-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2020-02-02 7:51 a.m., Keith Packard wrote: > > I spent some time over the last week experimenting with a different > way of doing frame timing. > > Instead of specifying *when* a particular frame should be > displayed, how about we specify how *long* a particular frame > should be made visible to the user? > > This has a couple of advantages over the approach taken in > GOOGLE_display_timing: > > 1. It provides information to the backend about frame timing a > frame earlier. > > 2. Missing a frame can generate fewer artifacts. > > Here's what I'm thinking the extension would look like: > > An application uses VK_MESA_present_period by including a > VkPresentPeriodMESA structure in the pNext chain in the > VkPresentInfoKHR structure passed to the vkQueuePresentKHR call. > > typedef struct VkPresentPeriodMESA { VkStructureType sType; > const void* pNext; uint32_t swapchainCount; const > int64_t* pPresentPeriods; } VkPresentPeriodMESA; > > The fields in this structure are: > > * sType. Set to VK_STRUCTURE_TYPE_PRESENT_PERIOD_MESA * pNext. > Points to the next extension structure in the chain (if any). * > swapchainCount. A copy of the swapchainCount field in the > VkPresentInfoKHR structure. * pPresentPeriods. An array, length > swapchainCount, of presentation periods for each image in the > call. > > Positive presentation periods represent nanoseconds. Negative > presentation periods represent frames. A zero value means the > extension does not affect the associated presentation. Nanosecond > values are rounded to the nearest upcoming frame so that a value of > n * refresh_interval is the same as using a value of n frames. > > The presentation period causes *future* images to be delayed at > least until the specified interval after this image has been > presented. Specifying both a presentation period in a previous > frame and using GOOGLE_display_timing is well defined -- the > presentation will be delayed until the later of the two times.
Should this extension specify how it interacts with the various VK_PRESENT_MODE_* modes? For one example: With VK_PRESENT_MODE_MAILBOX_KHR, does the period specified by this extension correspond to: a) The time between when the image is placed in the the queue of pending presentation requests and when the next image is placed in the queue b) The time between when the image is taken from the queue to be actually presented and when the same thing happens for another image (which happens to be in the queue at the time) c) Yet something else? If it's a), given the extension talks about rounding to the nearest upcoming frame, does VK_PRESENT_MODE_MAILBOX_KHR effectively behave the same as VK_PRESENT_MODE_FIFO(_RELAXED)_KHR with this extension? If it's b), there can be any number of images entering and leaving the queue during the period, so it's not clear what purpose the period would serve? - -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQSwn681vpFFIZgJURRaga+OatuyAAUCXkrQ9gAKCRBaga+Oatuy AB2FAJ4glgpyMYSy1WPmbpzbI2O5Rvv0/QCfSeQBF7vsooAtjEBicmW76NfWWws= =MzZO -----END PGP SIGNATURE----- _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev