eukara has quit [Remote host closed the connection]
eukara has joined #zink
jekstrand has quit [Ping timeout: 480 seconds]
jekstrand has joined #zink
otokawa_ has quit []
otokawa_ has joined #zink
otokawa_ has quit []
otokawa_ has joined #zink
<zmike>
hch12907[m]: \o/
<zmike>
ajax:
otokawa_ has quit []
<ajax>
anholt: i think what i was remembering here is that if a pre-kopper-era swrast loader tries to load zink it's expected to not work. and the server's glx code has an old swrast loader.
<ajax>
anholt: but Xorg wouldn't be using it, there, the glx code would load iris as a __DRI_DRI2 driver. and then glamor would use whatever libEGL decides it's going to use.
<ajax>
and Xwayland uses libEGL instead of __DRI_DRI2 or __DRI_SWRAST
<ajax>
so Xephyr is the remaining case, and i guess the question is does the swrast loader still select llvmpipe, because if it does then using zink for glamor should work there too
<ajax>
(with indirect glx contexts turned off, the glx provider code never really touches any GL state in the driver it happened to load, so there's no question of it doing anything that would interfere with glamor)
<ajax>
Xephyr -glamor -retro draws the ugly stipple, so, hoorayish
<ajax>
i still want Xorg and Xephyr to do glx setup like Xwyland does, but at least it's not blocking using zink as glamor's renderer
<zmike>
\o/
<ajax>
but such a Xephyr has no DRI3 extension (somehow?) so you can't then use zink to draw glxgears on such a server. wtf.
<ajax>
oh, sure. Xephyr's using the glamor egl stubs so there really isn't dri3.
<ajax>
honestly why aren't we using VkDebugUtilsMessengerCreateInfoEXT
<ajax>
and then making sure every place it can fail in our vk drivers is annotated with a good message
<zmike>
it's used, there's just no logging used with it
<zmike>
there's already logging for failures though
<ajax>
it's not used at CreateInstance time afaict
<ajax>
it could, if you chained the struct in, but we don't
<zmike>
check out create_debug()
<zmike>
in general though I think vk_log infrastructure is supposed to handle logging for the drivers
<ajax>
in the vk driver, yes. in zink no though, right?
<zmike>
no, in zink there's regular mesa_loge and such
<ajax>
right. and we register a callback for them, in create_debug, but that whole dance happens entirely after vkCreateInstance has failed
<zmike>
yep
<zmike>
if you want to expand it for instance creation go for it
<ajax>
thinking it's a time saver in the long run, yeah
* ajax
pokes
<ajax>
to the extent that i think i write good code, i think my best work is making sure debugging is possible and possibly straightforward