01:15holytrousers: hello everyone, i'm having this strange bug when opening a video (only in webkkit2-gtk browsers luakit or Surf ) x hangs completely only the mouse moves but the keyboard is dead
01:16holytrousers: here is the journalctl https://bpaste.net/raw/92d9e73cc625
01:16gnarface: i'm suspecting it's a known issue
01:16gnarface: which card is it?
01:19holytrousers: "GeForce 8600M GS"
01:19gnarface: yea that sounds like it's in the right range
01:19holytrousers: oh that's good news i guess :D
01:19gnarface: well, in a sense
01:20gnarface: see subnote 5 here: https://nouveau.freedesktop.org/wiki/VideoAcceleration/
01:20gnarface: this one is looking unlikely to ever see a fix unless Nvidia staff intervenes
01:21gnarface: but on the plus side, all you have to do is avoid h264, or somehow force it into software decoding
01:21gnarface: (cpu power willing)
01:22holytrousers: i see, curious that chromium plays quite smoothly ( maybe it's sw decoding ? )
01:22gnarface: that'd be my guess
01:22gnarface: or maybe not h264
01:22gnarface: it could be translating it to something else
01:22gnarface: or maybe you're using flash
01:22holytrousers: nop no flash
01:23gnarface: it should be pretty easy to verify with some test files and a copy of mplayer or vlc
01:23holytrousers: any kind of video only in luakit/surf
01:23holytrousers: mpv / vlc play fine
01:23gnarface: the issue won't be player-specific, except in the sense that different players may have better failover behavior, or just simply not default to trying hardware decoding in the first place
01:24gnarface: and it'll only be h264 video
01:24gnarface: (mpeg2 should decode fine in hardware)
01:25gnarface: other codecs like theora don't have a hardware decoding option so you won't notice anything different
01:25holytrousers: humm ok so i guess that the firmware for vdpau is useless then ?
01:26gnarface: well, it depends on how you define useless
01:26gnarface: but yea, effectively, it's useless until someone figures out how it works. and nvidia isn't admitting anything.
01:27gnarface: and maybe just useless on that particular family of cards (they seem to have it working on some of the others, as you can see on that chart on the page i linked)
01:28holytrousers: thank you gnarface for your help
01:28gnarface: sorry i couldn't actually fix anything for you
01:28gnarface: this particular issue is holding me back too
01:28holytrousers: i admire you guys for the effort
01:29gnarface: oh, i'm not actually part of the team, i can't take any credit
01:29gnarface: but i assure you the ones who are, appreciate your sentiment
01:31gnarface: it's a really annoying bug too
01:31gnarface: because while there are legacy proprietary drivers that still support the hardware, *Valve* won't support those drivers
01:32gnarface: so until this is fixed in nouveau, steam in-home streaming is a no-go on this hardware
01:32gnarface: (it works in software decoding, but software decoding makes the latency too variable to be effective for anything short of turn-based gameplay)
01:33gnarface: steam link was even on sale recently, but i despise waste
01:34holytrousers: that's weird because i always thought that after adding vdpau "firmware" playback went smoother and the tearing stopped
01:34holytrousers: must be placebo :/
01:34gnarface: well, there's the possibility my assumption is wrong and the symptoms could just be a red herring too
01:34gnarface: worth double-checking with some tests
01:35holytrousers: will do yes
01:35gnarface: but it sounds a lot like what was happening to me, basically i'd look at logs and find out it was falling back on sofware
01:35gnarface: i'd twiddle some configs to force it to not do that, and i'd get the same thing you described; card would just freeze on a black screen
01:36gnarface: like it just chokes on the very first frame of the video
01:36gnarface: not an i/o lock, more like it's just sitting there waiting for something
01:36gnarface: a secret passkey
01:36gnarface: maybe divine intervention
01:36gnarface: i dunno
01:37holytrousers: mpv plays fine a x264 video
01:37holytrousers: smooth so i would be pretty sure it's hw decoding
01:38gnarface: hard to say with a modern cpu honestly and video
01:38gnarface: for me with the software decoding it was only like the difference between it being 10ms delay static, or 50-90ms delay, variant.
01:39gnarface: not enough that you'd really notice with video except if you were comparing the cpu load
01:39holytrousers: would you call core2duo t5750 modern ?
01:39gnarface: it's a problem for gaming because of course the varying delay kills your input timing
01:39gnarface: in this context, yea i'd call a core2duo modern
01:40gnarface: 64bit chip, 64-bit os, at 2.3ghz the one i have mine in doesn't even use one whole core decoding OR encoding h264
01:41gnarface: but you should note, the differences in performance will be much more noticable at 1080p than at 480i
01:41gnarface: resolution matters a lot
01:41holytrousers: seems you're right : mpv --hwdec=no gives the same playback quality on a hd video
01:42gnarface: the difference between 480i and 720p might be negligible on modern hardware, but going from 1080i to 1080p crosses a threshold where there might actually not be enough cable bandwidth
01:42gnarface: ok yea, so firmware placebo effect
01:42gnarface: (not a guarantee though, not enough is known about what all it does to even guarantee that much)
01:43holytrousers: haha i've been living in an illusion
01:43gnarface: i'm very sorry
01:43holytrousers: i'm very happy :D
01:44gnarface: i haven't made any friends by shattering illusions
01:58holytrousers: sorry to bother you, but is this line in my log responsible for the freeze ? Oct 26 01:05:08 speedy kernel: nouveau 0000:01:00.0: fifo: DMA_PUSHER - ch 4 [ositorWorkQueue] get 002033d004 put 002033d00c ib_get 00000197 ib_put 000001a1 state 80007418 (err: INVALID_CMD) push 00406040
02:03holytrousers: the hardware is 10 years old why on earth do they keep it proprietary
03:45imirkin: karolherbst: https://hastebin.com/osahinugis.vbs -- crashes. that's with your 'cts' branch.
03:46imirkin: wow, these sure are not short shaders it's building
06:58mastermart: hi, so it was an occationally spammy run of 9years if other have tried to figure how long i have been there, starting from year 2009 that was, 8-9 years i have been at gpu, i have ended my most difficult research today though, and i am doing almost fine as the most complex pressure shots are allready done
07:00mastermart: i was aware that it was a nervy session and it was going to be , but luckily it's over now
08:03jcadduono: is nouveau driver responsible for nvidia-fb kernel driver getting i2c access for ddc?
08:04jcadduono: i am hoping to find a way to write an edid to a monitor running over eDP but all my attempts have been unsuccessful so far
08:06jcadduono: from what i can tell, proprietary nvidia driver does not actually have working i2c function for GP104 (GTX 1080) although previous cards do, was hoping to get that possibility from nouveau
09:03karolherbst: imirkin: yeah, no idea why, but this only happens with a O0 build the crash... that's why I was actually thinking to figure out why unordered_set helps (most likely we have such high memory demands, that it triggeres some undefined behaviour or something like that, no clue)
09:04karolherbst: ohh wait
09:05karolherbst: unordered_set is totally random, could be simply that for some "order" inside the set it compiles and with a different one it doesn't.... whatever
09:05karolherbst: but on a master branch it shouldn't compile either...
12:44imirkin: jcadduono: nvidia-fb?
12:45imirkin: do you mean the fbdev driver? if so, that's basically unmaintained. i doubt it works for anything past tesla.
12:46imirkin: if you mean nouveaufb as provided by nouveau, then i *think* there's a dpaux i2c thing that gets registered. you'd have to be a little careful with how you use it, of course.
12:46imirkin: i don't know that edid flashing is a thing that can be done these days
12:47imirkin: you can force an edid blob to be used for a particular connector though