On 06/08/17 12:32 PM, Keith Packard wrote: > Daniel Vetter <daniel@xxxxxxxx> writes: > >>> +#define DRM_CRTC_SEQUENCE_FIRST_PIXEL_OUT 0x00000004 /* Signal when first pixel is displayed */ >> >> Note that right now vblank events are defined as: >> - The even will be delivered "somewhen" around vblank (right before up to >> first pixel are all things current drivers implement). >> - An atomic update or pageflip ioctl call right after a vblank event will >> hit (assuming no stalls) sequence + 1. radeon/amdgpu have some sw hacks >> to handle this because their vblank event gets delivered before the last >> possible time to update the next frame. >> - The timestamp is corrected to be top-of-frame. >> >> Would be a good time to document this a bit better, and might not exactly >> match what vk expects ... > > [...] > > FIRST_PIXEL_OUT is an attempt to signal to the kernel that the > application really wants to see the event when the first pixel hits the > display. I assume the important thing here is the timestamp in the > event and not the actual delivery, but I don't actually know that. > > If the timestamp is the only important thing, it sounds like the kernel > already satisfies that, which is cool. > > If Vulkan really wants the event to be delivered when the first pixel is > displayed, then having this bit in the ioctl means we can let drivers > continue to do whatever they are now when the bit isn't set, but try > harder to deliver the event at first-pixel when requested. I don't see the point of giving this choice to userspace. The event timestamp specifies when first-pixel occurs; if it's in the future, userspace can use other functionality to wait until then if needed (though it's hard to imagine why it would be). > So, I think what I want to do is leave the bit in the request so that > drivers can at least see what user space is asking for, and if we learn > that it's important to deliver the event at the requested time, we can > go fix drivers later. This seems like a very bad idea: Having a flag which doesn't have any effect at first will result in userspace randomly setting the flag or not. If we were to then change the behaviour with the flag (not) set, some userspace will almost certainly break. So effectively we can never make the flag have any effect. The way to go here is to drop the flag for now and document the behaviour explicitly. If unexpectedly a real need for different behaviour comes up in the future, we can add a flag for it at that time. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
