This fixes incorrect rendering when either the source or backdrop
tasks establish a raster root.
By design, it also changes mix-blend backdrop readbacks to work in
a way that can handle readbacks from picture cache tiles, which is
a follow up optimization being worked on.
Differential Revision: https://phabricator.services.mozilla.com/D103853
In bug 1687394, the semantics of `requested_raster_space` were
changed to only take effect when an intermediate surface was
created.
However, this causes a regression to snapping with text runs
that are animated on the root surface (such as loading spinner
glyphs).
To fix that, while also keeping the functionality of the previous
patch (removing a source of pass-through pictures), there is now
a stack of requested raster space pushed and popped for each
stacking context. This is read and stored by text runs during
scene building, ensuring that these animated glyphs select the
correct raster space to avoid snapping / jittering bugs.
Differential Revision: https://phabricator.services.mozilla.com/D104345
The result of compute_aa_range depends on fwidth(local_pos). In the no-perspective case,
the derivatives of local_pos are constant across an entire primitive. SWGL fast-paths only
run in the no-perspective case anyway, so it is convenient to compute the aa_range once
for the entire span and then reuse it, factoring out this per-pixel cost.
Differential Revision: https://phabricator.services.mozilla.com/D104294
This fixes incorrect rendering when either the source or backdrop
tasks establish a raster root.
By design, it also changes mix-blend backdrop readbacks to work in
a way that can handle readbacks from picture cache tiles, which is
a follow up optimization being worked on.
Differential Revision: https://phabricator.services.mozilla.com/D103853
This fixes incorrect rendering when either the source or backdrop
tasks establish a raster root.
By design, it also changes mix-blend backdrop readbacks to work in
a way that can handle readbacks from picture cache tiles, which is
a follow up optimization being worked on.
Differential Revision: https://phabricator.services.mozilla.com/D103853
This change had previously been backed out due to causing rendering
issues on HTC 10 Android, and some Linux Radeon cards (bug 1687554).
On the HTC 10, the issue was that the extra case statement added to
the text run shader caused the glslopt optimized shader to become too
complex for the device, resulting in rendering issues. Since bug
1689316 has landed, the optimized shader output is simpler and this
issue is avoided.
On radeon, we have established that the problem is due to the format
of the texture and that the shader is fine. Furthermore, the shader
works correctly with either R8 or RGBA8 texture data, as all of the
channels contain the alpha value in the RGBA8 textures. Therefore we
continue to use RGBA8 textures for alpha glyphs on Linux Radeon, but
switch to R8 on other platforms.
Differential Revision: https://phabricator.services.mozilla.com/D104082
Previously, we've taken the strategy of exposing any gecko specific hooks
as traits. The disadvantage of this approach is that it requires plumbing
a boxed trait through to any places that need to use it.
With this approach, we add global functions that don't do anything when
compiled without the 'gecko' feature. This makes it easier to add hooks
and avoids the plumbing which should reduce friction in the process
of moving more stuff out of gecko and into webrender.
Differential Revision: https://phabricator.services.mozilla.com/D102334
Our existing batched texture upload logic works with pixel buffer objects which we don't use with ANGLE.
The motivation is to avoid expensive driver overhead from submitting many glTexSubImage2D calls (one for each texture cache item) on low-end Intel Windows configurations.
On Windows+Intel it is much faster to use batched draw calls to copy from staging textures to texture cache than using CopySubResourceRegion (when there is a high number of copies).
Differential Revision: https://phabricator.services.mozilla.com/D103333
We have encountered issues on some platforms due to a large number of
if statements in shaders. The shader optimizer previously generated
code with a large number of if statements, due to the way in which it
optimized switch statements.
Previously the optimizer output 2 if statements for every case in a
switch. First it ORs the "fallthrough" var with the case's
condition. Then sets the fallthrough var to false if the "break" var
is true. Then conditionally executes the case's instructions if
fallthrough is true. For example:
switch (uMode) {
case 0:
gl_Position = vec4(0.0);
break;
case 1:
gl_Position = vec4(1.0);
break;
}
becomes:
bool break_var = bool(0);
bool fallthrough_var = (0 == uMode);
if (break_var) fallthrough_var = bool(0);
if (fallthrough_var) {
gl_Position = vec4(0.0, 0.0, 0.0, 0.0);
break_var = bool(1);
};
fallthrough_var = (fallthrough_var || (1 == uMode));
if (break_var) fallthrough_var = bool(0);
if (fallthrough_var) {
gl_Position = vec4(1.0, 1.0, 1.0, 1.0);
break_var = bool(1);
};
This update removes one of these ifs, by ANDing the fallthrough_var
with !break_var rather than conditionally setting it to false. eg:
bool break_var = bool(0);
bool fallthrough_var = (0 == uMode);
if (fallthrough_var) {
gl_Position = vec4(0.0, 0.0, 0.0, 0.0);
break_var = bool(1);
};
fallthrough_var = (fallthrough_var || (1 == uMode));
fallthrough_var = (fallthrough_var && !(break_var));
if (fallthrough_var) {
gl_Position = vec4(1.0, 1.0, 1.0, 1.0);
break_var = bool(1);
};
This is logically equivalent but uses half as many if statements,
which helps to avoid driver bugs on some platforms.
Differential Revision: https://phabricator.services.mozilla.com/D103713
We keep encountering issues on various platforms due to the usage of
switch statements, especially the optimized output produced by
glslopt. Replace all instances with if-else statements instead.
Differential Revision: https://phabricator.services.mozilla.com/D103300
Currently when the GPU cache is resized we allocate a new texture and
then copy the contents of the old texture to the new texture. This
copy requires either EXT_copy_image (for glCopyImageSubData) or
EXT_color_buffer_float (to bind the RGBAF32 texture to a framebuffer).
On devices where neither extension is supported, don't attempt to copy
the old texture. Instead mark the entire CPU-side copy of the cache as
dirty, meaning we will subsequently upload the entire contents to the
new texture. (A complete CPU-side copy is only mainted for the
PixelBuffer gpu cache bus type, not for Scatter ones. However, as the
Scatter type also requires EXT_color_buffer_float, we will only be in
this situation for PixelBuffer buses.)
Differential Revision: https://phabricator.services.mozilla.com/D103071
Instead of keeping a stacking context around for scrollbar containers,
extend and use the tile cache barrier code to create them. This
removes the final remaining code path that creates pass through
picture primitives.
The tile cache barrier changes also form the basis of how we will
make blend containers and backdrop roots work in a follow up patch.
Blend containers and backdrop roots will become redundant stacking
contexts when they exist at the start of a tile cache, which will
save an entire off-screen surface / constant invalidation.
Differential Revision: https://phabricator.services.mozilla.com/D102527
Previously, a leaf picture would be created unconditionally when
popping a stacking context during scene building. This results in
many pass-through pictures being created that are often not required.
This patch introduces a helper struct that delays creation of a
pass-through wrapping picture until it's known to be needed (and
instead adds the prim_list to a wrapping picture where possible).
In a follow up patch, the last couple of places that create pass
through pictures via pop_stacking_context will be removed.
Differential Revision: https://phabricator.services.mozilla.com/D102381
Under software WebRender, performance is substantially improved if we make the approximations in ClipItemKind::get_clip_result more accurate.
That function's job is to decide whether a primitive falls entirely inside a
clip, entirely outside it, or has regions of both. If the primitive is known to
fall entirely inside the clip, WebRender doesn't bother applying the clip to it.
This also saves WR the trouble of rendering the clip mask itself - which is what
the cs_rectangle_clip shader is spending a lot of time on when displaying these
pages.
Before this change, ClipItemKind::get_clip_result handles rounded rectangle clip
regions by computing an 'inner rect', a rectangle inset from the rounded
rectangle on each side by the relevant rounding radii. This is a correct
conservative approximation, but it means that any primitive that lies flush with
one of the flat sides of the clip is considered to only be partially within the
clip, and thus needs to have the clip mask applied - even though simple
rectangle intersection would serve.
With this change, instead of an 'inner rect', we approximate the rounded
rectangle by a rectangle with rectangular chunks taken out of each corner. This
lets us recognize more primitives as being fully within the clip, and apply the
clip mask less often.
Differential Revision: https://phabricator.services.mozilla.com/D102526
the storage logic was made for, and used exclusively in, the prim_store.
Moving it into the sub-module and making it private allows for easier navigation in the code.
Differential Revision: https://phabricator.services.mozilla.com/D102494
Bug 1685563 switched to using R8 textures instead of BGRA8 for
non-subpixel AA glyphs. This caused rendering issues on certain
android and linux devices, so switch back temporarily until those
issues are fixed.
Differential Revision: https://phabricator.services.mozilla.com/D102465
Currently we expire old picture cache tiles at the end of the frame,
immediately before garbage collecting them. This means that new
textures have already been allocated for newly-created picture cache
tiles, so we often end up both allocating and destroying textures in
the same frame.
Instead, move the call to expire_old_picture_cache_tiles() to the
beginning of the frame. Picture cache tiles added to the cache during
the frame can then recylce these textures rather than allocate new
ones. Garbage collection still occurs at the end of the frame,
destroying freed textures that were not recycled.
Note that expire_old_picture_cache_tiles() frees picture cache tiles
which were unused in the *previous* as well as the current frame. This
is a legacy from when the function freed all types of texture cache
entries, and could be called throughout the frame. Immediately prior
to this change, it could in fact have just checked for usage during
the *current* frame, as the function was only called at the end of the
frame. However, as this change moves the call to the beginning of the
frame, we do actually now need to check for usage during
the *previous* frame.
Differential Revision: https://phabricator.services.mozilla.com/D102349
Removes another case of pass through pictures, by handling the rare
case of a stacking context with backface-visibility: false that is
_not_ part of a 3d rendering context as an offscreen surface.
Differential Revision: https://phabricator.services.mozilla.com/D102251
Previously, it was possible to request a local/screen raster
space even if the owning stacking context didn't create an
offscreen surface.
This complicates various parts of the code, and also results
in a pass-through picture primitive being created (which we
want to remove as part of the work for #1684781).
With this change, it's only possible to change the raster space
when the enclosing stacking context creates an offscreen surface
for some other reason (e.g. 3d transform, filters etc).
Differential Revision: https://phabricator.services.mozilla.com/D102244
Instead, top level tile cache pictures are stored in the scene.
Follow up tasks in this bug will be simplified by having pictures
only exist when they have Some(..) for requested_composite_mode.
This patch removes one case of a pass-through picture, and
simplfies some of the surrounding code in the process.
Differential Revision: https://phabricator.services.mozilla.com/D101539
All LRU partitions use the same freelist to store the entries, and only have
separate LRU indexes. The shared freelist makes it easier to transfer an entry
from one LRU partition to another. If instead we used different LRUCache
instances, moving entries between partitions would be cumbersome because we
would need to look up the strong handle for the entry so that we could remove it
from the old freelist.
Differential Revision: https://phabricator.services.mozilla.com/D102122
When I wrote this patch, I thought that it would simplify the next patch in this
series, but I think it didn't make much of a difference in the end.
I still think this patch improves things and is worth taking, though.
Differential Revision: https://phabricator.services.mozilla.com/D102121
The limit wasn't doing anything useful anymore, because one of the recent texture
cache refactorings made it so that we weren't actually evicting these glyphs from
the texture cache. In the future, we can implement a similar limit in the texture
cache itself, by giving it per-cache-type limits rather than a global limit.
Differential Revision: https://phabricator.services.mozilla.com/D101834
The new version contains
- A bug fix for the bucketed allocator (we don't currently use it)
- A few fixes that can happen when requesting large enough allocation sizes to cause integer overflows. At the moment we never request an allocation larger than 512px so we are safe but it's still good to stay up to date.
Differential Revision: https://phabricator.services.mozilla.com/D101608
Add a new texture type alpha8_glyphs to the texture cache and store
alpha glyphs in it. Because the opengl texture format is R8 but the
shader requires to read the texture's alpha channel, we must swizzle
the components. We cannot rely on texture swizzling due to driver
bugs, so add the necessary code to the shader to do so manually.
Differential Revision: https://phabricator.services.mozilla.com/D101643
ANGLE appears to truncate uploads from a PBO in cases where the
UNPACK_ROW_LENGTH is greater than the width of the upload. We
encounter this due to rounding up the stride of our data to be a
multiple of 4 bytes. Don't do that on ANGLE.
Note that we only hit this issue in wrench, as in Firefox we do not
use PBO uploads with ANGLE.
Differential Revision: https://phabricator.services.mozilla.com/D101663
The previous traversal strategy for assigning render tasks is very
simple and works fine for normal content. However, it's possible to
create graphs with very deep levels of nesting and dependencies
that cause the pass traversal to not terminate quickly.
This patch contains two changes to fix these cases:
- Recursion in assign_render_pass will early out if a shorter
path has been found.
- Remove recursion from assign_free_pass, iterating each task once.
Differential Revision: https://phabricator.services.mozilla.com/D101541
In cases where clips are in the same coordinate space as the parent
picture surface (but different from the primitive), we can apply
a simple optimization to reduce the size of clip mask allocations.
In the linked test case, this drastically reduces the size of clip
masks that are drawn (each of the many clip masks drops from approx
1000 x 1000 pixels to approx 64 x 64 pixels).
Differential Revision: https://phabricator.services.mozilla.com/D101298
Restructure how frame building handles building of the surface
render task structures.
In future parts of this bug, a surface may have multiple "sub-passes"
where the rendering is separated into different render tasks that
write to the same target (without clear on subsequent sub-passes).
For example, this will be used to allow mix-blend-mode and
backdrop-filter to issue readbacks directly from picture cache
tiles rather than forcing draws to an intermediate surface.
The `add_child_render_task` method will be expanded to support
the case of a surface having multiple sub-passes, adding the
render task to the correct sub-pass.
Differential Revision: https://phabricator.services.mozilla.com/D101122
This is a small extract from a change I tried to land earlier.
It refactors the GL version queries, no functional changes here.
Differential Revision: https://phabricator.services.mozilla.com/D101082
render_impl() calls draw_frame(). We were drawing the debug overlays in both
functions, so the overlays were rendered twice.
This patch removes the drawing in draw_frame() and keeps the one in render_impl().
For anything that uses the debug renderer, such as the "epochs" overlay, this
means that the drawing commands were appended twice, and then all commands were
executed at the end of render_impl().
Comparing the "epochs" debug overlay with and without this change, this patch
noticeable]y reduces its opacity from "extra opaque" (due to double drawing) to
"normal translucency".
Also, when the native compositor was used, any debug drawing in draw_frame()
that wasn't using the debug renderer didn't actually work, because it wasn't
going into the debug overlay surface - only render_impl() correctly binds the
debug overlay surface when the native compositor is used.
Differential Revision: https://phabricator.services.mozilla.com/D100961
In bug 1676474 an issue was reported regarding partial present on
Mali-G77 devices. This was introduced in bug 1675159, which refactored
some partial present logic and shifted the order of some OpenGL calls
around. As a precaution, we disabled the feature on all Mali-Gxx
devices.
The bug seems to occur when eglSetDamageRegion is called after
rendering to an offscreen render target (in this case due to texture
cache or GPU cache updates), but without the driver being flushed in
some way. This appears to be a bug in the Mali driver.
This patch moves the eglSetDamageRegion call back to its original
location -- after all offscreen render targets have been rendered,
immediately before rendering to the main framebuffer -- which fixes
the issue. It also re-enables the feature on all Mali-Gxx devices.
Differential Revision: https://phabricator.services.mozilla.com/D101018
Most of that is *rendering* logic, so the change moves it closer to the renderer.
One tiny bit - `enum DebugItem` - is used in frame building, so I left it in its own small module at the root.
Differential Revision: https://phabricator.services.mozilla.com/D100936
This isn't very systematic as I'm not sure the best approach for that
yet. That being said, this captures the bulk of the autoreleases without
that happen without a pool.
Differential Revision: https://phabricator.services.mozilla.com/D100363
There is a driver bug on old versions of the Adreno driver which
prevents usage of persistenly mapped buffers for texture
uploads. Creating and mapping the buffer works correctly, but
attempting to upload to a texture from the buffer results in an error
due to the buffer still being mapped.
This means that no texture data is uploaded, essentially meaning that
we do not render anything at all.
It appears to affect at least Adreno 4xx and 5xx devices running
Android 6. For now, simply disable persistent mapping on all Adreno
devices, until we know more specifically which are affected.
Differential Revision: https://phabricator.services.mozilla.com/D100391
There are probably other places that have this kind of problem but this
keeps thing simple for now and might be sufficient to get things under
control.
Further work will follow.
Differential Revision: https://phabricator.services.mozilla.com/D100294
this is probably the last of the low-hanging fruits in renderer submodules.
I think it would be very useful to try isolating the scene building stuff in a similar way.
So in the end, the root `src` should only contain things that are used by multiple stages of WR.
Differential Revision: https://phabricator.services.mozilla.com/D100263
This patch introduces the new frame graph implementation, which
allows for more advanced and efficient render task graphs.
The goal of this initial work is to achieve feature parity with
the existing render task graph.
Follow up work will take advantage of the new graph functionality
to improve the efficiency of current mix-blend-mode, backdrop-filter
and svg filter operations.
Differential Revision: https://phabricator.services.mozilla.com/D99743
This patch introduces the new frame graph implementation, which
allows for more advanced and efficient render task graphs.
The goal of this initial work is to achieve feature parity with
the existing render task graph.
Follow up work will take advantage of the new graph functionality
to improve the efficiency of current mix-blend-mode, backdrop-filter
and svg filter operations.
Differential Revision: https://phabricator.services.mozilla.com/D99743
Once the new graph API is in place, it becomes possible to express
an input dependency on a persistent target (for example, if wanting
to read back from a picture cache tile for a mix-blend, or marking
that a color target depends on a render task in a texture cache).
To make that simpler to express, this patch adds a specific struct
for render target locations that are persistent, and updates the
surrounding code to use it. At the same time, introduce an Unallocated
field for dynamic tasks that are not yet allocated, rather than
using an Option.
Differential Revision: https://phabricator.services.mozilla.com/D99305
This patch splits the graph building functionality into
`RenderTaskGraphBuilder` and the graph querying code into
the existing `RenderTaskGraph` struct.
The Builder struct is retained frame to frame, which means
there is no longer a need for the `RenderTaskGraphCounters`
struct. The Graph struct is constructed per-frame by calling
`end_pass` on the Builder.
Although this doesn't do much different internally, it will
make integration with the new task graph changes simpler. It
also enforced during frame building when it is possible
to add / query render tasks.
A few unrelated tidy ups are included in this patch - mostly
removing where the task graph is passed to from a few structs
and methods that no longer require access to the graph.
Differential Revision: https://phabricator.services.mozilla.com/D99297
This patch makes picture cache tiles use normal textures instead
of array textures. With this and the previous patch, WR no longer
uses array textures at all (except when provided by the external
image handler trait).
Differential Revision: https://phabricator.services.mozilla.com/D99013
Mainly this implements a new set of SWGL intrinsics based around swgl_allowTextureNearest
and swgl_commitTextureNearest which can fairly easily provide a further fast-path above
and beyond swgl_commitTextureLinear. This requires the row be from an axis-aligned 1:1
draw so that we can do something not unlike a fast copy of the texture data straight
to the destination in cases where even the linear filter would be essentially doing
the same thing in a more expensive way. For now, only a few WR shaders that were already
using swgl_commitTextureLinear have been fast-pathed with the new intrinsics to see if
this provides significant performance benefit.
Differential Revision: https://phabricator.services.mozilla.com/D100079
It's always supplied by Gecko anyway, and being able to rely on this
will make it easier to create stable spatial node IDs that persist
across display lists.
Differential Revision: https://phabricator.services.mozilla.com/D100076
Once the new graph API is in place, it becomes possible to express
an input dependency on a persistent target (for example, if wanting
to read back from a picture cache tile for a mix-blend, or marking
that a color target depends on a render task in a texture cache).
To make that simpler to express, this patch adds a specific struct
for render target locations that are persistent, and updates the
surrounding code to use it. At the same time, introduce an Unallocated
field for dynamic tasks that are not yet allocated, rather than
using an Option.
Differential Revision: https://phabricator.services.mozilla.com/D99305
This patch splits the graph building functionality into
`RenderTaskGraphBuilder` and the graph querying code into
the existing `RenderTaskGraph` struct.
The Builder struct is retained frame to frame, which means
there is no longer a need for the `RenderTaskGraphCounters`
struct. The Graph struct is constructed per-frame by calling
`end_pass` on the Builder.
Although this doesn't do much different internally, it will
make integration with the new task graph changes simpler. It
also enforced during frame building when it is possible
to add / query render tasks.
A few unrelated tidy ups are included in this patch - mostly
removing where the task graph is passed to from a few structs
and methods that no longer require access to the graph.
Differential Revision: https://phabricator.services.mozilla.com/D99297
This patch makes picture cache tiles use normal textures instead
of array textures. With this and the previous patch, WR no longer
uses array textures at all (except when provided by the external
image handler trait).
Differential Revision: https://phabricator.services.mozilla.com/D99013
With this change, all color/alpha intermediate surfaces are individual
textures, rather than texture arrays.
This can in theory cause more batch breaks in some cases, but this
is likely to be very rare in practice.
Benefits:
- No more allocating the array at the size of the largest task / slice.
- Remove a source of many driver bugs on android devices.
- Simplify integration of future patches with render task graph.
Much of the render target array texture code is still present, since
picture cache tiles in the Draw compositor still make use of texture
arrays. However, once these are switched to normal textures, we can
remove most of the slice layer, blit workaround functionality etc.
Remove the default feature setting for selecting the image sampler
kind. Instead, this must be explicitly specified by the shader or
a dynamic feature define, which makes sampler selection less error prone.
Differential Revision: https://phabricator.services.mozilla.com/D99006
Remove usage of the implicit prev pass alpha and color texture
samplers from batching / renderer / shader code. They are replaced
by explicit references to the texture ID for the source task.
Differential Revision: https://phabricator.services.mozilla.com/D98872
With this change, all color/alpha intermediate surfaces are individual
textures, rather than texture arrays.
This can in theory cause more batch breaks in some cases, but this
is likely to be very rare in practice.
Benefits:
- No more allocating the array at the size of the largest task / slice.
- Remove a source of many driver bugs on android devices.
- Simplify integration of future patches with render task graph.
Much of the render target array texture code is still present, since
picture cache tiles in the Draw compositor still make use of texture
arrays. However, once these are switched to normal textures, we can
remove most of the slice layer, blit workaround functionality etc.
Remove the default feature setting for selecting the image sampler
kind. Instead, this must be explicitly specified by the shader or
a dynamic feature define, which makes sampler selection less error prone.
Differential Revision: https://phabricator.services.mozilla.com/D99006
Remove usage of the implicit prev pass alpha and color texture
samplers from batching / renderer / shader code. They are replaced
by explicit references to the texture ID for the source task.
Differential Revision: https://phabricator.services.mozilla.com/D98872
This commit moves the code that deals with allocating into a dynamic amount of textures (TextureUnits) out of texture_cache.rs, rename it into AllocatorList and make it generic.
The code also changes some of the profile counters to count pixels and number of textures instead of number of regions and size in bytes.
I had to introduce two traits which is a bit cumbersome but not so bad. AtlasAllocator is needed to implement AllocatorList with multiple allocators and AtlasAllocatorList is a dyn trait to let the texture cache can select between allocator lists of different type signatures.
Differential Revision: https://phabricator.services.mozilla.com/D98371
This patch adds infrastructure for crash reporter annotations to
WebRender. This is used to expose the new annotation,
GraphicsCompileShader, to indicate which shader we are in the process of
compiling. We often see crash reports when compiling shaders, and it
would be useful to know which one it is compiling.
This also adds another annotation, IsWebRenderResourcePathOverridden,
which is useful to know if someone overrode the shader resource path for
testing purposes. We can likely ignore any crash reports that have this
annotation set.
Differential Revision: https://phabricator.services.mozilla.com/D99736
There might be some overlap with memory counted elsewhere and some of
the size calculations could be wrong but it should give us an overall
picture.
Differential Revision: https://phabricator.services.mozilla.com/D99562
With this change, all color/alpha intermediate surfaces are individual
textures, rather than texture arrays.
This can in theory cause more batch breaks in some cases, but this
is likely to be very rare in practice.
Benefits:
- No more allocating the array at the size of the largest task / slice.
- Remove a source of many driver bugs on android devices.
- Simplify integration of future patches with render task graph.
Much of the render target array texture code is still present, since
picture cache tiles in the Draw compositor still make use of texture
arrays. However, once these are switched to normal textures, we can
remove most of the slice layer, blit workaround functionality etc.
Remove the default feature setting for selecting the image sampler
kind. Instead, this must be explicitly specified by the shader or
a dynamic feature define, which makes sampler selection less error prone.
Differential Revision: https://phabricator.services.mozilla.com/D99006
With this change, all color/alpha intermediate surfaces are individual
textures, rather than texture arrays.
This can in theory cause more batch breaks in some cases, but this
is likely to be very rare in practice.
Benefits:
- No more allocating the array at the size of the largest task / slice.
- Remove a source of many driver bugs on android devices.
- Simplify integration of future patches with render task graph.
Much of the render target array texture code is still present, since
picture cache tiles in the Draw compositor still make use of texture
arrays. However, once these are switched to normal textures, we can
remove most of the slice layer, blit workaround functionality etc.
Remove the default feature setting for selecting the image sampler
kind. Instead, this must be explicitly specified by the shader or
a dynamic feature define, which makes sampler selection less error prone.
Differential Revision: https://phabricator.services.mozilla.com/D99006
Remove usage of the implicit prev pass alpha and color texture
samplers from batching / renderer / shader code. They are replaced
by explicit references to the texture ID for the source task.
Differential Revision: https://phabricator.services.mozilla.com/D98872
This should not have a functional change because today nothing uses the
individual flags and instead always uses ClearCache::all().
Differential Revision: https://phabricator.services.mozilla.com/D99598
When deallocating the last item of the region the region's size is changed in free and we end up returning the wrong value.
The faulty code is actually removed in a later patch from this series but I'd like to fix the regressing now and land the patch that removes the bad code during the next train.
Differential Revision: https://phabricator.services.mozilla.com/D99458
This ID allows the compositor to track per-frame information from frame
generation, through APZ sampling, to the NotifyDidRender notification.
Differential Revision: https://phabricator.services.mozilla.com/D97535
This is a follow up to the addition of a clip mask texture sampler.
With this patch, that sampler is no longer bound to the PrevPassAlpha
input, but is explicitly bound to any arbitrary texture that the
input render task was drawn into. This is a step towards enabling
the full render task graph.
There's a bit of complexity here in that it's now possible for individual
segments to break a batch, if they have clip masks that ended up on a
different texture. This should be an extremely rare case. However, it
does currently result in (even more) code duplication in some of the
batching code - which can be refactored once the render task graph
changes are in place.
Differential Revision: https://phabricator.services.mozilla.com/D98711
This is an incremental but important step to implementing render
tasks as a proper graph.
By moving the render target management to the frame building step,
we know the texture_id of all sub-passes before the batching is
done for any passes that use these as inputs. This means that
we can directly reference the texture_id during batch, rather
that the old `RenderTaskCache` and `PrevPassAlpha` / `PrevPassColor`
enum fields (although removal of all these will be done in the
next patch).
Another advantage of this is that we have much better knowledge
of which targets are required for rendering a given frame, so
these can be allocated up front at the start of a frame. This
may be a better allocation pattern for some drivers. We also
have better knowledge available on when a texture can be
invalidated, and the render target pool management is simpler since
it is the same as the way other texture cache textures are handled.
Differential Revision: https://phabricator.services.mozilla.com/D98547
Remove usage of the implicit prev pass alpha and color texture
samplers from batching / renderer / shader code. They are replaced
by explicit references to the texture ID for the source task.
Differential Revision: https://phabricator.services.mozilla.com/D98872
This is a follow up to the addition of a clip mask texture sampler.
With this patch, that sampler is no longer bound to the PrevPassAlpha
input, but is explicitly bound to any arbitrary texture that the
input render task was drawn into. This is a step towards enabling
the full render task graph.
There's a bit of complexity here in that it's now possible for individual
segments to break a batch, if they have clip masks that ended up on a
different texture. This should be an extremely rare case. However, it
does currently result in (even more) code duplication in some of the
batching code - which can be refactored once the render task graph
changes are in place.
Differential Revision: https://phabricator.services.mozilla.com/D98711
This is an incremental but important step to implementing render
tasks as a proper graph.
By moving the render target management to the frame building step,
we know the texture_id of all sub-passes before the batching is
done for any passes that use these as inputs. This means that
we can directly reference the texture_id during batch, rather
that the old `RenderTaskCache` and `PrevPassAlpha` / `PrevPassColor`
enum fields (although removal of all these will be done in the
next patch).
Another advantage of this is that we have much better knowledge
of which targets are required for rendering a given frame, so
these can be allocated up front at the start of a frame. This
may be a better allocation pattern for some drivers. We also
have better knowledge available on when a texture can be
invalidated, and the render target pool management is simpler since
it is the same as the way other texture cache textures are handled.
Differential Revision: https://phabricator.services.mozilla.com/D98547
Glenn Watson
Nicolas Silva
Jeff Muizelaar
Lee Salzman
Csoregi Natalia
Andreea Pavel
Dorel Luca
Jamie Nicol
Butkovits Atila
Ryan VanderMeulen
Matt Woodrow
Bogdan Tara
Dzmitry Malyshau
Jim Blandy
Markus Stange
Barret Rennie
Razvan Maries
Cosmin Sabou
Mike Hommey
Andrew Osmond
Brindusan Cristian
Xidorn Quan