The main issue that gets fixed here are:
- VK_IMAGE_LAYOUT_UNDEFINED cannot be used if the image content is to
be preserved after the transition. Unfortunately, there is more than a
few places in the VK backend where we use VK_IMAGE_LAYOUT_UNDEFINED on
images that are later used as sources.
- accessing an image memory from the host is only supported if the the
layout is PREINITIALIZED or GENERAL. However, images in the staging
pool were transitioned to other layouts and put back into the pool,
later they would be mapped/memcpy'ed into. Instead we now always use
the GENERAL layout and never change it.
- images that where in the pool where transitioned using the miplevel
of the texture we were copying into, however this didn't make sense
because images from the pool don't have mip levels.
As part of these fixes, we also refactor imageLayoutTranstion(),
because there was two copies of this function, one specific to texture
and another one more generic. We now always use the more generic one,
with a new helper for textures.
Note: didn't fix "readPixels" which has at least problem (1), because
it's a tricky implementation, and it requires more toughts.
A new Engine::pumpMessageQueues() method can be used to trigger all
pending user callbacks right away. This can help reducing latency
of certain callbacks such as picking queries.
This is typically called once before calculating the next frame's
parameters (e.g. object positions or appearance that may depend on a
callback result).
Fix some comments and documentation.
This is a pixel accurate implementation of picking. Picking queries
can be created on view, and upon completion a user provided callback
is called with the Entity of the renderable at the queried coordinates
in the viewport.
Picking queries typically have 1 or 2 frame of latency and may impact
performance on some drivers.
It is mostly intended for use by editors, or when latency is not a major
concern. This api should not be used for dragging/moving objects, it is
intended for initial picking only.
Picking is implemented in the structure pass.
The depth buffer value is retrieved and the fragment coordinate is
reconstructed and passed to PickingQueryResult. This can be used in
turn to calculate the view and/or world space position.
This is just a minimal change to get the R_INTEGER format to work.
- if src/dst types are identical, just copy (this avoids a mul and a div)
- add R,RG and INTEGER types
There a just new inline helpers to more easily use lambdas, functors and
method callbacks with {Pixel}BufferDescriptor.
A BufferDescriptor can be constructed like this:
auto bd = BufferDescriptor::make(buffer, size, [](void* b, size_t s){ });
or
auto bd = BufferDescriptor::make(buffer, size, &Foo::bar, *foo);
the code generating the commands for the structure pass (called DEPTH)
in the code was different that from the color. This made sense, but
isn't great from an architectural standpoint.
Moreover, the special filtering flags DEPTH_FILTER_*_OBJECTS were
useless because part of their functionality was handled in the DEPTH
code directly.
Instead, we now generate the DEPTH commands the same way than we do for
COLOR, but we honor the DEPTH_FILTER_*_OBJECTS flags properly.
This should help Filament properly support more glTF assets with
transparency, and should make Filament behave more like other
renderers such as three.js.
The finalizer can't be used to dispose of filament resource, because
it runs on its own thread.
Added a destroy() method to all IBLPrefilter related classes that must
be called once the object is no longer needed.
note: Resources will be freed eventually anyways when the Engine itself is
destroyed.
fixes#4633
A lod bias can be applied to textures when dynamic resolution is
enabled. A proper lod bias is calculated and applied for quality levels
HIGH and ULTRA.
Lod Bias is implemented in glslang, which mean it's ignored when
glslang is not used, which currently happens with OpenGL backends with
optimization turned off (which includes filament LITE). This may be
fixed in the future.
We were decrementing activeJobCount after removing the job from the
queue, which could cause other threads in the pool to preempt us before
the decrement, causing them to spin forever trying to get a non-existant
job, until the decrement actually happened.
Now we always decrement first and fix-up the count if we couldn't get
a job from the queues. The race is inverted, and doesn't cause threads
to spin a long time.
the gc usually runs for a very short amount of time, so the jobsystem
overhead is very significant compared to the actual work.
additionally this works around a scheduling issue that happens sometimes
on some devices where a thread could be "runnable but not running" for
many milliseconds.
On some GPU such as Adreno, the shader compiler flattens the early
exit condition, which becomes useless. We work around this by using a
two pass version of the algorithm using the depth buffer for
skipping "fast" fragments that have already been rendered.
This improves performance significantly, e.g. from 5ms to 1.3ms on
Pixel4.
Currently this mode is always enabled, which hurst performance on GPUs
that don't have this problem. This will be remediated later.
Now that FSR scaling is cheap enough on mobile, we use it for quality
levels MEDIUM to ULTRA.
MEDIUM and HIGH use the mobile optimized version, which has a slightly
lower quality, ULTRA uses the original version.
Additionally the RCAS sharpening pass can always be disabled by setting
the sharpen value to 0.
We used the "float" code with the "half" texture coords, turns out FSR
uses slightly different code for both.
We're now using the "half" code (using mediump float).
