08:09anYc: Hi, is reclocking useable with NVC0/Fermi? I am using nouveau but never had high demands - just normal desktop apps - but now I need some 3D apps from time to time. Should I switch to the binary drivers? I wouldn't mind switching the levels manually.
12:40pendingchaos: imirkin or someone who understands GM107+ instruction scheduling: can you explain this?: https://hastebin.com/imojohetew.txt
12:41pendingchaos: (full shader assembly with instructions of previous paste indented in case it's interesting: https://hastebin.com/humivasoca.txt)
12:49RSpliet: anYc: currently not I'm afraid. Existing code in various places is WIP and/or stalled in the wake of limited people-power and varying priorities (like Volta bring-up)
12:59diogenes_: Hi guys, i'm trying to run wine game with DRI_PRIME=1 in terminal and i'm getting: libGL error: unable to load driver: nouveau_dri.so
12:59diogenes_: but the game starts and i don't know whether it's still using nouveau or intel?
13:00diogenes_: the full output: http://termbin.com/dx7h
13:18RSpliet: diogenes_: or worse, it might fall back to software rendering ;-)
13:19RSpliet: diogenes_: can you try something simpler first... like DRI_PRIME=1 glxinfo - and see if it reports nouveau rendering or llvmpipe/softpipe/whatever software fall-back?
13:19diogenes_: RSpliet, i ran verbose and it turns out it looks for it in /usr/lib/dri/nouveau_dri.so but on my system it's located in /usr/lib64/dri/nouveau_dri.so
13:19diogenes_: i'll try ln -s
13:20RSpliet: Well, I was about to type... you might want to also install the 32-bit version of nouveau dri
13:20RSpliet: As this is likely required by wine and a lot of steam games and the likes
13:20diogenes_: cool let me try that
13:21RSpliet: The paths make me suspect it's a centos or fedora system? Shouldn't be a pain to do that
13:21diogenes_: RSpliet, openSUSE :)
13:21RSpliet: ah fair enough! I've got blinders on that limit my world to debian/ubuntu and redhat/fedora :-P
13:24diogenes_: RSpliet, YAY!!! just installed Mesa-dri-nouveau-32bit and it works, thanks a lot!
13:25RSpliet: No worries
13:26RSpliet: Which graphics card are you playing with, if I may ask?
13:26RSpliet: oh nm, you've already discovered pstates, so I guess something something Kepler or marginally newer ;-)
13:27diogenes_: RSpliet, GeForce GT 650M
13:27RSpliet: Yeah, I got a discrete one of those in my office. That's a nice card for nouveau
13:27diogenes_: yes it is
13:28diogenes_: running nouveau with =15 power mode gives me almost the same performance as with proprietary nvidia, only 2 fps difference
13:28RSpliet: You might want to install a newer kernel than 4.4 though, there's been some pstate work since that lets you squeeze even more performance out of it (by playing with different boost settings. If you're truly curious karolherbst can probably tell you some more about that)
13:29RSpliet: Depends on the game, but yeah, nouveau can be pretty good for stuff with relatively simple shaders.
13:29RSpliet: ... oh god I wish I had time for nouveau again :-C
13:30diogenes_: RSpliet, later this month my distro will upgrade to 4.16 so till then i'm pretty much satisfied with the nouveau driver, thanks guys for a good job, i'll make a donation in the future.
13:30RSpliet: Only hardware donations are accepted I think ;-) But no sweat, glad you can use your laptop pain-free!
13:31diogenes_: :) yes, all open source, no proprietary nvidia, that's an awesome work!
13:46diogenes_: i was asking yesterday if there is any kind of nouveau monitoring tool (gpu utilization ans so on) and as i was told, there isn't one and indeed there isn't but i've found a different way
13:48diogenes_: my solution is to run: sensors, if no application is using nouveau, then you get GPU core: N/A, temp1: N?A, but, if there is a running application that uses nouveau, then running sensors it showed me: GPU core: +1.01 V and temp1: +62.0°C.
13:50RSpliet: diogenes_: this is correct. When no application uses the card it's sent into a deep sleep mode, deep enough not to be able to read out the sensors without waking it up ;-)
13:51diogenes_: RSpliet, yes i know, that's why i love optimus, no need to use morepower than it's necessary.
13:52RSpliet: Not sure if a newer kernel has different behaviour, but its undesirable to burn power waking up a sleeping device just to discover its temperature, which we know isn't going to exceed its threshold because unlike humans, chips cool down massively when they're asleep :-P
13:58diogenes_: RSpliet, actually on ubuntu, nouveau is the only option now to use optimus technology in the right way, afaik the newer kernel don't support bumblebee anymore so you should have that pain called PRIME when you switch to the card you want to use, the re-log to apply the changes and that sucks, so nouveau is the best option.
14:12RSpliet: I thought ever since nvidia implemented a proper drm driver, that shouldn't be a problem anymore? Idk, never tried tbh
14:22diogenes_: RSpliet, i personally don't like nvidia's implementation, it turns out that few people who worked on opensource nouveau, did a lot much better work than nvidia's army of well paid developers.
14:48anYc: RSpliet: ok, thank you
14:59imirkin: pendingchaos: did you work it out, or need some help?
15:07karolherbst: mupuf: I have now a spare laptop I could use for CI with a nve6 :)
15:13pendingchaos: no, I have not
15:14pendingchaos: would anyone be interested in a patch that allows you to dump both the binaries and the tgsi of shaders and replace the binaries with one's own?
15:16pendingchaos: (binaries = input of envydis, output of envyas btw)
15:21pendingchaos: (like MESA_SHADER_*_PATH in https://www.mesa3d.org/shading.html)
16:06imirkin: pendingchaos: yes, that'd be awesome
16:07imirkin: something would have to be worked out for number of gpr's
16:07pendingchaos: would just setting it to 254 be fine?
16:09imirkin: i guess yeah
16:09imirkin: or max allowable by isa
16:10imirkin: oh, except for compute =/
16:10imirkin: invocations * num gpr <= global gpr file size
16:16pendingchaos: I think I'll do target->getFileSize(FILE_GPR)
16:16imirkin: it doesn't have to work 100% of the time, at least initially
16:17pendingchaos: I assume setting it to 255 would be fine (asking since register 255 seems to be a zero register)?
16:17imirkin: yes, i think so
16:19mupuf: karolherbst: laptops are a little annoying to deal with when they crash
16:19mupuf: but that's a good start for mesa testing
16:19karolherbst: mupuf: I am aware
16:19mupuf: with RSpliet, we used the docking connector to be able to press the power button
16:19karolherbst: mupuf: but you know my old laptop, no?
16:19mupuf: oh, right :D
16:19karolherbst: I think I will have no problem adding some additional hardware to it :D
16:20mupuf: but if you get the battery out and you use a power cutter like intel-gfx-ci does, you can easily make it work
16:20karolherbst: I only need to wire up the power button, no?
16:20mupuf: nope. there is a bios option to boot when the power comes back
16:20karolherbst: I see
16:21mupuf: and I was surprised to find out that this is pretty universal
16:21karolherbst: I think the firmware/EC of that laptop is pretty much messed up anyway
16:22pendingchaos: imirkin: it seems setting it to 255 breaks things actually, so I'll cap it at 254
16:24pendingchaos: maybe things are similar cards that have smaller gpr files
16:26imirkin: last gpr is always zero on all G80+ isa's (which is what codegen deals with)
16:53imirkin: pendingchaos: i looked at your shader ... doesn't seem like there's anything obvious in there. it's overwriting the result of the suld (r4..r7) with r5, but the suld has a wr 0 (write dep bar), and the mov $r5 waits on that barrier, so ... odd.
16:53imirkin: perhaps the st has to be higher in the suld?
16:53imirkin: could also start sticking yl all over the place -- afaik blob always does yl
16:53imirkin: (yl = yield)
16:57pendingchaos: changing the suld's (st 0x1 wr 0x0) to (st 0x2 wr 0x0) seems to fix the issue
16:58pendingchaos: not sure why, why did you suggest it?
16:58imirkin: well, you said that sticking a nop in there worked
16:58imirkin: which does nothing, but you had (st 0x1) there
16:59imirkin: 1+1 = 2, so ... :)
17:00imirkin: it definitely goes a little counter to my understanding of how this stuff works
17:01imirkin: i forget how the barriers get reset
17:01imirkin: iirc if you do (wr 0x1) and then a bunch of (wt 0x0), it all works out
17:01imirkin: question is ... what happens if you do (wr 0x1) (wr 0x1) -- does the write wait for the previous barrier to be signaled?
17:02imirkin: basically what causes the signaled -> not-signalled transition
17:02pendingchaos: I've got to go, I'll be back in ~2 hours or so
17:03imirkin: k, ttyl
17:03imirkin: hakzsam: do you remember this stuff clearly in any way?
17:05imirkin: pendingchaos: https://github.com/NervanaSystems/maxas/wiki/Control-Codes
17:05imirkin: "Barriers take one additional clock cycle to become active on top of the clock consumed by the instruction doing the setting. So you may need to also use a stall count of 2 if you intend to wait with the subsequent instruction."
17:05imirkin: probably need to adjust the auto-sched-code generator
17:05imirkin: if that rule's not there already
17:06karolherbst: you are hitting a bug inside the sched calculator?
17:07imirkin: not sure
17:07imirkin: i think he may have been doing this by hand
17:08karolherbst: I see
17:08karolherbst: imirkin: anyway, ping on that RA regression ;)
17:09imirkin: let's assume i have no recollection of "that"
17:09imirkin: care to remind me?
17:10karolherbst: you know, that return; thing
17:10imirkin: oh right yes
17:10imirkin: let me have a look
17:10pendingchaos: the failing code is generated with some nops thrown in
17:10pendingchaos: I think there was also mention of stalls >12 needed a yield flag in there too? I'm not sure if the sched calculate takes than into account
17:10pendingchaos: (I probably won't be available for long)
17:10imirkin: pendingchaos: yes, there was such a mention
17:10imirkin: and yes, i don't think it does
17:11imirkin: but iirc blob just throws yield flag in everywhere nowadays
17:11imirkin: i guess they decided it was beneficial in the average case too
17:13karolherbst: imirkin: or doesn't matter
17:14imirkin: karolherbst: you got an example of the RA fail?
17:14karolherbst: imirkin: everything which spills
17:15karolherbst: but I don't think I have any glsl example
17:15imirkin: got a concrete example? :)
17:15karolherbst: but should be failry easy to trigger
17:15karolherbst: just load something where you have more than 255 live values
17:16imirkin: yeah that stinks. but i could reduce the reg count
17:16imirkin: to e.g. 8
17:16karolherbst: ohh, yeah
17:16karolherbst: but this might cause other issues
17:16imirkin: and what's the failure?
17:16karolherbst: RA fails
17:16karolherbst: no spill candidate
17:17imirkin: poof. where'd he go...
17:19imirkin: so anyways... because i move the def right next to the merge
17:19imirkin: if the merge can't spill, then that *effectively* means that its args can't spill
17:20imirkin: (they can, but it won't do any good to reducing register pressure)
17:20imirkin: so the question is ... will this be OK for the tex
17:20imirkin: on nv50
17:21karolherbst: I can check on a tesla GPU if the stuff is still fixed though
17:21imirkin: i have one plugged in
17:21imirkin: i just need to think for a bit
17:22imirkin: question is -- should that noSpill thing just get dumped entirely
17:22mangix: quick question, is inability to turn the display back on after the screen gets blanked by GNOME a known issue?
17:23mangix: should I try debugging with nouveau.debug?
17:23imirkin: you could describe the issue...
17:25mangix: so GNOME blanks the screen after 5 minutes. Moving the mouse or pressing keyboard buttons or really anything doesn't turn the screen back on
17:25mangix: the good news is, no kernel panic or anything so I can do ctrl+alt+f7 and ctrl+alt+del to restart the system safely
17:26mangix: screen comes back of course
17:27imirkin: anything in xorg log?
17:28imirkin: what about ctrl+alt+f1 and then ctrl+alt+f7 (or f4 or whatever vt X is on by default)
17:28imirkin: also what GPU is this?
17:31mangix: maxwell 980
17:33imirkin: mangix: and how are the screens connected?
17:34mangix: this is a laptop, so eDP
17:34mangix: this is not a 980m btw
17:35imirkin: ok. do you have an xorg log from after the problem happens?
17:36imirkin: and do you have a second computer?
17:37mangix: no and yes
17:38mangix: i can get one
17:41imirkin: well if you ssh in while the issue is occurring
17:41imirkin: then it's easier to figure out wtf is going on
17:41mangix: oh I see
17:41imirkin: oh, also are you using a recent kernel?
17:41imirkin: if not, i think some people had various issues
17:41imirkin: ok, 4.16 should be good
17:41imirkin: although SOMEONE had issues with a GM204 actually
17:41imirkin: (was it you?)
17:41imirkin: retrieving EDID
17:41mangix: no. I have not been in here for almost a year
17:42imirkin: although stuff like dpms is similar
17:42mangix: I did report an i2c bug a while back
17:42mangix: which got fixed
17:42imirkin: right yeah
17:42mangix: an not me
17:42imirkin: but someone's reporting issues with that fix
17:44mangix: so 13a86519202c5d119d83640d6f781f3181205d2c did indeed fix nouveau for me
17:47mangix: in any case this seems like a different issue
17:50imirkin: pendingchaos: looks like the sched calculator takes care of this -- https://hastebin.com/ajisivamil.php
17:56mangix: so screen is not turning on
17:57imirkin: are you ssh'd in?
17:57imirkin: [from another box]
17:57mangix: bah i forgot to turn ssh on
18:01mangix: k screen is off
18:02imirkin: remembered to turn ssh on this time? :)
18:02mangix: yeah i did. it's woeking
18:02imirkin: cool. so now grab the xorg log, and put it up in a hastebin
18:04mangix: oh wait. I'm running wayland
18:04mangix: there's no Xorg.log file
18:04imirkin: sorry, can't help =/
18:04mangix: will redo on X
18:04imirkin: [not that i have anything against people using wayland, i just know nothing about how to operate or debug it]
18:05imirkin: you could ask in the wayland support chans for assistance perhaps? not sure.
18:08mangix: Well, same thing happens on X
18:10mangix: imirkin: https://pastebin.com/XNUsiSM6
18:11mangix: screen blank is set to a minute
18:11mangix: hence the 154 enty
18:13imirkin: mangix: DISPLAY=:0 xrandr
18:13imirkin: (pastebin results)
18:16imirkin: mangix: ok, let's try this: DISPLAY=:0 xrandr --output eDP-1 --off and then DISPLAY=:0 xrandr --output eDP-1 --auto
18:19mangix: still nothing
18:19mangix: i'm assuming no root needed
18:19imirkin: mangix: DISPLAY=:0 xrandr -s 1920x1080
18:22mangix: the screen is black
18:22mangix: the backlight isn't even on
18:22imirkin: i wonder if that's it
18:22imirkin: can you kinda tell if things are displaying despite the lack of backlight?
18:23imirkin: (e.g. shine a flashlight onto the screen if you got one)
18:24mangix: the screen is no different than if the laptop were off
18:24imirkin: check if you have a backlight property
18:24imirkin: like in /sys/class/backlight
18:24imirkin: or something
18:24imirkin: and see if you can flip it on manually
18:24mangix: when the dimming happens, first is becomes black with the backlight turned on
18:24mangix: then the backlight turns off
18:25mangix: there's an nv_backlight yes
18:26imirkin: is there stuff in there?
18:26mangix: yeah there's an entry called bl_power
18:26mangix: i'm trying to flip it to 1
18:27mangix: sudo echo 1 > bl_power is giving me permission denied
18:27imirkin: yeah... is there anything else in there?
18:27imirkin: sudo su -
18:27imirkin: then echo
18:28imirkin: or some people cleverly do echo 1 | sudo tee bl_power
18:28imirkin: i just like having root shells around instead of dicking around with sudo
18:31mangix: i agree, but fedora decided to get rid of it like ubuntu
18:31mangix: i tried setting bl_power to 1
18:31mangix: bl_power of 0 is supposed to be on
18:32imirkin: normally there's a brightness setting
18:32mangix: yeah it's set to 61
18:32mangix: both actual and brightness
18:32imirkin: so when did this happen?
18:33mangix: after GNOME blanked the screen
18:33imirkin: i meant more like ... after upgrading what
18:34mangix: that...is an interesting question. I think I've always had this problem. I just worked around it by disabling screen blanking in GNOME
18:34imirkin: ah. super.
18:34imirkin: well, it'd probably be interesting to get a debug session of the blanking/unblanking stuff
18:34imirkin: skeggsb is the one who really understands this stuff
18:34imirkin: so try to get his attention.
18:34mangix: will do
18:35imirkin: he's in australia, so he's likely still asleep
18:35mangix: what was the kernel command line again?
18:35imirkin: [and tends to not be around on weekends]
18:35imirkin: you could try like nouveau.debug=i2c=debug,disp=debug drm.debug=0x1e
18:47mangix: output created
18:47mangix: let's see what's in there...
18:49mangix: no idea
18:51mangix: so from what I can tell, nouveau thinks the screen comes back on
18:53mangix: 40 > 45 is where I move the mouse
20:06pendingchaos: turns out another difference (aside from adding the nops) from the code I gave and what was generated was that I added the (wt: 0x1) and then forgot about it
20:07pendingchaos: so the code that was actually being generated is: https://hastebin.com/idexupafiw.txt
20:08pendingchaos: it seems the code generator is failing to recognize that the "mov" needs a barrier to wait for the suld to finish
20:09pendingchaos: perhaps SchedDataCalculateGM107::firstFirstUse() should check both "insn"'s sources and definitions?
20:09imirkin: so ... internally it knows that that's $r4q right?
20:09imirkin: this is a WaW
20:10pendingchaos: that suld writes to r4-r7? yes
20:10pendingchaos: I think WaW is correct
20:10imirkin: so it should detect that
20:10imirkin: and throw in a barrier
20:10imirkin: if it doesn't, that's bad :)
20:14pendingchaos: does the modification of findFirstUse() solution sound good?
20:24imirkin: pendingchaos: pppprobably. yes.
20:24imirkin: would have to check where else it's called
20:25gnarface: so, supposedly some new version of the Spectre attack can "reveal firmware secrets" ... does that mean there's a chance this could be used to provide insight into the nvidia binary blob and/or firmware that wasn't possible before?
20:25pendingchaos: just at write barrier creation and placement
20:26imirkin: gnarface: no.
20:26gnarface: oh, drat
20:29imirkin: pendingchaos: yeah, looks like modifying findFirstUse to essentially contain findFirstDef makes sense
20:30imirkin: to prevent WaW in general
20:30pendingchaos: I don't think I'll literally use findFirstDef() in findFirstUse() btw
20:34imirkin: right, that won't work exactly
20:34imirkin: either refactor, or just copy. wtvr.
20:34imirkin: i'm not picky
20:34imirkin: comment update would be nice though
21:05pendingchaos: imirkin: both the WaW and shader dump/replacement patches sent
21:05pendingchaos: forgot to add "nv50/ir: " or something for the WaW though
21:14imirkin: ok thanks