<ajax>
was mostly getting it copied to somewhere other than the machine i was working on, since i was about to switch tasks
<zmike>
I gotchu
<ajax>
i can take a crack at it today in a bit
<zmike>
cool, I'm down in gallivm for advanced blend again
<zmike>
ajax: you waiting on more reviews for the glx refcount MR?
<ajax>
hah, was just refreshing that
<ajax>
no, think i'm set
<ajax>
i have a refinement in progress to handle the super weird cases but i don't want to block on that
<zmike>
👍
fahien has quit [Ping timeout: 480 seconds]
fahien has joined #zink
fahien has quit []
fahien has joined #zink
<ajax>
jekstrand: how kosher would it be to expose VK_KHR_shared_presentable_image without supporting any of the new presentation modes it names?
<ajax>
basically just to add vkGetSwapchainStatusKHR
<jekstrand>
ajax: Hrm... I'm not sure if the extension allows that.
<ajax>
i dunno. i don't see any text saying either of demand/continuous need to be there.
<ajax>
(i kind of hate the vulkan extn doc format and think gl extns are nicer to work with, and this is kind of why)
<zmike>
yeah it's terrible
<ajax>
but actually
<ajax>
the text also says: "
<ajax>
In order to query a swapchain’s status when rendering to a shared presentable image, call:
<ajax>
" which sorta kinda doesn't say anything about non-shared-presentable images
<jekstrand>
Yeah...
<jekstrand>
I think if you want it, we should draft an EXT. What's the use-case?
<ajax>
but, which also does not document any error condition for calling it on an nspi
<ajax>
kopper, nothing concrete at the moment but i remember wanting it
<jekstrand>
I mean, feel free wire up the entrypoint, play with it, and then draft an EXT if it's useful.
<jekstrand>
We track the failure information per-swapchain so it shouldn't be hard.
<jekstrand>
But I don't know that it'd get you information faster than AcquireNextImage or QueuePresent
<ajax>
it's sort of ANI with zero timeout, except without the side effect of acquiring the image
<jekstrand>
Right.
<jekstrand>
I still don't get why you want that but sure, if it's useful, I see no reason why not.
fahien has quit []
<ajax>
oh so
<ajax>
one reason is that right now the way you do surface liveness checks is GetDevicePhysicalWhatever that bottoms out at xcb_get_geometry
<ajax>
which is a pointless round-trip since we're already getting Present configuration events asynchronously so if the size had changed we'd know
<ajax>
and then because of the way the kopper is wired, you do one of these per frame, so now you're at 12us per round trip, times 60 is 0.72ms, and i'm not comfortable spending 0.7% of my cpu time checking whether a surface is alive when if it's not i'm dying soon anyway
<zmike>
🤔
<ajax>
think i got my math right there, at any rate that was the mechanism that made me want a softer swapchain liveness check
<ajax>
i guess it's 0.7% of your timeline, other threads can do work through that, but still
Thermi has joined #zink
<zmike>
0.7% is 0.7%
<ajax>
jekstrand: so yeah, how do i ask a VkImage whether its content is defined
<ajax>
because without that kopper's EXT_buffer_age needs to hope that ANI gives you back images that weren't modified since last you owned them
<jekstrand>
ajax: We'd need some sort of extension, probably to AcquireNextImage which tells you whether or not they've been modified and, since we only ever use DRI3 and Wayland, the answer will always be "no, they haven't changed."
<jekstrand>
Annoyingly, AcquireNextImage2KHR doesn't return via a struct so there's nowhere to chain that in. :-(
<ajax>
enh. not a guarantee for dri3 but i'm willing to pretend.
<jekstrand>
So how do we implement buffer age with X?
<ajax>
and given that, whatever, i'll just assume things work and if they don't i'll point at the pixel ownership test
<jekstrand>
Isn't it at least a guarantee with present?
<ajax>
X promises that by the time it idles the pixmap back to you that it is the same object. it does not promise anything about its content.
<jekstrand>
Oof. TIL.
<jekstrand>
In any case, we'll need an extension. And that probably means vkAcquireNextImage3. :-/
<ajax>
i mean. in practice it _does_ not modify the bits, unless you do non-glx things inside that window
<ajax>
which: what kind of crazy person are you
<zmike>
also: glx exists
<jekstrand>
Yeah, that sounds like something we can stick in an eratta
<ajax>
but doing those non-glx things count as glx losing the pixel ownership test, so nyah
<jekstrand>
Sure. In any case, new ext, ANI3, fun times.
<jekstrand>
That or we make some high-level promise you can query as part of surface capabilities but putting it on ANI seems more sane.
<ajax>
hmph. what's the oldest vulkan-capable mba.
<ajax>
i really like the one i'm using but nvaf is not exactly zink material
<airlied>
I assume one of the intel ones had skylake or kabylake at some point?