10:11crmlt: i'm trying to fix this in nvidiabl: https://github.com/crmlt/nvidiabl/issues/1
10:12crmlt: any idea why this could happen? Thanks for help.
11:06pendingchaos: imirkin_: do you have a kepler card? if so, can you test https://hastebin.com/raw/inugegecuz?
11:06pendingchaos: arb_shader_image_load_store-semantics and multiple-resident-images-reading.shader_test would probably be enough
11:43imirkin: pendingchaos: while i do have one, it's not currently plugged in
11:44imirkin: crmlt: i'm a little confused as to what nvidiabl is meant for... is it meant for the situation where neither blob nor nouveau are loaded?
11:46imirkin: crmlt: and also, which GPU are you having trouble with?
11:49imirkin: crmlt: looks like your restore function is just writing back the old value. that won't work - these aren't registers, they're function calls. setting value X doesn't mean that you get value X when reading back
11:51crmlt: imirkin: it provides sysfs backlight interface for blob 340
11:52crmlt: imirkin: i see
11:55imirkin: oh wow. so you're basically fighting the blob for control?
11:56imirkin: i'm not surprised that fails
11:56imirkin: i'm sure it has nothing to do with your resume logic - a quick glance suggests that's only called on module unload
11:57imirkin: the blob manages brightness too
11:57imirkin: so it will just write to that register
11:57imirkin: and your driver will have no idea
11:57imirkin: hence your current issue
11:57crmlt: I see
11:57imirkin: the nvidia 340.x drivers definitely let you manage panel brightness SOMEHOW, even if it's not via the backlight interface
11:58imirkin: i don't remember how, of course
11:58crmlt: imirkin: yea it can be managed using XRandR API
11:58imirkin: no, that's something else
11:58imirkin: that's a software brightness
11:58imirkin: not a panel brightness
11:58imirkin: xrandr just adjusts the color LUT
11:58crmlt: i mean something different
11:58crmlt: the way how xbacklight works
11:58imirkin: probably NV-CONTROL
11:59crmlt: and KDE's powerdevil does it too
11:59pendingchaos: anyone with a kepler card and piglit built willing to test a patch?
11:59crmlt: imirkin: I see
12:01pendingchaos: * piglit built and mesa git usable willing to test a mesa patch
12:01imirkin: crmlt: oh hm. maybe it has a "backlight" propery? dunno
12:05crmlt: imirkin: i'm not sure...
12:06imirkin: anyways ... it's a value managed by nvidia
12:06imirkin: when it turns screens on/off it will write it
12:06imirkin: you have no way of being notified when that happens
12:06imirkin: you could poll that register every so often
12:06imirkin: which is equivalent to your current "solution"
12:07imirkin: you just have to be careful not to turn a screen on when it's off
12:07imirkin: of course that's not great for battery
12:07imirkin: interrupts are dispatched when all this happens, but since you're not bound to that device, that doesn't do you much good
12:09crmlt: I see
13:05pendingchaos: imirkin: findings from running the shader tests on the blob: https://hastebin.com/eqozoyuvuh.txt
13:14imirkin_: pendingchaos: so for the things where adding the writeonly qualifiers worked, it'd be nice to add some tests to ensure that not having them DOESNT work
13:15pendingchaos: sounds fine
13:16pendingchaos: how does just leaving the bound-image-cast test as it is sound? it isn't correct glsl but it should test the functionality it is meant to
13:30imirkin_: pendingchaos: why does bound-image-cast not work with writeonly?
13:30imirkin_: pendingchaos: that should probably be, btw,
13:31imirkin_: writeonly image2D fixedTex = image2D(foo)
13:31imirkin_: the qualifiers go with the declarations
13:32pendingchaos: IIRC that doesn't work? I think it said the types were incompatible
13:33imirkin_: maybe writeonly = writeonly? dunno
13:34pendingchaos: adding writeonly to the cast doesn't seem to fix it
13:35imirkin_: so writeonly image2D foo = writeonly image2D(uvec2) doesn't work either? :(
13:35imirkin_: HdkR: i blame you.
13:38pendingchaos: it doesn't work
13:40imirkin_: HdkR: as the resident bindless expert... suggestions?
13:40imirkin_: pendingchaos: generally the guys who wrote the ext are listed at the top and will often answer well-thought-out questions
13:46HdkR: er, let me settle in, moment
13:46imirkin_: wow you get up early
13:47HdkR: Hm, curious. I'm shocked that cast wouldn't work.
13:47HdkR:loads up compiler
13:51HdkR: imirkin_: You should know that I'm always around, watching
13:52imirkin_: waiting for someone to mention dual-source blending
13:54imirkin_: HdkR: this is the shader: https://hastebin.com/biyavosahu.pl
13:54imirkin_: that doesn't work, but we're trying to figure out what will
13:57HdkR: Don't you need to specify the layout in the cast?
13:57imirkin_: writeonly should be enough, no?
13:57HdkR: Oh wait, writeonly and without formatted, right
13:57imirkin_: the claim is that "writeonly image2D fixedTex = writeonly image2D(bla)" is not enough.
13:58HdkR: Curious that the blob also seems to confirm that, but it shouldn't be necessary
13:58imirkin_: i meant "the claim is that the blob says that ..."
13:59HdkR: Right :)
13:59imirkin_: since there are no conformance tests, and it's a complex spec, it's basically the true reference here =/
13:59HdkR:checks if there is any extra wordage in the spec for it
13:59HdkR: The cast portion is fairly...lacking
14:00imirkin_: "casts are allowed. yay!"
14:00HdkR: Might as well as say templating is allowed in a similar fashion
14:00imirkin_: finally :p
14:01imirkin_: should do it the same way that all the preprocessor stuff is defined
14:01imirkin_: i.e. that thing tells you to look at C99
14:01imirkin_: for tepmlates, just look at C++11
14:04HdkR: I think this is an oversight from the blob
14:05HdkR:checks if it happens on loads as well
14:06HdkR: Yep, happens with loads as well with _formatted
14:06HdkR: bweh, I'll bring it up
14:30HdkR: imirkin_: Bug submitted for you
14:30imirkin_: HdkR: thanks :)
14:31HdkR: Pretty sure the intent is to allow the cast without having to explicitly state the format qualifier though
14:32HdkR: Same with readonly when _formatted is supported
14:42pendingchaos: imirkin_: I guess I'll include writeonly on both the cast and declaration?
14:44pendingchaos: oh wait that doesn't work with mesa
14:48imirkin_: pendingchaos: well, ideally you'd make mesa work with "writeonly image2D foo = image2D(bar)"
14:48imirkin_: i don't think the *cast* needs qualifiers
14:48imirkin_: but i guess i dunno for sure.
14:48imirkin_: HdkR: --^
14:48pendingchaos: qualifiers should probably be allowed on casts
14:49pendingchaos: for things like imageLoad(layout(rgba8) image2D(uvec2(...)), ...)
14:49imirkin_: yeah ...
14:49imirkin_: ok yeah
14:49imirkin_: the cast has to be able to be part of the r-value
14:49imirkin_: but parsing that properly seems tricky
14:49pendingchaos: the spec is vague about it though
14:50pendingchaos: "the cast has to be able to be part of the r-value"?
14:50imirkin_: what if you do
14:50imirkin_: writeonly image2D foo = layout(rgba8) image2D(bar)
14:50pendingchaos: the qualifiers have to be part of the type?
14:52imirkin_: i guess
14:52imirkin_: but what if you do like layout(rgba8) uvec2(foo). or layout(rgba8) foo + bar
14:52pendingchaos: that would be wrong
14:52imirkin_: all kinds of non-sensical that can happen there
14:52imirkin_: i agree that that would be wrong
14:53imirkin_: but making it actually wrong but the other thing right can be difficult
14:54pendingchaos: I have some changes in the works for those sort of things
14:54pendingchaos: it's not finished though and I got distracted by this bindless thing
14:55HdkR: imirkin_: What's more confusing is the blob doesn't require the read/writeonly qualifier on the left hand side
14:56HdkR: Or at least doesn't seem to need it...
14:56HdkR: It's too friggin vague
15:31pendingchaos: imirkin_: did you get this btw: https://lists.freedesktop.org/archives/mesa-dev/2018-June/196860.html?
15:31imirkin_: i did
15:31imirkin_: great catch
15:31imirkin_: i just haven't had a ton of time to properly check patches
15:31imirkin_: also the git repo for mesa just got migrated
20:26unraised: I have two NV50 cards (NVS 290) with 3 montors on a workstation. Fedora 28 and Rawhide switched from x11 to wayland, but now I can only see gui output on the primary display. The two displays on the second card are blank, but I can move my mouse between all three. I can even drag windows between all three, but they disappear when traversing the blank screens.
20:27unraised: It looks like multicard is supported for NV50, so is this most likely a bug in gnomes wayland (mutter)?
20:27imirkin_: remind me what NVS 290 is? G98?
20:27unraised: G86 I believe
20:27imirkin_: can you see if there are any horrible errors in dmesg?
20:28unraised: There does appear to be errors scrolling by in dmesg/journalctl
20:28imirkin_: care to share?
20:29unraised: DATA_ERROR 12 [RT_LINEAR_WITH_ZETA] summarizes a few of them by the looks of it.
20:29imirkin_: yeah, can't do that.
20:29imirkin_: so what's going on is that someone is trying to draw to a linear rendertarget (as one would be when it's being shared between GPUs), with a depth buffer attached
20:30imirkin_: while that's not technically illegal in the GL sense, in the practical sense nouveau doesn't handle this scenario
20:31imirkin_: maybe reach out to the wayland compositor authors and see if they can avoid doing that
20:31unraised: Awesome, thank you! I'll likely quote you in my bug report to gnome's mutter project.
20:32unraised: (If that's ok with you.)
20:32imirkin_: go for it.
20:32imirkin_: note that i'm not 100% sure how all the EGL integration stuff is meant to work
20:32imirkin_: but to save you some anticipation, they'll just tell you "go fix your driver"
20:33imirkin_: so might as well just use X and move on with life.
20:47diogenes_: is there any advantage at all in using wayland+nouveau comparing to xorg+nouveau? are there any benchmarks or something?
20:49imirkin_: wayland gives you the ability to have frame-level perfection which xorg does not
20:50imirkin_: there's also various security-type enhancements (like apps can't pick up events from other apps)
20:50unraised: imirkin_: do you think nouveau will ever support that scenario (linear rendertarget with depth buffer)? Is it a limitation of the understanding of the closed drivers?
20:50imirkin_: unraised: well, the hardware just can't do it. however the driver could be made to work around it.
20:51diogenes_: imirkin_, thanks for the info.
20:59imirkin_: of course wayland loses you networking
20:59imirkin_: and forces you onto vnc-style stuff
21:00imirkin_: i don't expect to use wayland myself ... at least for a very long time
21:01diogenes_: it turns out that after 10 years wayland is still beta and what do you mean by "loses networking"?
21:02imirkin_: like in X, you can run a remote client against a local X server
21:02diogenes_: oh i see
21:02imirkin_: not all X clients will be happy with such an arrangement
21:03imirkin_: but the software i use seems fine