00:00DUOLabs[m]: I'm asking in the context of QEMU: does QEMU already have support for Venus (that is, QEMU recieves command from guest, passes it to virglrenderer, which passes it to Venus, which then passes the result back to virglrenderder, which passes it back to QEMU)? Or does Venus already get the command, but QEMU currently have no way of reading the buffer.
00:31robclark: DemiMarie: any security boundary in the userspace stack is a false promise ;-)
00:33HdkR: Security through obscurity? :P
01:03robclark: obscurity only stops the good guys
07:45mivanchev: Hey, just stopping by to ask why 23.0.1 has no tag on the git repo?
07:59hch12907: <DUOLabs[m]> "I'm asking in the context of..." <- I believe QEMU support for venus is not upstreamed yet?
07:59hch12907: not too sure, but last time I checked you still have to apply some patches in order to enable venus.
10:33DUOLabs[m]: <hch12907> "I believe QEMU support for venus..." <- Oh, I thought it was --- I checked the changes between the fork and upstream, and they seemed to match.
11:23DUOLabs[m]: Even if it wasn't, what needs to be done --- basically, what part of the communication pipeline is incomplete?
16:52DavidHeidelberg[m]: robclark: Hey! zink became unstable on 6.3 kernels on a630, do you have any ideas why that happens? every other a630 job passed just fine: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22255#note_1850663
16:58robclark: DavidHeidelberg[m]: not really.. a couple of those look like gpu hangs.. one looks like memory allocation fails which is odd
16:59robclark: otoh ToT zink just hangs in semaphore wait for me for things I've tried
17:04robclark: DavidHeidelberg[m]: the one allocation related change in 6.3-rc is 8a86f213f4426f19511a16d886871805b35c3acf but if it is trying to do an order 5 allocation that means zink is trying to use ~5000 syncobjs (or at least more than ~2500) !?!
17:04robclark: but maybe that isn't the allocation failing, idk
17:05DavidHeidelberg[m]: I'll try retry few more times, but the fails seems to be random (not related to any trace directly)
17:09robclark: do you see the same thing on a618? Or zink traces is only on a630?
17:15minecrell: DavidHeidelberg[m]: why did you drop CONFIG_PHY_QCOM_USB_HS=y?
17:43DavidHeidelberg[m]: minecrell: tbh I stole that block from tomeu but that explains why a306 has no usb loaded....
17:43minecrell: indeed :p
17:44DavidHeidelberg[m]: thanks :D :)
21:10DUOLabs[m]: <DUOLabs[m]> "Oh, I thought it was --- I..." <- Oh, now I see why I thought it was merged. I was on the wrong branch --- `virgl-gpu-next` instead of `venus-dev`.
21:23DUOLabs[m]: However, it seems like venus is the newer one.
22:44DemiMarie: Is it expected that any program with GPU acceleration can crash the entire login session, including the Wayland compositor?
22:49kisak: most current generation compositors are not taught how to recover from a gpu reset
22:50DemiMarie: which ones are?
22:52kisak: I don't know which support robust contexts. Finishing my thought, in general OpenGL drivers are supposed to catch situations leading up to a GPU reset and not allow the application do that, but Vulkan has no such expensive runtime checking.
22:53DemiMarie: kisak: Vulkan vs OpenGL does not matter in the virtualization use-case.