Open cwfitzgerald opened 2 years ago
For EGL, the WSI can do present with damage if the EGL_KHR_swap_buffers_with_damage extension is supported.
Random thoughts incoming:
WSI
mean windowing system integration? It's unfortunately not the most searchable abbreviation.PRESENT_STATISTICS
I feel that the PRESENT
is needed to differentiate from MONITOR_STATISTICS
. However, I feel it should be at least PRESENTATION_STATISTICS
.MONITOR_STATISTICS
reads as if 'monitor' means 'keep track of' as in verb noun. I first thought DISPLAY_STATISTICS
but that has the same problem. SCREEN_STATISTICS
is maybe a bit less problematic even though grammatically it could go either way. I feel like I want DISPLAY_REFRESH_STATISTICS
to be the outcome. :)scoll
typos in places. Where does the 'scroll' term come from? Scroll-lock comes to mind but that's an old cathode ray tube (CRT) feature. From the structs it looks like it's for requesting which part of the screen would be actually updated with what portion of the provided frame. Is that correct?presentation_start
and earliest_present_time
?presentation_margin
mean?Taking a step back and thinking about how one would want to use this - the presentation and display refresh statistics provide information that can be used to make some kind of estimation/prediction for frame pacing, and the presentation descriptor then allows making an attempt at controlling presentation of a given frame. I'd have to think through it more thoroughly to be able to figure out whether it's sufficient and ergonomic.
It feels like there must be a way on Windows to get information about display refresh rates and timings...
@superdump There is, it's a bit complicated, but should be implementable within winit. You can get very specific timing info about all your monitors. Now that winit exposes micro-hertz refresh it should be usable for pacing. We just also need to expose the precision of the hz measurement.
I'm not sure what the status here is, but I'd love to implement the VK_GOOGLE_display_timing
version, if you can give some guidance.
@badicsalex Sorry this totally got lost in the information firehose. None of this (outside of getting cpu-side presentation timestamps) is implemented yet and we'd love help! Come on our matrix and chat, that'd probably be the easiest way to sync up.
@cwfitzgerald thanks for the answer. We've investigated the issue in detail since then, and it seems that VK_GOOGLE_display_timing wouldn't give us much over simply measuring the acquire times of a simple FIFO mode, so we didn't pursue that angle any further.
I talked a bit with @DJMcNab at RustNL last week, and he said that partial present functionality was important to the Xilem team.
I'm still interested in this too, just haven't gotten around to properly look at this. I have a fork somewhere that implement a crude way of getting presentation information on Apple hardware, but I think the main problem here is finding out to integrate data from the different APIs into wgpu's data model. Having precise statistics about when presentation happened is super crucial for my use case and now that the rest of my project is somewhat shaping up, I might have another look.
On a side note, I'd also be interested in running a handler as soon as possible after frame presentation, but I'm not sure if that is even possible outside of Apple/Metal.
Context
I'm working on frame pacing and we need some help from the api. The difficulty of designing this api is each WSI has different pieces of information and give it to us in different ways.
Supersedes #682 Supersedes #2650
Investigation
We have the following major WSIs to think about:
And we have the following primatives:
Notes: 1a. Presentation times need to be queried actively, it doesn't get told to us. 1b. Presentation times are given through an event queue. 1c. Presentation times are given through callbacks.
Because of the diversity of the platforms, I think this will inherently be a leaky abstraction - this is okay - we shouldn't try to hide platform differences, just make it as easy to use as possible.
As such I have put together the following api.
Api Suggestion
Feature
First is to add a single Feature.
Presentation Features
Add an extended presentation capabilities bitflag that is queryable from the surface. I am separating this from regular features because they are more useful as default-on. Having the single feature means that users have to consciously enable it, but without needing to individually modulate them.
Presentation Signature
The presentation signature will be changed to the following.
Presentation Timestamp
Because different apis use different timestamps - we need a way of correlating these timestamps with various other clocks. The clocks used are as follows on each WSI:
Add the following function to the surface.
Which will let people write the following code to correlate instants and presentation timestamps. We need this because
Instant
s need to be treated as completely opaque as the clock they use can change at any time. In most cases these are actually the same clock, but this is what we get.Presentation Statistics
Because of the difference in how all the apis query stats, we need to abstract this carefully. We use a query-based "presentation statistics queue".
vkGetPastPresentationTimingGOOGLE
which drains the queue.Presentation Wait
First add the following member to SurfaceConfiguration:
This adjusts either the swapchain frame count to
value + 1
- or sets SetMaximumFrameLatency to the value given, or uses a wait-for-present in the acquire method to limit rendering such that it acts like it's avalue + 1
swapchain frame set.Monitor Information
Getting exact frequencies of monitors is important for pacing - they can be derived from presentation stats, but an explicit api is more precise if it is available.
Conclusion
This is obviously one hell of an api change, and this doesn't have to happen all at once, but this investigating should give us the place to discuss the changes and make sure it provides the information needed.