05:44rooi-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:42RSpliet: 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:28pmoreau: RSpliet: True :-D
18:40pendingchaos: imirkin_: am I correct in thinking that the FIFO engine split commands into per-engine queues
18:40pendingchaos: and each engine executes their commands in parallel to those of other engines
18:40pendingchaos: and that SERIALIZE waits for the current and queued commands of each engine to finish?
18:40imirkin_: all correct except the last bit
18:40imirkin_: gr engine is fancy.
18:41imirkin_: it receives commands
18:41imirkin_: and then executes them out of order
18:41imirkin_: or in parallel
18:41pendingchaos: "gr engine"?
18:41imirkin_: a SERIALIZE tells it "wait for everything to finish before processing the next command"
18:41imirkin_: gr = graph
18:41imirkin_: the engine which handles 2d, 3d, probably copy classes
18:42imirkin_: (fermi had separate copy engines? kepler's copy2 engine is part of pfifo directly)
20:12HdkR: 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:12HdkR: er, multi-screen
20:12HdkR: Not multi-gpu
20:16imirkin_: that shouldn't flicker though
20:16imirkin_: although who knows how those scanout engines work
20:18HdkR: 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:19ClaudiusMaximus: 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:19ClaudiusMaximus: 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:19imirkin_: ClaudiusMaximus: i'm sure it's a nouveau issue
20:20imirkin_: there have been some issues with textures lately that i've not had a chance to fix
20:20imirkin_: if you use an older version of mesa, it should be fine
20:20imirkin_: like 17.1 or so
20:20imirkin_: i forget when it got broken
20:20imirkin_: the problem isn't the shader, but rather the texture binding updates
20:20ClaudiusMaximus: i'm using whatever comes with debian stable latest updates
20:20imirkin_: ok, and what would that be?
20:22ClaudiusMaximus: 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:23ClaudiusMaximus: mesa 13.0.6
20:24ClaudiusMaximus: i found a bug report from 2015 about textureSize() but the test case attached to it worked fine for me
20:24ClaudiusMaximus: so it think it's a different bug
20:24ClaudiusMaximus: i do have a fairly minimal reproducer (160 or so lines of C99, using GLEW and GLFW3)
20:28ClaudiusMaximus: 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:28ClaudiusMaximus: but i'm not a driver coding expert, so my assumption may be naive :)
20:32pendingchaos: I'm getting some slightly-stretched colourful noise on my GP106/GTX 1060
20:33pendingchaos: (on a fairly recent development mesa)
20:40imirkin_: pendingchaos: is your complaint about the noise or the stretching? :)
20:40imirkin_: ClaudiusMaximus: hmmmm welll ... i can try your reproducer (later tonight)
20:40imirkin_: what GPU are you on?
20:41pendingchaos: the noise is what should be shown
20:41imirkin_: pendingchaos: i'm not sure i understand your issue
20:42imirkin_: [actually, i'm sure i don't understand it]
20:42pendingchaos: sorry if I wasn't clear, I ran the reproducer
20:42pendingchaos: it looked fine
20:42imirkin_: now i get it :)
20:42imirkin_: you ran ClaudiusMaximus's code.
20:44ClaudiusMaximus: pendingchaos: ok - i get full-width lines with the bug, slightly stretched noise with the working version
20:44imirkin_: ClaudiusMaximus: what gpu?
20:44ClaudiusMaximus: imirkin_: i annotated the lpaste with lspci -vv excerpt
20:44imirkin_: ah. G98.
20:44ClaudiusMaximus: VGA compatible controller: NVIDIA Corporation G98M [GeForce G 105M] (rev a1) (prog-if 00 [VGA controller])
20:44imirkin_: i have a G92 plugged in at home
20:45imirkin_: i'll see if it repros
20:45imirkin_: you know ... textureSize problems sound mildly familiar.
20:45imirkin_: i'd definitely try a later mesa
20:45imirkin_: otoh, could be unrelated
20:47pendingchaos: 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:47pendingchaos: if so, which one?
20:47imirkin_: pendingchaos: iirc that logic is extremely fragile
20:47imirkin_: it assumes that the callers do certain things
20:48imirkin_: PUSH_REFN can trigger a pushbuf
20:48imirkin_: oh wait. wrong function
20:48imirkin_: it's not quite that fragile... let's see....
20:49imirkin_: the fence bo is always in the bufctx
20:49imirkin_: so unless there's something funky going on, it should be all good.
20:50pendingchaos: it seems that the pushbuf's current bufctx isn't always nvc0->bufctx
20:50ClaudiusMaximus: my ati laptop is too old to test with unfortunately (only does gl 2.1 glsl 120)
20:50imirkin_: pendingchaos: that's right
20:50pendingchaos: and I don't see a PUSH_REFN for fence.bo anywhere
20:51imirkin_: but all bufctx's should have it... i'd think. maybe not.
20:51imirkin_: which bufctx is it, in this case?
20:51pendingchaos: and commenting out lines 467-469 (the wait || hq->state == NVC0_HW_QUERY_STATE_READY condition) triggers an assert
20:51pendingchaos: removing it make it always use nvc0->screen->fence.bo for 64bit queries
20:52pendingchaos: "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:53imirkin_: and surprising.
20:53pendingchaos: unless I'm retrieving the current bufctx wrong
20:53imirkin_: i'll be honest - it's been quite a while
20:53imirkin_: since i've looked at any of this stuff
20:53imirkin_: i'd have to dig into it again to see what the expected situation is
20:53imirkin_: offhand, it seems surprising that there's no bufctx
20:56pendingchaos: struct nouveau_bufctx* cur = nouveau_pushbuf_bufctx(push, NULL); nouveau_pushbuf_bufctx(push, cur); printf("bufctx: %p\n", cur);
20:56pendingchaos: sometimes it prints "bufctx: (nil)"
20:57pendingchaos: (it just occurred to me I could just to push->bufctx)
21:03pendingchaos: the only place I see where it could be set to NULL is at the end of nvc0_draw_vbo
21:03imirkin_: but even when it's not inside a draw
21:04imirkin_: it still has to reference all the usual "system" things
21:18ClaudiusMaximus: upgraded my laptop mesa to debian buster (testing), version 17.3.7, my bug is still present
21:21imirkin_: cool. i'll check it out tonight.
21:21imirkin_: ClaudiusMaximus: oh, do you ever sample from the texture?
21:22imirkin_: and you use texture(), not texelFetch?
21:22imirkin_: k. i'll look tonight
22:03catphish: 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:04imirkin_: catphish: https://nouveau.freedesktop.org/wiki/Optimus/
22:04catphish: thanks, just found that, reading now
23:04catphish: 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:05imirkin_: catphish: strace -f -e open DRI_PRIME=1 glxinfo > /dev/null
23:05imirkin_: pastebin the results of that.
23:05imirkin_: er, crap
23:05imirkin_: make that
23:06imirkin_: DRI_PRIME=1 strace -f -e open glxinfo > /dev/null
23:06imirkin_: oh, and throw on a LIBGL_DEBUG=verbose on there
23:07catphish: sure, 1 sec
23:08imirkin_: ok, so that's a pretty direct fail...
23:08imirkin_: pastebin xorg log
23:09catphish: 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:09catphish: log: https://paste.ubuntu.com/p/8GxWTrTm6R/
23:10imirkin_: [ 101.810] (EE) NOUVEAU(G0): Failed to initialise context object: COPY_NVE0 (0)
23:10imirkin_: [ 101.810] (EE) NOUVEAU(G0): Error initialising acceleration. Falling back to NoAccel
23:10imirkin_: that will not lead to a lot of acceleration :)
23:11imirkin_: pastebin dmesg (and i'll bbiab)
23:11catphish: oh yeah
23:18catphish: brb, i'll try a rather more modern kernel
23:22catphish: upgrading from 4.4.0-119 to 4.16.1 fixed it
23:23catphish: i guess my nouveau kernel driver was too old for the xorg driver?
23:24catphish: 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:26catphish: interestingly different results: https://paste.ubuntu.com/p/cj2BgrghTj/
23:26catphish: not quite what i expected
23:27karolherbst: catphish: is glmark a 64 bit application?
23:28karolherbst: ohh wait, it is open source, so probably
23:28catphish: i'd assume it's built from source as such, yes
23:28catphish: also, NV117 seems wrong
23:30karolherbst: catphish: it is gm107
23:30catphish: oh, no, GTX 960M, it's correct, thought this laptop has a 1050 :)
23:31imirkin_: catphish: btw, if you reclock, you should get more respectable framerates
23:31imirkin_: cat /sys/kernel/debug/dri/1/pstate for a list of available levels
23:36imirkin_: (note that the gpu has to be powered up to make use of these)
23:37imirkin_: and the settings get lost when it powers down
23:37imirkin_: karolherbst: what's going on with your patches btw?
23:37imirkin_: it's been like ... ages
23:37karolherbst: I didn't tough those
23:37imirkin_: skeggsb: what's the holdup?
23:38imirkin_: 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:38catphish: well that mostly just crashed my computer
23:38catphish: brb probably need to reboot to fix that :)
23:38catphish: i have no mouse
23:39karolherbst: imirkin_: maybe I could split out all the bug fixes
23:39karolherbst: imirkin_: like that one: https://github.com/karolherbst/nouveau/commit/9d029ff5646dd510c59f1593fb82787b5a63e2d3
23:39karolherbst: not that it matters much....
23:39imirkin_: is there anything contentious in your patches?
23:39imirkin_: i mean why haven't they just been applied
23:40karolherbst: nobody time to review? dunno
23:40skeggsb: iirc there was something from my last review, and it hasn't been updated since... can't quite remember now
23:40skeggsb:will try and find out
23:40karolherbst: skeggsb: mhh might be indeed
23:40karolherbst: but I think i addressed that actually
23:41catphish: back :)
23:41imirkin_: catphish: check the logs (see title) - i mentioned some things that could be relevant to you
23:41karolherbst: skeggsb: or I forgot it again...
23:42imirkin_: step 1:
23:42imirkin_: DRI_PRIME=1 glxgears
23:42imirkin_: let it run in the background.
23:43catphish: i echoed 0f in there, and bad things happened
23:43imirkin_: and then cat that file again
23:43karolherbst: imirkin_: actually I think the clock state should be remain the samer after suspending actually
23:43karolherbst: I remember some discussions about that
23:43imirkin_: catphish: basically when the gpu is off, bad things will happen
23:43imirkin_: and it turns itself off if you're not using it
23:44catphish: well that's ideal
23:44imirkin_: [bad things will happen if you try to do a reclock, that is]
23:44catphish: oh i see
23:44imirkin_: AC: core 405 MHz memory 810 MHz
23:44imirkin_: there ya go.
23:44imirkin_: that means it's on. echo 0f > ...
23:44catphish: yep, it's on now
23:45imirkin_: and then run glmark2 (and you can kill glxgears)
23:45catphish: what do those lines mean?
23:45catphish: AC is the current state?
23:45imirkin_: each line is a power state. the last line is the current settings.
23:45catphish: and you cant switch it while it's off :)
23:46imirkin_: (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:46skeggsb: it's not just a thought, you can
23:46skeggsb:has been using that for years now
23:47imirkin_: catphish: now run glmark2
23:47imirkin_: skeggsb: i think you're the only one who knows how to make it work
23:47catphish: it doubled my glxgears rate for a start
23:47karolherbst: skeggsb: https://github.com/karolherbst/nouveau/commit/0cd8b3e998e0a421a696a67d4bf524769cc618b8
23:47imirkin_: catphish: glxgears with optimus is mostly a measure of pcie bandwidth
23:47karolherbst: skeggsb: I noticed that my battery hit "a" power budget while running on batteries
23:47karolherbst: and the GPU throttled
23:47karolherbst: with Nouveau
23:47karolherbst: no clue where that comes from
23:48catphish: the same is probably true of glmark2, it may well be the frame copying thats limiting it
23:49imirkin_: (while without optimus, glxgears is a measure of fill rate)
23:49catphish: better, still limited by something, i'll try to find a more demanding test
23:49karolherbst: catphish: it looks like you hit the same bottleneck in all tests :p
23:49karolherbst: pixmark_piano is perfectly demanding
23:49karolherbst: (and triggers intel syncing bugs)
23:49imirkin_: you'll get like 0.01 fps with that
23:49karolherbst: reports 15fps, looks like 4
23:49catphish: karolherbst: yeah, i guess thats my frame copying bandwidth :)
23:50catphish: awesome, still turns the gpu off when it's idle
23:50catphish: this is cool
23:50karolherbst: imirkin_: I got a 200fps result once ... *whistles*
23:50imirkin_: karolherbst: uh huh. where you make the frag shader do nothing?
23:50karolherbst: imirkin_: no, real work
23:50karolherbst: just the right GPU was used :p
23:51imirkin_: and the right driver :p
23:51karolherbst: well right
23:51karolherbst: but nouveau is like 80% compared to blob
23:51karolherbst: at least on kepler
23:51imirkin_: 60-80 on kepler i think
23:51karolherbst: would be strange
23:51imirkin_: gets down to like 50% on GM10x
23:51karolherbst: because you need like nothing for it
23:51karolherbst: only a good compiler
23:51imirkin_: and a good resource manager.
23:51karolherbst: anything else shouldn't be an issue
23:51karolherbst: not even that
23:51imirkin_: we have neither.
23:52karolherbst: why would a resource manager be important here?
23:52catphish: 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:52catphish: now it just seemt to work out of the box with nouveau, so i'm very happy
23:52imirkin_: catphish: yeah, it works nicely in certain scenarios.
23:53catphish: though the manual clocking is a tad tedious
23:53imirkin_: be thankful that it can be done at all
23:53imirkin_: that's a recent addition
23:54skeggsb: and shouldn't have been done because it's incorrect ;)
23:54catphish: well i'm happy :)
23:54imirkin_: skeggsb: you're such a purist... :p
23:54catphish: hopefully this will do for occasional games :)
23:55catphish: i think glmark2 gets more challenging, i'll let it run a while
23:56karolherbst: skeggsb: I think the last thing we talked about was some racy stuff with the therm thing or something though
23:56karolherbst: but I thought I resolved all this...
23:56karolherbst: well, I guess I will retest stuff
23:56catphish: wonder if there's any good linux vr yet
23:57imirkin_: i wouldn't expect too much
23:58karolherbst: skeggsb: I will create a branch with only trivial bugfixes, should be good enough for now