- now the DynamicResolutionOptions don't specify the target frame rate,
they only specify how to scale this given view
- there is a new FrameRateOptions setting on Renderer, which is used
to specify the desired target frame rate for the whole Renderer
- the frame rate is now specified as a "frame interval" in units of
the display frame period.
- the display frame period is (indirectly) set via DisplayInfo.
In other words, the use must set (and update) DisplayInfo properly
(the default are reasonable, but assume 60 Hz). They must also set the
desired interval (default is 1, which is probably what you want).
Finally they must enable dynamic scaling per View, the defaults are
also reasonable.
Currently Renderer doesn't attempt (yet) to actually target the
requested frame rate, so it's up to the caller to push frames at the
desired speed. however, dynamic resolution, like before, will attempt
to shrink work to fit the target.
Renderer can now be given a DisplayInfo that contains some
important information about the current display. This will be used
for frame-pacing and dynamic-resolution.
This is most relevant on Android, where we can accurately query these
parameters. Added support for that in our samples.
This also sets the minSDK to 19 (including gltf viewer's), since this is
the version we support. We were cheating before by under-reporting our
minSdk.
Until now, only the memory of Hw handes was allocated synchronously,
handles were constructed later asynchronously. This was error prone
with the few (but growing) synchronous calls we have.
Now we have an init<> call that allocates and constructs handles synchronously,
the asynchronous construction if needed, is still performed with construct<>,
which is now implemented as "destroy+construct", this is okay because
most of our handles have trivial dtors.
This fixes a race with TimerQuery and Fence. Fences are still not fully
working though, but at least won't access uninitialized memory.
Currently backend fences MUST be used trough FFence.
On metals (made only of specular light), specular AO can
create large black spots. This change simply kills specular
AO to avoid this artifact. In practice we should take into
account multiple bounces but this is rasterization...
This adds a simple query API to the backend.
There are 2 methods to create/destroy queries, which are
essentially futures. And 3 methods to mesure elapsed time:
beginTimerQuery/endTimerQuery and getTimerQueryValue.
The begin/end pair is not nestable.
On the GL backend side, there are 2 implementations of this, one uses
arb_timer_query or disjoint_timer_query, the other uses fences.
We need both implementations because on some GPUs, including
qualcomm's elapsed-time timer query is useless, as it measures
cpu time.
Metal/Vulkan implementations will be part of subsequent PRs. Vulkan
will be able to implement this with vkWriteTimestamp which is
reported to be accurate.
An immediate benefit is that we can now get frame times on MacOS, which
should allow it to use dynamic-resolution.
the view clear flags would not be honored when rendering directly
into an imported render target.
note: now that this works this could cause an issue when using
multiple views side-by-side and one of them doesn't have a skybox,
that view will trigger a clear of the whole buffer (because clears
clear everything, not just the viewport).
A solution will come in a later PR.
Fixes#2312
Pixelflinger
Ben Doherty
Romain Guy
Philip Rideout