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