01:30 jenatali: gfxstrand: Congrats, your wish was granted: https://www.phoronix.com/news/Mesa-Vulkan-Driver-Runtime
02:21 Company: reading that post makes me think that it's inevitable that you end up with such a layer
02:22 Company: because you want backwards compatibility and at some point that means an implementation of the old stuff using the new stuff
14:25 glehmann: > Improves CTS runtime by a lot.
14:25 glehmann: konstantin: how much is a lot?
15:10 konstantin: glehmann: I was too lazy to check against main (it takes 3-4 hours to run) but I think it's >20%
15:10 glehmann: nice
15:12 konstantin: I remember running a caselist (size 500, piglit+zink) which compiled 50k sample functions so it's not a surprise to me
16:38 alyssa: konstantin: and i thought vk cts runtime was bad!
17:50 JoshuaAshton: sima: Has the concept of surfacing fence errors up through to userspace ever come up? It'd be nice if from a compositor side that we knew if the syncobj was signalled due to a hang,etc so we don't display garbage and can ignore the commit.
17:50 JoshuaAshton: cc: daniels emersion also, you might be interested in this.
17:51 JoshuaAshton: That would also allow drivers to reliable return VK_ERROR_DEVICE_LOST in vkWaitSemaphores etc
18:03 daniels: yeah that’s an idea - I was going to say that you should be getting DEVICE_LOST but yeah you wouldn’t notice it on external imports
18:05 JoshuaAshton: We'd also have to consider semantics for how that would interact with event fd
18:05 JoshuaAshton: Gamescope does all of it's dmabuf latch waits with epoll, so we could either POLLHUP or regular POLLIN and have a query for the error
18:05 JoshuaAshton: Not sure which would be most ideal there
18:06 JoshuaAshton: (speaking about when we do explicit sync with external syncobj + eventfd in the future fwiw, *right now* we just wait on the dmabuf fd)
18:09 JoshuaAshton: This is also a problem for SteamVR (and probably monado?) which has always been external sync with semaphores
18:39 daniels: I think you’d still have to do POLLIN in order to not break existing users
19:34 JoshuaAshton: Makes sense
23:18 sima: JoshuaAshton, uh ... very tricky topic
23:18 sima: and also a bit very late now, can you ping me again on monday or so?
23:19 sima: because my brain isn't in a state where remembering todo stuff works :-P
23:28 airlied: JoshuaAshton: I'm sure sima can fill in more detail, but yes it has come up, I think i915 even did it for a bit, but it got really messy when fences start getting passed around through processes and across security boundaries, like X.org dying because of misc error on a client fence etc
23:54 JoshuaAshton: Ah yes, I forgot it's Caturday! ^_^
23:55 JoshuaAshton: airlied: Hmm, I guess what I want is a way to just know if the syncobj was signalled due to an error or if it was signalled because the work was actually complete
23:55 JoshuaAshton: Not for it to kill/error a process