05:44 rooi-oog: Hi all. I'm wondering if opengl 4.3 profile on my GK208 is a bug or a feature? Is there any options to get 4.5? I'd read mesa 18.0 has full support of 4.5 profile.
11:42 RSpliet: pmoreau: when I saw the one-liner e-mail from the student proposing to work on vulkan I kind of already assumed it wasn't going to happen. Zero own research, no sign of curiousity, no in-depth questions...
12:28 pmoreau: RSpliet: True :-D
18:40 pendingchaos: imirkin_: am I correct in thinking that the FIFO engine split commands into per-engine queues
18:40 pendingchaos: and each engine executes their commands in parallel to those of other engines
18:40 pendingchaos: and that SERIALIZE waits for the current and queued commands of each engine to finish?
18:40 imirkin_: all correct except the last bit
18:40 imirkin_: gr engine is fancy.
18:41 imirkin_: it receives commands
18:41 imirkin_: and then executes them out of order
18:41 imirkin_: or in parallel
18:41 pendingchaos: "gr engine"?
18:41 imirkin_: a SERIALIZE tells it "wait for everything to finish before processing the next command"
18:41 imirkin_: gr = graph
18:41 imirkin_: the engine which handles 2d, 3d, probably copy classes
18:42 imirkin_: (fermi had separate copy engines? kepler's copy2 engine is part of pfifo directly)
20:12 HdkR: imirkin_: Oh right. I found out the issue I was having with my screens flickering under Nouveau with multi-GPU. I had accidently set up the multiple monitors to have a couple pixel overlap...
20:12 HdkR: er, multi-screen
20:12 HdkR: Not multi-gpu
20:16 imirkin_: hah
20:16 imirkin_: that shouldn't flicker though
20:16 imirkin_: although who knows how those scanout engines work
20:18 HdkR: I only figured it out after I went back to the blob and noticed a couple pixels on the side of one screen that didn't belong :P
20:19 ClaudiusMaximus: hi, i ran into a bug. the glsl shader vec2 ts = vec2(textureSize(tex, 0)); float aspect = ts.x / ts.y; works, but this fails with bad image output (as if division by 0): float aspect = float(textureSize(tex, 0).x) / float(textureSize(tex, 0).y); both work fine with nvidia proprietary driver
20:19 ClaudiusMaximus: will try later on an old laptop with ati graphics to see if it is a more general issue, but for now i've tested with nouveau on a less-old laptop
20:19 imirkin_: ClaudiusMaximus: i'm sure it's a nouveau issue
20:20 imirkin_: there have been some issues with textures lately that i've not had a chance to fix
20:20 imirkin_: if you use an older version of mesa, it should be fine
20:20 imirkin_: like 17.1 or so
20:20 imirkin_: i forget when it got broken
20:20 imirkin_: the problem isn't the shader, but rather the texture binding updates
20:20 ClaudiusMaximus: i'm using whatever comes with debian stable latest updates
20:20 imirkin_: ok, and what would that be?
20:22 ClaudiusMaximus: i have xserver-xorg-video-nouveau 1.0.13 apparently, let me grab the output of glxinfo (bit slow as i'm on irc from desktop but laptop is having the issue)
20:23 ClaudiusMaximus: mesa 13.0.6
20:23 ClaudiusMaximus: old
20:24 ClaudiusMaximus: i found a bug report from 2015 about textureSize() but the test case attached to it worked fine for me
20:24 ClaudiusMaximus: so it think it's a different bug
20:24 ClaudiusMaximus: i do have a fairly minimal reproducer (160 or so lines of C99, using GLEW and GLFW3)
20:26 ClaudiusMaximus: http://lpaste.net/364633
20:28 ClaudiusMaximus: what other info should i put in a bug report? i don't think it is the textuer binding update actually, because getting the textureSize works, as long as i cast it to a vec2 before division - it fails when i try to access the parts separately as floats
20:28 ClaudiusMaximus: but i'm not a driver coding expert, so my assumption may be naive :)
20:32 pendingchaos: I'm getting some slightly-stretched colourful noise on my GP106/GTX 1060
20:33 pendingchaos: (on a fairly recent development mesa)
20:40 imirkin_: pendingchaos: is your complaint about the noise or the stretching? :)
20:40 imirkin_: ClaudiusMaximus: hmmmm welll ... i can try your reproducer (later tonight)
20:40 imirkin_: what GPU are you on?
20:41 pendingchaos: the noise is what should be shown
20:41 imirkin_: pendingchaos: i'm not sure i understand your issue
20:42 imirkin_: [actually, i'm sure i don't understand it]
20:42 pendingchaos: sorry if I wasn't clear, I ran the reproducer
20:42 pendingchaos: it looked fine
20:42 imirkin_: ohhh
20:42 imirkin_: now i get it :)
20:42 imirkin_: you ran ClaudiusMaximus's code.
20:44 ClaudiusMaximus: pendingchaos: ok - i get full-width lines with the bug, slightly stretched noise with the working version
20:44 imirkin_: ClaudiusMaximus: what gpu?
20:44 ClaudiusMaximus: imirkin_: i annotated the lpaste with lspci -vv excerpt
20:44 imirkin_: ah. G98.
20:44 ClaudiusMaximus: VGA compatible controller: NVIDIA Corporation G98M [GeForce G 105M] (rev a1) (prog-if 00 [VGA controller])
20:44 imirkin_: i have a G92 plugged in at home
20:45 ClaudiusMaximus: yep
20:45 imirkin_: i'll see if it repros
20:45 imirkin_: you know ... textureSize problems sound mildly familiar.
20:45 imirkin_: i'd definitely try a later mesa
20:45 imirkin_: otoh, could be unrelated
20:47 pendingchaos: shouldn't there be a nouveau_pushbuf_bufctx(push, nvc0->bufctx); or PUSH_REFN(push, nvc0->screen->fence.bo) in nvc0_hw_get_query_result_resource? (they seem to fix an assertion failure in libdrm's pushbuf.c)
20:47 pendingchaos: if so, which one?
20:47 imirkin_: pendingchaos: iirc that logic is extremely fragile
20:47 imirkin_: it assumes that the callers do certain things
20:48 imirkin_: PUSH_REFN can trigger a pushbuf
20:48 imirkin_: oh wait. wrong function
20:48 imirkin_: it's not quite that fragile... let's see....
20:49 imirkin_: the fence bo is always in the bufctx
20:49 imirkin_: so unless there's something funky going on, it should be all good.
20:50 pendingchaos: it seems that the pushbuf's current bufctx isn't always nvc0->bufctx
20:50 ClaudiusMaximus: my ati laptop is too old to test with unfortunately (only does gl 2.1 glsl 120)
20:50 imirkin_: pendingchaos: that's right
20:50 pendingchaos: and I don't see a PUSH_REFN for fence.bo anywhere
20:51 imirkin_: but all bufctx's should have it... i'd think. maybe not.
20:51 imirkin_: which bufctx is it, in this case?
20:51 pendingchaos: and commenting out lines 467-469 (the wait || hq->state == NVC0_HW_QUERY_STATE_READY condition) triggers an assert
20:51 pendingchaos: removing it make it always use nvc0->screen->fence.bo for 64bit queries
20:52 pendingchaos: "which bufctx is it, in this case?"? nvc0_hw_get_query_result_resource is sometimes called with the current bufctx as NULL of that answers your question
20:52 imirkin_: ahh
20:52 imirkin_: curious.
20:53 imirkin_: and surprising.
20:53 pendingchaos: unless I'm retrieving the current bufctx wrong
20:53 imirkin_: i'll be honest - it's been quite a while
20:53 imirkin_: since i've looked at any of this stuff
20:53 imirkin_: i'd have to dig into it again to see what the expected situation is
20:53 imirkin_: offhand, it seems surprising that there's no bufctx
20:56 pendingchaos: struct nouveau_bufctx* cur = nouveau_pushbuf_bufctx(push, NULL); nouveau_pushbuf_bufctx(push, cur); printf("bufctx: %p\n", cur);
20:56 pendingchaos: sometimes it prints "bufctx: (nil)"
20:57 pendingchaos: (it just occurred to me I could just to push->bufctx)
20:57 imirkin_: ;)
21:03 pendingchaos: the only place I see where it could be set to NULL is at the end of nvc0_draw_vbo
21:03 imirkin_: but even when it's not inside a draw
21:04 imirkin_: it still has to reference all the usual "system" things
21:04 imirkin_: hm
21:18 ClaudiusMaximus: upgraded my laptop mesa to debian buster (testing), version 17.3.7, my bug is still present
21:21 imirkin_: cool. i'll check it out tonight.
21:21 imirkin_: ClaudiusMaximus: oh, do you ever sample from the texture?
21:22 ClaudiusMaximus: yes
21:22 imirkin_: and you use texture(), not texelFetch?
21:22 ClaudiusMaximus: yes
21:22 imirkin_: k. i'll look tonight
22:03 catphish: i have a laptop with dual gpus (prime) and i'm interested in trying to use both, however despite having nouveau loaded, i only see my ati display in xrandr --listproviders, not sure where to begin looking for a solution, and pointers appreciated
22:04 imirkin_: catphish: https://nouveau.freedesktop.org/wiki/Optimus/
22:04 catphish: thanks, just found that, reading now
23:04 catphish: those instructions were helpful, seems i'm half way there, i now see 2 entries in xrandr --listproviders, but setting DRI_PRIME=1 doesn't cause my second adapter to be used, it does break the vsync in glxgears though, so something is happening https://paste.ubuntu.com/p/YrykxZnwjc/
23:05 imirkin_: catphish: strace -f -e open DRI_PRIME=1 glxinfo > /dev/null
23:05 imirkin_: pastebin the results of that.
23:05 imirkin_: er, crap
23:05 imirkin_: make that
23:06 imirkin_: DRI_PRIME=1 strace -f -e open glxinfo > /dev/null
23:06 imirkin_: oh, and throw on a LIBGL_DEBUG=verbose on there
23:07 catphish: sure, 1 sec
23:08 catphish: https://paste.ubuntu.com/p/hPj5JHYkcW/
23:08 imirkin_: ok, so that's a pretty direct fail...
23:08 imirkin_: pastebin xorg log
23:09 catphish: if it matters (it probably does) i'm currently running linux mint (based on xenial) with https://launchpad.net/~xorg-edgers/+archive/ubuntu/ppa installed
23:09 catphish: log: https://paste.ubuntu.com/p/8GxWTrTm6R/
23:10 imirkin_: [ 101.810] (EE) NOUVEAU(G0): Failed to initialise context object: COPY_NVE0 (0)
23:10 imirkin_: [ 101.810] (EE) NOUVEAU(G0): Error initialising acceleration. Falling back to NoAccel
23:10 imirkin_: that will not lead to a lot of acceleration :)
23:11 imirkin_: pastebin dmesg (and i'll bbiab)
23:11 catphish: oh yeah
23:11 catphish: https://paste.ubuntu.com/p/tw7szcgw7q/
23:11 catphish: thanks!
23:18 catphish: brb, i'll try a rather more modern kernel
23:22 catphish: upgrading from 4.4.0-119 to 4.16.1 fixed it
23:23 catphish: i guess my nouveau kernel driver was too old for the xorg driver?
23:24 catphish: it might have been ok if i didn't use the bleeding edge xorg stuff, i installed that before i realised my previous problem was simply that i had options nouveau modeset=0 stuck in my initrd
23:26 catphish: interestingly different results: https://paste.ubuntu.com/p/cj2BgrghTj/
23:26 catphish: not quite what i expected
23:27 karolherbst: catphish: is glmark a 64 bit application?
23:28 karolherbst: ohh wait, it is open source, so probably
23:28 catphish: i'd assume it's built from source as such, yes
23:28 catphish: also, NV117 seems wrong
23:30 karolherbst: catphish: it is gm107
23:30 catphish: oh, no, GTX 960M, it's correct, thought this laptop has a 1050 :)
23:31 imirkin_: catphish: btw, if you reclock, you should get more respectable framerates
23:31 imirkin_: cat /sys/kernel/debug/dri/1/pstate for a list of available levels
23:32 catphish: interesting
23:36 imirkin_: (note that the gpu has to be powered up to make use of these)
23:37 imirkin_: and the settings get lost when it powers down
23:37 imirkin_: karolherbst: what's going on with your patches btw?
23:37 imirkin_: it's been like ... ages
23:37 karolherbst: I didn't tough those
23:37 karolherbst: *touch
23:37 imirkin_: skeggsb: what's the holdup?
23:38 imirkin_: i feel like an idiot every time i have to explain that people will hang their box if they try to reclock while the gpu is runpm-suspended
23:38 catphish: well that mostly just crashed my computer
23:38 catphish: brb probably need to reboot to fix that :)
23:38 catphish: i have no mouse
23:39 karolherbst: imirkin_: maybe I could split out all the bug fixes
23:39 karolherbst: imirkin_: like that one: https://github.com/karolherbst/nouveau/commit/9d029ff5646dd510c59f1593fb82787b5a63e2d3
23:39 imirkin_: sure.
23:39 karolherbst: not that it matters much....
23:39 imirkin_: is there anything contentious in your patches?
23:39 imirkin_: i mean why haven't they just been applied
23:40 karolherbst: nobody time to review? dunno
23:40 skeggsb: iirc there was something from my last review, and it hasn't been updated since... can't quite remember now
23:40 skeggsb:will try and find out
23:40 karolherbst: skeggsb: mhh might be indeed
23:40 karolherbst: but I think i addressed that actually
23:41 catphish: back :)
23:41 imirkin_: catphish: check the logs (see title) - i mentioned some things that could be relevant to you
23:41 karolherbst: skeggsb: or I forgot it again...
23:42 catphish: https://paste.ubuntu.com/p/Dp5rWspqsx/
23:42 imirkin_: step 1:
23:42 imirkin_: DRI_PRIME=1 glxgears
23:42 imirkin_: let it run in the background.
23:43 catphish: i echoed 0f in there, and bad things happened
23:43 imirkin_: and then cat that file again
23:43 karolherbst: imirkin_: actually I think the clock state should be remain the samer after suspending actually
23:43 karolherbst: I remember some discussions about that
23:43 imirkin_: catphish: basically when the gpu is off, bad things will happen
23:43 imirkin_: and it turns itself off if you're not using it
23:44 catphish: well that's ideal
23:44 imirkin_: [bad things will happen if you try to do a reclock, that is]
23:44 catphish: oh i see
23:44 catphish: https://paste.ubuntu.com/p/h48Z53jTCH/
23:44 imirkin_: AC: core 405 MHz memory 810 MHz
23:44 imirkin_: there ya go.
23:44 imirkin_: that means it's on. echo 0f > ...
23:44 catphish: yep, it's on now
23:45 imirkin_: and then run glmark2 (and you can kill glxgears)
23:45 catphish: what do those lines mean?
23:45 catphish: AC is the current state?
23:45 imirkin_: each line is a power state. the last line is the current settings.
23:45 catphish: ok
23:45 catphish: and you cant switch it while it's off :)
23:46 imirkin_: (it is somehow hooked up to whether you're on AC or DC power, and the thought was that you could set different levels for AC and DC power)
23:46 catphish: https://paste.ubuntu.com/p/qjcvXyv58G/
23:46 skeggsb: it's not just a thought, you can
23:46 imirkin_: =]
23:46 skeggsb:has been using that for years now
23:47 karolherbst:hasn't
23:47 imirkin_: catphish: now run glmark2
23:47 karolherbst: :p
23:47 imirkin_: skeggsb: i think you're the only one who knows how to make it work
23:47 catphish: it doubled my glxgears rate for a start
23:47 karolherbst: skeggsb: https://github.com/karolherbst/nouveau/commit/0cd8b3e998e0a421a696a67d4bf524769cc618b8
23:47 imirkin_: catphish: glxgears with optimus is mostly a measure of pcie bandwidth
23:47 karolherbst: skeggsb: I noticed that my battery hit "a" power budget while running on batteries
23:47 karolherbst: and the GPU throttled
23:47 karolherbst: with Nouveau
23:47 karolherbst: no clue where that comes from
23:48 skeggsb: https://paste.fedoraproject.org/paste/hDZvy8lJVafEouT~WtsqsQ
23:48 catphish: the same is probably true of glmark2, it may well be the frame copying thats limiting it
23:48 catphish: https://paste.ubuntu.com/p/gcFdpWD9sQ
23:49 imirkin_: (while without optimus, glxgears is a measure of fill rate)
23:49 catphish: better, still limited by something, i'll try to find a more demanding test
23:49 karolherbst: catphish: it looks like you hit the same bottleneck in all tests :p
23:49 karolherbst: pixmark_piano is perfectly demanding
23:49 imirkin_: heheh
23:49 karolherbst: (and triggers intel syncing bugs)
23:49 imirkin_: you'll get like 0.01 fps with that
23:49 karolherbst: reports 15fps, looks like 4
23:49 catphish: karolherbst: yeah, i guess thats my frame copying bandwidth :)
23:50 catphish: awesome, still turns the gpu off when it's idle
23:50 catphish: this is cool
23:50 karolherbst: imirkin_: I got a 200fps result once ... *whistles*
23:50 imirkin_: karolherbst: uh huh. where you make the frag shader do nothing?
23:50 karolherbst: imirkin_: no, real work
23:50 karolherbst: just the right GPU was used :p
23:50 imirkin_: hehe
23:51 imirkin_: and the right driver :p
23:51 karolherbst: well right
23:51 karolherbst: but nouveau is like 80% compared to blob
23:51 karolherbst: at least on kepler
23:51 imirkin_: 60-80 on kepler i think
23:51 karolherbst: would be strange
23:51 imirkin_: gets down to like 50% on GM10x
23:51 karolherbst: because you need like nothing for it
23:51 karolherbst: only a good compiler
23:51 imirkin_: and a good resource manager.
23:51 karolherbst: anything else shouldn't be an issue
23:51 karolherbst: not even that
23:51 imirkin_: we have neither.
23:52 karolherbst: why would a resource manager be important here?
23:52 catphish: i used to use the nvidial blob, never got over the need to reboot to switch driver, none of the frame copying techniques ever worked for me back then
23:52 catphish: now it just seemt to work out of the box with nouveau, so i'm very happy
23:52 imirkin_: catphish: yeah, it works nicely in certain scenarios.
23:53 catphish: though the manual clocking is a tad tedious
23:53 imirkin_: be thankful that it can be done at all
23:53 imirkin_: that's a recent addition
23:53 imirkin_: (relatively)
23:54 skeggsb: and shouldn't have been done because it's incorrect ;)
23:54 catphish: well i'm happy :)
23:54 imirkin_: skeggsb: you're such a purist... :p
23:54 catphish: hopefully this will do for occasional games :)
23:55 catphish: i think glmark2 gets more challenging, i'll let it run a while
23:56 karolherbst: skeggsb: I think the last thing we talked about was some racy stuff with the therm thing or something though
23:56 karolherbst: but I thought I resolved all this...
23:56 karolherbst: well, I guess I will retest stuff
23:56 catphish: wonder if there's any good linux vr yet
23:57 imirkin_: i wouldn't expect too much
23:58 karolherbst: skeggsb: I will create a branch with only trivial bugfixes, should be good enough for now