01:39RSpliet: oh wow... "4.5.3 Mail limit reached. Please try again later."
02:01Berra: kernel rejected pushbuf: Invalid argument
04:14paulk-collins: hey there, I figured that Maxwell GPUs need a (nvidia-signed?) firmware with nouveau, but what about Kepler? Was it all reversed and replaced by free code or do we still need a proprietary firmware?
04:22pmoreau: paulk-collins: Iirc, it should be fine with Kepler, except for some NVE6/NVE7 chipsets ---see https://bugs.freedesktop.org/show_bug.cgi?id=70354
04:28paulk-collins: ok, thanks
07:17l4mRh4X0r: Hi! I'm trying to get PRIME to work on my laptop. xrandr --listproviders shows both the Intel graphics and nouveau, but after I run xrandr --setprovideroffloadsink nouveau Intel, if I run DRI_PRIME=1 glxinfo | fgrep "OpenGL vendor", it still says Intel
07:17l4mRh4X0r: Can someone help me getting it to work?
07:21pmoreau: Sorry, I don't know more than what the wiki says... :/
07:21pmoreau: imirkin would surely know, but he's not there yet
07:22l4mRh4X0r: Ah, okay. Do you know when he might be?
07:23pmoreau: He usually comes about now.
07:23l4mRh4X0r: Ah, I'll just wait then
07:24pmoreau: He always reads the logs, so if you idle he'll answer when he comes back.
07:49alec-b: hi, I'm booting with nouveau.pstate=1 and I can read the clock info on /sys, but for some reason the file doesn't allow writting
07:49alec-b: what might be the cause? am I right in the assumption that echo'ing to that file is how one should try out reclocking?
07:52pmoreau: alec-b: You're assuming right
07:52pmoreau: Are you trying to echo as root?
07:53alec-b: when I do "echo '07' > pstate" I get the following: echo: write error: function not implemented
07:53pmoreau: Ah, well it's not implemented then :)
07:53pmoreau: What card do you have?
07:53alec-b: when I cat pstate I get the available levels (4 different)
07:54alec-b: gtx 285
07:54alec-b: I was under the impression it was implemented for this card
07:54pmoreau: There's a difference in being able to read the clocks in having the code to set them
07:54pmoreau: Which kernel version do you have?
07:54alec-b: 3.19.8 atm
07:55pmoreau: You're a bit too early: NVA0 cards don't have reclocking yet, but it's a work in progress (RSpliet submitted some patches for that yesterday)
07:56alec-b: probably on 4.1 then?
07:56alec-b: it's ok I just wanted to try it out, I really don't need it at all
07:56alec-b: ty :)
07:57pmoreau: alec-b: You can find the patches here if you want to test: http://lists.freedesktop.org/archives/nouveau/2015-May/020889.html
07:57alec-b: ty :)
07:58pmoreau: I'm sure he'll love some feedback if you happen to test them :)
08:00alec-b: I'm not 100% sure my feedback will be valuable. Reason being this old old gpu is kinda broken. It shows graphics corruption with binary drivers. Fortunately I can use it well with nouveau, and I think it's because binary forces the max peformance level constantly whenver we have more than 1 monitor and they don't happen to have exactly the same resolution/refresh rates
08:00alec-b: whiles downclocked the card seems to work well
08:00alec-b: so in case reclocking fails, there will always be doubt the gpu might be at fault, and not nouveau
08:01pmoreau: Ah ah, ok :D
08:01alec-b: so it's nice I only get to use it at all because of nouveau :)
10:41imirkin: paulk-collins: all (G84+) gpu's still require proprietary firmware for video decoding acceleration
10:42imirkin: paulk-collins: starting with kernel 4.1, GM107 no longer requires firmware for (regular) acceleration. GM200+ is the one that starts requiring signed fw
10:42imirkin: paulk-collins: that said, bugs exist, etc :) but everything up to GM107 inclusive shouldn't require proprietary firmware
10:43imirkin: l4mRh4X0r: most likely acceleration isn't coming up on your gpu. please pastebin dmesg and xorg log
11:42hakzsam: imirkin, could you push the timestamp-disjoint fix please? http://cgit.freedesktop.org/~hakzsam/mesa/log/?h=nv50_timestamp_disjoint
11:44imirkin: hakzsam: pushed
11:45imirkin: hakzsam: you should request push access to mesa...
11:45hakzsam: imirkin, yes, and I don't want to annoy you each time I need to push something ... :)
14:38mcayland: hi all. i've just upgraded to from debian wheezy to jessie and i'm struggling with corrupt graphics on-screen with KDE under X.
14:39imirkin: mcayland: pastebin dmesg + xorg log -- that should answer some basic questions
14:39mcayland: imirkin: okay will do. FWIW card identifies as NV44...
14:40imirkin: ah heh. and i bet you're using kwin or something?
14:40imirkin: try disabling opengl compositing, iirc kwin can do xrender
14:42mcayland: imirkin: http://pastebin.com/WvM23rmj
14:43imirkin: mcayland: yeah, that all looks fine.
14:43mcayland: i'm just using the default installation so i guess it could be kwin. need to figure out how to disable opengl compositing when i can't see properly...
14:44mcayland: also for some reason the mouse cursor is green :/
14:44RSpliet: what's wrong with green?
14:44mcayland: wheezy seemed to work fine FWIW
14:44RSpliet: it's a nice colour...
14:44mcayland: RSpliet: nothing personal against green i guess, it just used to be grey before the upgrade :)
14:49mcayland: imirkin: quick sanity check while i go and figure out about opengl compositing: http://www.ilande.co.uk/tmp/kde-jessie.jpg
14:50imirkin: nice, i like it ;)
14:52imirkin: mcayland: https://fitzcarraldoblog.wordpress.com/2011/09/08/toggle-kwin-compositing-on-and-off-easily-from-your-desktop/
14:52imirkin: just from a quick search
14:53imirkin: qdbus org.kde.kwin /KWin toggleCompositing
14:57mcayland: imirkin: okay have managed to switch over to xrender - thanks a lot!
14:57mcayland: but i still have a green mouse pointer...
14:58imirkin: are you secretly on powerpc?
14:58mcayland: heh no sorry
14:58imirkin: openly? :)
14:58mcayland: still no :)
14:58imirkin: anyways, sorry, the mouse pointer thing is weird
14:59imirkin: perhaps it got corrupted somehow...
14:59mcayland: i tried restarting x and that didn't help. does it need a reboot?
15:00imirkin: worth trying, i suppose
15:00mcayland: cool will do in a sec (copying files!). as for the opengl vs. xrender, is opengl compositing not supported for NV44? or does it need a newer mesa than the one in jessie?
15:01imirkin: the nv30 opengl driver is ... shall we say... imperfect
15:01mcayland: and i guess no-one is working on it since it's fairly old?
15:01imirkin: it's good enough for stupid things, but the compositing stuff tends to do stupidly heavy things
15:01glennk: i don't think kwin is known for using lightweight shaders that would run well on ancient hardware
15:02imirkin: i actually just plugged a NV44 into my box because people were saying really basic stuff was broken
15:02imirkin: but they appeared to be lying
15:02imirkin: (2 people said glxgears was broken... worksforme though)
15:02glennk: probably more that their $desktopenvironment started using composite/GL after an update
15:03mcayland: glennk: hmmm it's a shame kwin uses that as the default if it needs support :/
15:03imirkin: glennk: perhaps
15:03imirkin: well, i suspect their answer is "stupid drivers! disable nouveau."
15:03imirkin: which... i wouldn't wholly disagree with, at least on the 3d front
15:03mcayland: imirkin: fwiw debian jessie is 3.16 so i bet that's quite old compared to git master :/
15:03imirkin: meh, that's the kernel. not exactly a lot of changes going in that affect pre-nv50
15:04imirkin: not exactly a lot of changes going into mesa either, tbh :)
15:04glennk: pre-nv50 is basically on life support by now?
15:04mcayland: i guess the answer is "buy a slightly less obsolete piece of graphics hardware" then? :)
15:05glennk: well, 10 bucks on ebay might be a good investment
15:05mcayland: unless you like green mouse pointers
15:06imirkin: glennk: meh, dunno. i just plugged one in again, so there may be a bunch of fixes coming up :)
15:06glennk: oh wait, nv43, thats an agp card right?
15:07mcayland: imirkin: cool i can help test if you like :)
15:07imirkin: glennk: nv4a was agp... the rest of nv4x are pcie
15:07imirkin: glennk: although i think a few came with pcie <-> agp adapters maybe?
15:08glennk: i mean the card itself, using a pcie<->agp bridge chip
15:08imirkin: right, all nv4x are native pcie
15:08glennk: same bridge chip that nv4a used, just in the opposite direction
15:08imirkin: except the nv4a/nv44a
15:08imirkin: nv3x are native agp
15:11mcayland: i can confirm that glxgears works for me
15:11imirkin: cool :)
15:12mcayland: for testing do people run piglit to see how support on older hardware works?
15:13pmoreau: How does BAR1 work: who uses it and for what?
15:13imirkin: mcayland: http://people.freedesktop.org/~imirkin/nv40-comparison/problems.html
15:14imirkin: pmoreau: can you rephrase the question? what do you mean by "how"?
15:14imirkin: pmoreau: you send it reads and writes, and it operates in the expected way :)
15:14glennk: lol for the s3tc fails on nv4a
15:15glennk: nv4b sorry
15:15imirkin: glennk: i think there was something weird about that run
15:15glennk: *might* also have something to do with nv3x hardware implementing s3tc incorrectly
15:15pmoreau: imirkin: I ran two traces of Nouveau, one with PCI-reseting the G96 and the other without. And most differences comes from R/W to BAR1 area, and the one without PCI-reset does a lot more time checking between those R/W, so I'm trying to understand why. :)
15:16imirkin: glennk: could be, i haven't actually looked at it...
15:16glennk: imirkin, more precisely, it interpolated the endpoint colors using rgb565 precision instead of rgb888
15:17imirkin: pmoreau: nouveau shouldn't be waiting... unless you mean nv_wait, which uses that crazy ptimer thing
15:17pmoreau: Yes, nv_wait
15:17imirkin: pmoreau: in which case could be that ptimer is somehow broken
15:17imirkin: and/or misconfigured
15:17pmoreau: Hum... I'll have a look at him then
15:18imirkin: mcayland: if you're looking to improve mesa on nv4x, i could probably find some beginner (or advanced!) tasks
15:19pmoreau: imirkin: So what is BAR1 used for? It's not regs as in BAR0 I think, so is it just some memory pool from which you can allocate stuff?
15:20imirkin: pmoreau: http://envytools.readthedocs.org/en/latest/hw/bus/bars.html
15:20imirkin: pmoreau: BAR1 is an aperture into VRAM
15:20imirkin: [i assume passing through the MMU]
15:20pmoreau: imirkin: I had a look at it, but... It didn't helped me much
15:20glennk: mcayland, 64MB card?
15:21pmoreau: imirkin: Is it some kind of redirection to some VRAM area?
15:21imirkin: pmoreau: right
15:21imirkin: pmoreau: so imagine you have 100TB of vram
15:21imirkin: pmoreau: and you want to access it somehow
15:22mcayland: glennk: yes
15:22imirkin: pmoreau: PCI cards can expose memory areas ("BAR" - Base Address Register?)
15:22mcayland: imirkin: that does sound tempting, although i do struggle for time.
15:22imirkin: pmoreau: which have a certain size and do whatever they want. in this case, it exposes a (say) 256MB window into VRAM
15:22mcayland: (and i can confirm that the green mouse pointer still exists after reboot)
15:22imirkin: mcayland: yeah, time is the biggest constraint =/
15:22imirkin: the green mouse cursor thing is quite odd... i should check if i see one or not
15:23imirkin: i just have it hooked up to s-video right now :)
15:23mcayland: i guess these cards use hardware cursors for the mouse?
15:23imirkin: hmmmm... weird. doesn't appear to be visible.
15:23imirkin: yeah, all nvidia gpu's have a hw cursor
15:23glennk: 1980x1080 on 64MB with compositing, erm, tight fit
15:23imirkin: could be a palette issue
15:24pmoreau: imirkin: Is this window fixed or can you move it?
15:24imirkin: pmoreau: you can configure it with MMIO writes
15:24imirkin: i forget exactly which mmio regs control it...
15:24imirkin: imem maybe? or that could be something else
15:24pmoreau: imirkin: Ok, thanks!
15:24mcayland: definitely smells like a shift issue...
15:25imirkin: mcayland: yeah, could be a RGB565 vs RGB888 thing, who knows
15:25mcayland: it looked okay in wheezy (3.2 kernel)
15:25mcayland: but i guess that doesn't help much :/
15:26imirkin: yeah, nouveau's been rewritten several times since then
15:27imirkin: pmoreau: it's the HOST_MEM stuff it looks like. check rnndb/bus/pbus.xml
15:28imirkin: pmoreau: and there's PTIMER.REMAP. hm.
15:28imirkin: oh, but that's for old cards
15:28pmoreau: imirkin: Hum... I'll have a look
15:29mcayland: imirkin: do you have a page of nv44 tasks starting from "easy" to "stupidly hard"?
15:30imirkin: mcayland: https://trello.com/b/ZudRDiTL/nouveau
15:30imirkin: this is the biggie: https://trello.com/c/PHZjdkSc/5-nv30-create-a-way-to-have-a-different-backing-rt-to-fix-unreasonable-render-format-restrictions-between-cbuf-and-zsbuf
15:33imirkin: mcayland: getting rid of the crashes in piglits would be nice... most of them are assert failures so not crashes in practice, but still probably good to handle somehow
15:33glennk: does kwin allocate a z/stencil buffer?
15:34imirkin: if it does, that would def potentially cause problems if it used a 16-bit one
15:34glennk: also would use most of the memory on a 64MB card
15:35glennk: 24.5MB about anyway
15:35imirkin: glennk: don't forget the turbocache! :)
15:36glennk: i don't remember those cards really working with framebuffer in system memory
15:36glennk: on agp systems at least
15:36mcayland: so 1920x1080 = 2MB * 4 bytes per pixel (RGBA) = 8MB?
15:37mcayland: imirkin: i'm still trying to translate the biggie into english :)
15:38imirkin: mcayland: you won't be able to, but i can explain it. on a scale of 1 to 10, how well do you know GL?
15:39mcayland: basic knowledge of how shaders work, some client API usage but that's it
15:40imirkin: ok, well basically there's something called a "framebuffer"
15:40imirkin: which can have various attachments
15:41imirkin: the attachments are basically textures with various types
15:41imirkin: you can have some number of color textures, and a depth/stencil one
15:41imirkin: the hw has various restrictions on the formats of these attachments
15:42imirkin: for color, nv3x can render to either RGB565 or RGBA8888
15:42imirkin: for depth/stencil it can do either Z16 or Z24_S8
15:42imirkin: but.... it can't mix and match them as much as you'd want
15:42imirkin: so if you have color *and* depth, you can only do RGB565 + Z16 *or* RGBA8888 + Z24_S8
15:42mcayland: ah. so the driver would have to convert them on the fly?
15:42imirkin: but RGB565 + Z24_S8 and RGBA8888 + Z16 can't work
15:43imirkin: so... the driver has to do *something*
15:43imirkin: but when reading (or writing) to these things directly, you want them to have the right formats
15:44mcayland: yeah otherwise you waste time doing the converting. but clients expect to be able to do this?
15:44imirkin: and attachments can be mixed/matched (in theory), so you might attach a depth buffer to an RGB565 color, and then to a RGBA8888 one
15:44imirkin: unfortunately there's no good way of communicating this issue over the GL api. you could just start making framebuffers incomplete, but applications won't cope well with such restrictions
15:46mcayland: that definitely seems slow. are there any tricks you can do with e.g. configuring hardware interleave?
15:48imirkin: not gonna say 'no', but i'm not aware of any reasonable way around this
15:48imirkin: so anyways, my genius solution to this problem is that if i detect a problem color/depth combo, i just don't bind the depth buffer
15:48glennk: not to mention that a sane compositor would not be using any depth/stencil buffers in the first place
15:49imirkin: seemed better than generating errors
15:49imirkin: but definitely a bit suboptimal
15:49imirkin: i just happened to notice that point sprites appear to be a bit broken too
15:50mcayland: meh. what do the proprietary drivers do in these cases?
15:50imirkin: i assume they do the copy, but i haven't checked
15:50imirkin: they're a pain to bring up
15:50imirkin: since they require old kernel, old X, etc
15:50imirkin: iirc 304 series is the last one that supports nv4x
15:51mcayland: could qemu help with this at all?
15:51imirkin: with difficulty, perhaps
15:52imirkin: glennk: does "R" mode mean anything to you in the context of point sprites?
15:53glennk: r = coordinate replace?
15:53imirkin: the options are "zero", "r", and "s"
15:53glennk: is this some nv4x register?
15:55glennk: no idea
15:58mcayland: imirkin, glennk: it's getting late here so gotta go sleep :)
15:59mcayland: thanks for the pointers re: nv44. i'm interested in trying to learn this stuff if i can get time...
15:59mcayland: shall i follow the mailing list for patches/progress?
16:00imirkin: sure. and idle in here.
16:02mcayland: awesome thanks guys. catch you both later :)
17:01imirkin: bleh, 3d blits appear to be broken on nv4x
17:01imirkin: (or *something* to make copyteximage mad)
17:44imirkin: bleargh. calim's texcoord enablement on nv30 didn't fix up the nv30_draw thing to support it
17:52imirkin: ugh. yeah. the draw patch seems pretty broken =/
21:06imirkin: gr. and swtnl got majorly broken between 10.5 and now... odd.
21:11buhman: break it harder
21:22imirkin: i don't think that's an option... doing a bisect now to see what killed it.
21:23imirkin: it was already pretty broken, but this is going to new heights
21:24imirkin: of course there aren't a lot of ways to fall onto the draw path... point sprites and vertex prog compilation failure
21:51koz_desktop: If I have a very dark screen after I boot from GRUB, could it be caused by my graphics card not liking Nouveau?
21:51koz_desktop: (I don't have X installed just yet)
21:52imirkin: how much after grub? when switching resolutions?
21:53imirkin: well, the screen is supposed to be black bg, white text/cursor
21:54imirkin: what platform are you on?
21:54koz_desktop: I get a dim grey background, a slightly less dim grey text/cursor.
21:55imirkin: i meant like... is this a ppc? or other funny cpu?
21:56imirkin: and what gpu is it?
21:56koz_desktop: It's an Intel machine, using some Maxwell GPU.
21:56koz_desktop: I'm not certain which one.
21:56imirkin: lspci -d 10de: -nn
21:57koz_desktop: GeForce 840M
21:59imirkin: i was looking for GMxxx
22:00imirkin: not directly supported by nouveau atm. also most likely not the primary gpu
22:00imirkin: i.e. the display is probably being driven by the intel igp
22:00koz_desktop: So how would I stop it ending up so dim?
22:01koz_desktop: And does it mean I don't actually need nouveau on this thing?
22:01imirkin: need or no, you're certainly not using it now -- nouveau will bail on load when it sees the GM108
22:01imirkin: unless you have local patches to tell it to work the same way as GM107
22:01koz_desktop: Will that help any? Or even work?
22:02imirkin: nope, your display is driven by the intel igp
22:03koz_desktop: OK, thanks.
22:04imirkin: at least that is the most likely situation
22:04imirkin: but i'd need to see dmesg to confirm
22:04koz_desktop: Once I can, I'll get it to you, but I suspect you're right - I just nuked nouveau and X server runs fine.