01:35 uis: https://github.com/pathscale/pscnv/wiki/nvidia_compute
01:36 uis: From https://nouveau.freedesktop.org/wiki/CodeNames/
01:36 uis: "CUDA" link
11:15 RSpliet: Heh... yeah, that was always quite the hack I think.
11:16 RSpliet: Anyway, pscnv became a political PITA, was abandoned by all nouveau devs many many moons ago
11:16 RSpliet: The link may go if you have wiki editing creds
11:20 karolherbst:doesn't even know what happened
11:21 RSpliet: You didn't miss out much
13:26 macc24: RSpliet: what the hell was pscnv?
13:27 imirkin: pathscale
13:27 imirkin: ancient history
13:28 macc24: oh
13:28 macc24: i like ancient stuff ;)
13:32 imirkin: they made their own compiler for nvidia hw
13:32 imirkin: not sure who bought it, tbh
13:33 imirkin: presumably they convinced at least some people theirs was better than nvidia's
13:34 imirkin: (it may very well have been, dunno)
14:04 uis: political PITA?
15:07 karolherbst: imirkin: any idea how much work it would be to get fully rid of using bufctx in mesa?
15:07 imirkin: without replacing?
15:07 imirkin: it's there for a reason
15:07 karolherbst: well.. without regressing of course ;)
15:07 karolherbst: but yeah
15:07 imirkin: we do flushes whenever
15:07 imirkin: and the batch needs to have the right bo's associated with it
15:07 karolherbst: yeah.. but bufcts are super racy and are causing most of the issue afaik
15:08 karolherbst: like triggering submission on other contexts pushbufs
15:08 imirkin: so we'd have to change the method of submission or something
15:08 karolherbst: replacing those could actually mean we can fix it easily
15:08 karolherbst: or well..
15:08 karolherbst: in smaller steps
15:10 karolherbst: imirkin: I mean I wouldn't mind if we are more explicit on how we reference bos and stuff
15:11 karolherbst: bufctxs are essentially the reason my tries failed on fully fixing as bufctxs just.. touch other threads data
15:12 karolherbst: maybe I just play around with the idea and see how well that works
15:13 imirkin: random flushes triggering random things is what killed my attempt
15:13 imirkin: nouveau_bo_map can issue a flush.
15:13 karolherbst: I got rid of that as I had per context pushbuffers
15:13 karolherbst: so it didn't matter
15:13 karolherbst: bufctxs on the other can flush pushbuffers of other contexts
15:13 karolherbst: and this was ugly
15:14 karolherbst: well, binding a bo to a bufctx was the culprit I think.. let me check
15:20 [diablo]: good afternoon #nouveau
15:21 [diablo]: guys, a mate, who'll be joining shortly, has just installed LM 19.3, he has a '01:00.0 VGA compatible controller: NVIDIA Corporation G73 [GeForce 7600 GT] (rev a1)'
15:21 [diablo]: when he start a video in VLC, it freezes the box...
15:21 [diablo]: any ideas please guys?
15:22 karolherbst: imirkin: okay.. I think it was something like that: a bo can only be bound to one pushbuffer at the time. When we have a bo used in multiple contexts we need to flush the pushbuf before we can move the bo to the current one.
15:23 karolherbst: so.. and somehow bufctx were involved in a super ugly and complex manner I forgot about
15:24 karolherbst: bufctx containing bos from multiple contexts could have been the big issue
15:24 karolherbst: something like this
15:25 karolherbst: but that also sounds like more that we should make it possible to have a bo being used in multiple push buffers
15:25 karolherbst: without having to flush them
15:52 imirkin: [diablo]: make sure VLC isn't trying to use GL or any hardware accel
17:00 RSpliet: karolherbst: ended up proposing a fix for the HDA issue myself. It works until I do a suspend-to-RAM cycle.
17:00 RSpliet: And now I wonder whether that's the same issue or not
17:00 karolherbst: heh
17:01 RSpliet: https://bugzilla.kernel.org/attachment.cgi?id=288167&action=diff fwiw
17:03 karolherbst: yeah.. mhhh
17:03 karolherbst: in the best case the driver wouldn't bind, but.. mhhh
17:03 karolherbst: did you try the other patch?
17:03 RSpliet: Of course I did
17:04 RSpliet: Didn't work though
17:04 karolherbst: both?
17:04 RSpliet: Yep
17:04 karolherbst: ahh
17:04 karolherbst: mhh
17:04 RSpliet: They can't not bind because of their two stage probing thing
17:04 RSpliet: Which seems wrong to me... but I don't want to mess too much with working code
17:05 RSpliet: If I have to choose between 1KiB of driver overhead or my laptop not going into PC8, I'd choose the former :-P
17:06 karolherbst: yeah...
17:07 karolherbst: I am wondering how expensive it would be to detect there are no codecs
17:07 karolherbst: but mhh
17:07 karolherbst: unbinding also frees resources
17:07 karolherbst: and .. it's fine if they bin as long as the driver handles the runpm bits
17:09 RSpliet: Exactly. I can think of three different ways to solve the problem. My patch was the one of least resistance (but not 100% there)
17:10 RSpliet: I'll try to unbind, then do a suspend-to-RAM cycle, maybe unbind again and see if DynOff works in that case.
17:10 RSpliet: ... later. Cooking now :-P
17:10 RSpliet: Anyway, if that experiment works, it's a problem with the sdn_hda_intel (patch). If it doesn't, there might be another runpm problem
17:58 [diablo]: hi imirkin thank you I will mention it to him
17:58 [diablo]: apparently Celluloid works fine
18:00 [diablo]: I will tell him to join this channel also
18:03 imirkin: can read it in the logs
18:05 [diablo]: imirkin hi it's phalanx with the issue... I've pasted him what you wrote
18:06 [diablo]: imirkin many thanks btw
18:13 phalanx: hi
18:13 phalanx: tried it imirkin but no cigar
18:13 imirkin: what mechanism did you use to try that?
18:14 phalanx: https://wiki.videolan.org/VLC_HowTo/Hardware_acceleration/
18:15 imirkin: what's your actual goal?
18:16 imirkin: to play videos, or to use vlc?
18:16 phalanx: to play videos with vlc
18:16 imirkin: ok
18:16 imirkin: did you disable GL *and* VDPAU?
18:17 imirkin: https://wiki.videolan.org/VLC_GPU_Decoding/
18:17 imirkin: make sure "Use GPU acceleration" is disabled
18:17 phalanx: leet me check
18:18 phalanx: i dont have that option
18:19 phalanx: i set hardware-accelerated decoding to disable
18:25 imirkin: ok, well, if there's no acceleration going on, then it can't be hanging
18:26 imirkin: i don't know how to use vlc, so you'll have to get help from the vlc guys on how to make it not use GL
18:26 imirkin: and not use VDPAU / VA-API / etc
18:26 phalanx: ok thank you
18:26 imirkin: alternatively you could just remove all the mesa / nouveau stuff
18:27 imirkin: which would still get you acceleration in the DDX
18:27 imirkin: or you could boot with nouveau.noaccel=1 to remove all acceleration
18:27 imirkin: or you could use mplayer instead of vlc.
18:27 phalanx: yes ok
18:36 lovesegfault: karolherbst: The patches you gave me for Pascal seem to build fine for 5.6; anything else I should know/do before trying the new kernel?
19:23 karolherbst: nope
19:32 lovesegfault: karolherbst: Cool, will try it out today