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