02:20 pq: imirkin, oh, bummer. Was it because nv96 reclocking wasn't worth maintaining or?
02:27 pq: imirkin, at least good news from upgrading 3.16.3 to 4.1.3 is that nothing seems to have regressed on nv96, even the (unimplemented?) HDMI audio works still. :-)
02:29 pq: I suppose http://nouveau.freedesktop.org/wiki/PowerManagement/ could use a note that reclocking has been removed for some.
05:38 kaan: how do i enable dri3 on nouveau? I get "(WW) NOUVEAU(0): Option "DRI3" is not used", is it hardware dependent?
05:53 pq: does anyone recall any GL bugs, that might cause random green or inverse color pixels (live noise, like analog static), possibly related to multisampling?
06:22 mlankhorst: pq: yeah, poor hdmi cable :-)
06:25 pq: mlankhorst, it's definitely not cable-related. I can take screenshots of the noise. :-p
06:25 pq: http://picpaste.com/pics/OWD-green-noise-1e2dNoDb.1437916911.png
06:30 glennk: pq, does that happen without the occulus postprocessing?
06:30 glennk: actually scratch that, its obviously from that pass
06:30 pq: glennk, I have no idea (how to even try)
06:31 glennk: some dither pattern it adds, at a guess values are turning into NaNs
06:31 pq: it's the OWD demo the the Oculus SDK
06:32 pq: time to file a bug with apitrace?
06:32 pq: ..attached
06:32 glennk: try it with llvmpipe etc
06:34 pq: ah, of course.
06:39 pq: yup, no green noise with swrast (whichever implementation it happens to load)
08:01 RSpliet: imirkin: Adreno A3xx is a scalar processor?
08:01 RSpliet: or rather: has scalar processors?
08:02 RSpliet: ...or rather: doesn't have vector-units?
08:02 RSpliet: phew, quite difficult to avoid ambiguity here
08:05 glennk: a3xx and onwards are scalar
09:04 RSpliet: glennk: thanks
09:05 imirkin: pq: i'm aware of a wine bug that causes various noise in all mesa drivers, except swrast since they tend to initialize unknowns
09:06 imirkin: pq: although that particular bug looks more reminiscent of "this looks like a long loop, why don't i just stop executing in the middle of it and see how things go" issue
09:06 imirkin: pq: unfortunately i have *no clue* why it happens
09:08 imirkin: pq: oh, one last one... there's this bug: https://bugs.freedesktop.org/show_bug.cgi?id=90887 but usually the artifacts are much heavier from it
09:08 RSpliet: imirkin: wrt bug loop, can that not be a more generic (watchdog) "timeout failure"?
09:13 imirkin: RSpliet: sure, it can. but playing with the watchdog feature we're aware of has been unsuccessful
09:13 imirkin: clearly there's one that we're not aware of, but... nvidia hasn't been forthcoming with it
09:14 Karlton: 18
09:15 imirkin: 73!
09:16 Karlton: meh, I need to disable mouse from bringing windows into focus
09:22 RSpliet: imirkin: tried unrolling one of those bad boys and see what happens? there are no code size limitations, are there?
09:22 imirkin: RSpliet: not sure. hard to unroll when there's a conditional break
09:25 RSpliet: you mean in glsl? you can still wrap it in a while(0) loop and use break I reckon?
09:25 RSpliet: gheh, more like a do{}while(0) loop of course
09:28 imirkin: RSpliet: right. not impossible. just hard/annoying.
09:28 imirkin: RSpliet: and no, i haven't tried
09:28 RSpliet: annoying, got it :-D
09:36 imirkin: RSpliet: you're more than welcome to, of course
09:37 RSpliet: I know I am :-)
09:37 imirkin: RSpliet: i did try a few different ways of generating the code (e.g. without using prebreak and thus the call stack), but while some of the specific corruption was a little changed, it didn't resolve the overall problem
09:41 imirkin: RSpliet: have you played more with pre-nva3 reclocking?
09:41 tobijk: you guys are too productive, i have to rebase every single cull patch ;-)
09:42 imirkin: tobijk: probably the bool thing?
09:42 imirkin: and/or inlines
09:42 RSpliet: imirkin: not really, I ran out of GPUs
09:42 tobijk: nah the tess changes :-)
09:42 imirkin: RSpliet: haha. nva0 is the only one you had?
09:43 RSpliet: yep
09:43 RSpliet: the rest is all broken
09:43 imirkin: doh
09:44 RSpliet: I think mupuf should come to Cambridge and restock me :-P
09:44 imirkin: top you up? :)
09:45 imirkin: RSpliet: look for a lug, perhaps people would be willing to donate to the cause
09:46 RSpliet: yeah... I will probably resend the one patch I e-mailed two weeks ago
09:46 RSpliet: since there's no R on the RFC, it seems to be all right :-P
09:52 imirkin: actually, there's no C
11:55 acer-laptop: Hi. I've got an annoying problem with an old NV4E (C51) GeForce 6100 (Go) and nouveau. Basically everything works, even Games look good. Only at seemingly random times the screen freezes up completly and I have no other choice than to reboot pc.
11:56 imirkin: acer-laptop: pastebin dmesg
11:56 acer-laptop: That said, it doesn't freeze in normal usage, only when playing games or webgl in browser is activated
11:57 imirkin: well, the brutal reality is that the 3d driver for pre-nv50 cards is... shall we say... lacking
11:57 imirkin: however none of that ought to hang the card
11:58 acer-laptop: imirkin: okay, moment...
11:58 imirkin: there was a short period of time when we were turning on MSI for nv4e, but that turned out to be a bust
11:58 imirkin: and doing a few other things wrong too
11:59 imirkin: there are also outstanding patches (not pushed to upstream linux yet) which fix potential segfaults (in the kernel, so... bad) for pre-nv50 gpu's
11:59 imirkin: however those would only happen under very specific conditions
12:01 acer-laptop: imirkin: ok, uploaded current dmesg http://www.pastebin.ca/3077441
12:02 imirkin: acer-laptop: ok cool, looks like you don't have one of the kernels where we had MSI enabled
12:07 acer-laptop: imirkin: if I had to guess, it might be somehow related to power managment. the screen freeze while still random seems to happen more often if gpu clock goes down from high.
12:07 imirkin: acer-laptop: gpu clock doesn't change
12:08 acer-laptop: imirkin: well, wrong guess then ;-)
12:08 imirkin: and it looks like we never worked out gpu clock stuff for the nv4x igp's
12:12 acer-laptop: imirkin: well, I asumed it since different core clock are shown in dmesg.
12:14 imirkin: acer-laptop: yeah, we decode what the vbios says, but not much more apparently
12:15 imirkin: acer-laptop: for the discrete gpu's in the nv4x we actually do support manual clock speed changes
12:16 acer-laptop: imirkin: I see.
12:24 acer-laptop: is there anything more info I could provide?
12:25 imirkin: sorry, i have no idea why you're getting the issue :(
12:25 imirkin: acer-laptop: you could try a newer kernel, but i dunno if that'd help
12:25 imirkin: acer-laptop: also getting logs from when the issue happens could prove useful, e.g. by ssh'ing in
12:26 acer-laptop: imirkin: what logs specificaly?
12:28 imirkin: acer-laptop: dmesg
12:29 acer-laptop: imirkin: that I can do ;-) I don't want to provoke a freeze right now since I'm still doing stuff but I'll be back this week.
12:30 imirkin: acer-laptop: although tbh i've never had too much luck debugging freezes
12:31 acer-laptop: imirkin: nobody is perfect. I don't expect a fix I'll hope it's easy tho
13:34 CMEPTb: how can i verify that 0a pstate is on?
13:35 imirkin: cat pstate, look at the -- line
13:35 imirkin: (or AC/DC in newer kernels)
13:36 CMEPTb: # cat /sys/class/drm/card0/device/pstate
13:36 CMEPTb: 07: core 405 MHz memory 648 MHz
13:36 CMEPTb: 0a: core 405-1032 MHz memory 1620 MHz
13:36 CMEPTb: 0e: core 405-1293 MHz memory 7010 MHz
13:36 CMEPTb: 0f: core 405-1293 MHz memory 7010 MHz
13:36 CMEPTb: AC: core 405 MHz memory 648 MHz
13:36 CMEPTb: what is the -- line?
13:36 CMEPTb: i'm on 3.18
13:36 imirkin: AC
13:36 CMEPTb: ac?
13:37 CMEPTb: what does that mean?
13:37 imirkin: alternating current
13:39 CMEPTb: (or AC/DC in newer kernels) <- what does this mean
13:39 imirkin: AC = alternating current
13:39 imirkin: DC = direct current
13:39 imirkin: in general are you on wall power or battery
13:42 CMEPTb: wall power...
13:42 CMEPTb: it's a desktop
13:42 imirkin: good thing it says AC :)
13:42 CMEPTb: isn't there a way to view the memory freq ?
13:42 CMEPTb: or are you telling me that i need to figure out how much voltage my vid card is consuming?
13:43 imirkin: i'm telling you that you need to look at the line that says "AC"
13:43 CMEPTb: a line? in what file?
13:43 imirkin: pstate.
13:43 CMEPTb: i just pasted the entire pstate file. there is no line that says AC on it, or --
13:43 Samsai: CMEPTb, "AC: core 405 MHz memory 648 MHz"
13:43 imirkin: you're joking right?
13:44 CMEPTb: ohhhhmg
13:44 Samsai: right up there
13:44 CMEPTb: so it didn't go to 0a state?
13:44 Samsai: it didn't
13:44 imirkin: CMEPTb: check dmesg, it'll probably tell you some error relating to voltage
13:45 CMEPTb: echo 0a /sys/class/drm/card0/device/pstate <- is this right?
13:45 imirkin: feels like a > missing in there somewhere
13:45 CMEPTb: oh derp
13:45 CMEPTb: 0a: core 405-1032 MHz memory 1620 MHz AC DC *
13:45 CMEPTb: yay
13:46 CMEPTb: um sorry i just woke up and not yet braining good i guess
13:46 CMEPTb: thanks
13:48 imirkin: CMEPTb: don't trust that * entirely... look at the line that starts with AC
13:48 CMEPTb: well, 0a got rid of my video issues. no more skipping on a 5gig blueray, and the annoying sheer at the top that's always been there is also gone
13:49 CMEPTb: AC: core 1032 MHz memory 1620 MHz
13:49 CMEPTb: yay nouveau! you guys rock
13:49 imirkin: cool
13:54 RSpliet: \m/
13:59 karolherbst: mhh
13:59 karolherbst: ahh no, the freq is right for 0a
14:00 imirkin: karolherbst: btw, demmt should be fixed for traces with new blob now
14:00 karolherbst: yeah, I saw a new commit there
14:00 karolherbst: just assumed it was for that
14:01 karolherbst: so they added a new memory ioctl
14:01 imirkin: new version of it... same data... basically
14:01 karolherbst: with two unkown fields?
14:01 karolherbst: ohh three
14:02 karolherbst: yeah okay
14:02 karolherbst: so nothing special
14:02 karolherbst: imirkin: maybe uvm related?
14:02 imirkin: karolherbst: actually 30 :)
14:02 karolherbst: not 34?
14:03 imirkin: wtvr
14:05 karolherbst: mhh 352 added GLX sutff for GL_ARB_copy_buffer and GL_ARB_texture_buffer_object
14:09 karolherbst: regarding the pmu stuff on my kepler card: no clue, reg used only once and nothing between the calls
14:09 karolherbst: seems pretty static to me
18:01 acer-laptop: imirkin: I haven't made a log for screen-freezing yet. this log show some interesting thing still. http://pastebin.ca/3078077
18:05 acer-laptop: TTM seems upset and it's wierd to see LVDS script spawn.