01:06 airlied[d]: skeggsb9778[d]: can you ack/rb https://patchwork.freedesktop.org/patch/589947/ somewhere dakr can see it and I'll get him to merge it
01:11 skeggsb9778[d]: done!
05:32 gfxstrand[d]: skeggsb9778[d]: I'm pretty sure we still have some fence bugs. I see random context timeouts that make no sense sometimes.
05:33 gfxstrand[d]: I was able to hit it really consistently with doing PRIME sharing between two NVIDIA GPUs where the compositor was running nouveau GL and the app was NVK.
05:33 gfxstrand[d]: No idea if that's related to the bug you're chasing, though.
13:38 asdqueerfromeu[d]: How should I debug a segfault in the proprietary NVIDIA driver code (that only happens in one application with an overlay enabled without even the NVIDIA kernel driver being loaded)? Do I have to write an email to the linux-bugs address?
15:34 ahuillet[d]: it's one way, but see $other_server
20:45 redsheep[d]: gfxstrand[d]: I realize that the location I'm testing from in the witness is quite CPU intensive, which probably explains quite a bit of the decreased scaling over your results
20:46 redsheep[d]: Since the frame times are consistent and dxvk reports high usage it's still probably GPU bound, but perhaps not quite as much? Or it just stresses the GPU differently
20:48 redsheep[d]: When the witness is on my non-vcache cores it runs about 160 fps on prop, but it only reports about 60% usage when it's like that. When it hits vcache cores it's closer to full utilization at about 210.
20:49 redsheep[d]: That's vs the best result on NVK at 108
20:53 redsheep[d]: Are you still working on more cbuf related optimization or have you shifted focus elsewhere?
21:07 gfxstrand[d]: I'll be coming back to it. I'm just taking a breather for a bit to try and do some code review and move some other things forward.
21:07 gfxstrand[d]: I'm very much not done.