00:31 imirkin: skeggsb: there have been a few others too i believe
00:36 skeggsb: the bisection of the commits is fault too btw, the commits were applied to 4.11 in the wrong order
00:37 skeggsb: (assuming that's where the bisect got done, it's in the right order in linus' tree)
00:44 skeggsb: in any case, i'll try and come up with *something* today, even if i can't reproduce, i'll try and come up with some random fixes to try
01:01 imirkin: cool. maybe i'll even have time to swap the nv5/nv1x into my box to test out the overlay stuff. i found a few small issues i've fixed already...
01:10 commanderkeen: after switching to nouveau my system has been freezing from time to time. I have to restart the machine. I'm using 2 GPU and a total of 6 monitors. I use xrandr --setprovideroutputsource to be able to have one x screen. any ideas why it is freezing
01:16 imirkin: probably should check system messages after the freeze... "freeze" can mean a ton of diff things, unfortunately.
01:22 commanderkeen: there is a call trace provided
01:24 commanderkeen: when I run lsmod| | grep nouveau there are no results
01:25 commanderkeen: but when I check xorg logs it shows nouveau module loading
01:27 commanderkeen: i'll read the wiki page so i can get a better idea on how nouveau works
01:34 commanderkeen: looks like i can install a newer version. i will try that first and go from there
01:34 commanderkeen: thanks
05:46 quesada: I'm nouveau, on an optimus laptop. The discrete card should we always on. Sometimes the light that indicates this blinks though, turns white for a second or two (that means the intel card is on)
05:47 quesada: during that time, X cannot take mouse or keyboard input
05:48 quesada: any idea how to fix this? Blacklist intel module?
05:51 quesada: ah, it's not the intel module
05:51 quesada: dmsg shows some light
05:55 quesada: https://pastebin.com/sPDbhkDK
05:56 quesada: ACPI Warning: \_SB.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20160831/nsarguments-95)
05:57 airlied: quesada: why should it always be on?
05:57 quesada: on bublebee (not using it though) github it say known, harmless
05:57 quesada: well, if I, typing on the computer, it should be on :)
05:58 airlied: why?
05:58 airlied: are you using the nvidia explicitly?
05:58 quesada: to take input
05:58 quesada: nouveau, not bbee
05:58 quesada: yes, straight to dedicated
05:58 airlied: in the BIOS?
05:58 quesada: no options in the bios I could see
05:59 quesada: looks like I have the crappiest of the optimus
05:59 airlied: so you are most likey using hte intel then
05:59 airlied: that dmesg noise is nouveau powering up/down the nvidia
05:59 airlied: or attempting to, not sure it succeeds
06:01 quesada: ok
06:01 quesada: any way to fix it? it's very distracting
06:02 quesada: losing input for a second or two every few seconds
06:02 airlied: depends on what is trying to power it up, it really shouldn't be powering up that often
06:02 quesada: hmm
06:02 quesada: how would I find that out?
06:02 airlied: are you doing anything in particular when it happens?
06:03 quesada: no
06:03 quesada: browsing
06:03 quesada: reading pdfs
06:03 quesada: in kde
06:03 airlied: nouveau.runpm=0 will stop it, at the expense of not shutting down the nvidia
06:04 airlied: but since it doesn't seem to be going off for you maybe that is okay, can you pastebin a full dmesg?
06:04 quesada: that means not shutting down nvidia on suspend?
06:04 airlied: it looks to last about 6s off
06:04 airlied: nope
06:04 quesada: ok
06:05 quesada: https://pastebin.com/HrSQeBTh
06:05 quesada: this is with psatebinit, not sure if it's complete
06:05 quesada: can do it by hand too
06:06 airlied: need a dmesg from boot if you have it
06:06 airlied: that has just the power up/down spam in it
06:07 quesada: ah
06:09 quesada: the one I have has 40000 lines, but the uptime is long. shold this be it?
06:10 quesada: hmm
06:10 quesada: pastebin cuts it
06:10 quesada: will use filesharing (seafile)
06:12 quesada: https://login.yoursecurecloud.de/f/2a441f1423/
06:13 quesada: does this work?
06:15 airlied: quesada: still not all of it, no worries if you can't find it
06:15 airlied: it's probably long since gone if you have a long uptime
06:22 quesada: oh, it's less than two days uptime now that I look at it
06:23 quesada: if this is not all, any way I can get you all of it?
06:23 quesada: I can also reboot, if that helps
06:41 airlied: quesada: if you use systemd journalctl -b might give it to you
06:41 airlied: if not /var/log/dmesg may have it
06:48 quesada: will try
06:50 quesada: airlied: thanks. try now the seafile link above. it's .5M lines :)
06:56 quesada: systemctl status in case it helps : https://pastebin.com/ixcwCH3Z
07:01 airlied: quesada: firefox kinda dislikes it :)
07:03 airlied: quesada: what kernel is it btw?
07:04 airlied: it might be a bug that is already fixed, or maybe it's just something in your userspace that is constantly doing something bad
07:05 skeggsb: hmm, that reminds me, i need to re-silence those messages too..
07:06 skeggsb: airlied: i don't suppose there's some way to detect what acpi is expecting there btw so we can avoid those warnings too? (i presume radeon sees this as well?)
07:19 quesada: Linux wintermute 4.9.30-1-MANJARO #1 SMP PREEMPT
07:20 quesada: airlied: try curl or wget, it's a lot of lines
07:24 quesada: btw, @all great job with nouveau. I prefer it to nvidia now
07:32 airlied: skeggsb: acpi is just broken around _DSM
07:32 airlied: the spec wants one thing, the BIOS wants another
07:32 airlied: we'd have to hack acpi interpreter to just not bother printing
07:33 airlied: quesada: gotta run, a 4.10 might help with that
07:34 skeggsb: airlied: yep, and if we changed the args we send, we'd break the systems that do the right thing :P can we detect which is which somehow?
07:44 quesada: I have an encrypted drive. I worry about upgrading kernel and not being able to decrypt. It happened once I think
07:47 airlied: skeggsb: dont think we can
10:03 karolherbst: does somebody encounter crashes within the therm subdev on nouveau master recently?
10:14 karolherbst: skeggsb: you broke nouveau :p 3630e3916fb8f213a4bf3490ef853f4fe706f91d
10:14 karolherbst: with that commit, I get crashes starting steam prime offloaded
10:15 karolherbst: or maybe in triggers after a few seconds
10:15 karolherbst: it
10:15 karolherbst: 's this bug I guess: https://bugs.freedesktop.org/show_bug.cgi?id=101273
10:17 karolherbst: uhh
10:17 karolherbst: that got backported as well
10:17 karolherbst: so 4.11.3 is affected
10:20 karolherbst: ohh, there is this as well: https://bugs.freedesktop.org/show_bug.cgi?id=101184
10:20 karolherbst: skeggsb: I will test if your fix works
10:28 karolherbst: it stopped happening :O ugh
10:30 karolherbst1: famous last words
12:53 RSpliet: *epiphany*
12:54 karolherbst: skeggsb: but it seems like your patch works for me
12:54 RSpliet: OpenCL exposes 24-bit integer FMA because that's the size of the significant in 32-bit FP FMA, hence they can re-use the same hw skipping the pre/postshift stages
12:55 karolherbst: uhhh
12:55 RSpliet: wonder why that took me so long to figure out :-D
12:58 RSpliet: (I do wonder how much extra HW it required to get two 16-bit FP FMAs in the same time as one 32-bit... probably not so bad if the wallace tree is well balanced)
13:00 RSpliet: sorry, I'm abusing IRC as a notepad right now, should've just started gedit instead :-D
14:29 imirkin_: RSpliet: yeah, that's the whole reason behind mul24 ;)
14:29 imirkin_: RSpliet: on nv50, there is only a mul24 (and mul16) for integers, no mul32.
14:35 RSpliet: imirkin_: Fermi does 32-bit mul? Do we know more about the implementation?
14:35 RSpliet: (eg. hardware shared with FP FMA? or rather a simple cheap shift mul/add?)
14:38 RSpliet: CUDA/OpenCL pushed integer (pointer) arithmetic to the critical path, sounds like a logical evolution to dedicate more HW to it. But most of the times you still don't need 32*32 mul
15:23 imirkin_: RSpliet: sorry, not sure. i do know that IMAD is supposedly incredibly slow -- slower than mul + add
15:24 imirkin_: RSpliet: the fermi thing *also* implements stuff like imulhi (i.e. the upper 32 bits from a signed or unsigned 32x32 mul)
15:25 imirkin_: the thing is that most of the time you don't need the full 32*32 mul, but opengl just has a 32-bit integer, so unless you can prove that both sides are < 24 bits, you have to do the full mul
15:25 RSpliet: imirkin_: interesting, because a 32-cycle shift-mul has the add-portion for free by pre-loading the to-add value in the shift register
15:27 RSpliet: so I'd expect IMAD to be as slow as IMUL but no worse :-)
15:27 RSpliet: (apart from maybe 1 cycle extra to load a third register from the regfile if they can't do that single-cycle)
16:51 Lyude: btw imirkin_ lemme know when you push that patch for disabling BGRA8 on fermi, wanna get something into fedora's mesa package for this and mesa-stable
16:54 imirkin_: Lyude: i pushed it last friday or so
16:54 Lyude: imirkin_: awesonme
16:54 Lyude: *awesome
16:54 imirkin_: along with your other series
21:43 quesada: I had a crash that didn't even give me TTYs, so I had to reboot. Here's dmesg from a recent boot: https://pastebin.com/bk0dnRfe
21:44 quesada: 4.9.30-1-MANJARO #1 SMP PREEMPT
21:46 karolherbst: quesada: if it happens again, downgrade to 4.9.29
21:47 karolherbst: quesada: this should be the bug: https://bugs.freedesktop.org/show_bug.cgi?id=101184