4 Commits

Author SHA1 Message Date
JoshJRive
4e0836dbf9 Add background draw shader loading to GL, D3D11, and D3D12 (#10388) c681049169
This adds AsyncPipelineStateManager to the render code, which handles the background processing of draw shader creation (not, at the moment, other shader types...there's no reason those couldn't be added as well, but this seemed the biggest target).

    If a given shader has not been compiled yet, we will fall back on an ubershader version with all features enabled
        the ubershader version will be compiled synchronously if it does not exist yet
    For the D3Ds, this is done with a background thread that compiles the shaders.
    GL, however, does not seem to play nice with background threading shader creation. But what it does have is the KHR_parallel_shader_compile extension, which basically lets the driver create threads in the background and thread the shader compilation.
        The shader manager, in this case, needs to poll the completion state every time the shader is requested and potentially push the compilation along to the next stage (i.e. once linkProgram has completed, then we can do the rest of our setup)
        If KHR_parallel_shader_compile is not supported (for instance, with WebGL on Firefox) then shader compilation will just happen synchronously (I could not find a clear way to thread the GL shader creation, but I would happily add it as a fallback if there is a way)

This change also updates our GLAD loader to version 2.0.8 (from 0.1.36!), which had some API changes.

Co-authored-by: JoshJRive <joshua@rive.app>
2025-08-22 04:00:47 +00:00
csmartdalton
358b43f4d7 Update ANGLE_shader_pixel_local_storage usage
Update our bindings, definitions, and usage to reflect the latest updates to the extension. Notably, we can now compile programs while PLS is active, so no need for the duplicated logic inside and outside of PLS being active.

Diffs=
85cdb31022 Update ANGLE_shader_pixel_local_storage usage (#9367)

Co-authored-by: Chris Dalton <99840794+csmartdalton@users.noreply.github.com>
2025-04-03 20:10:06 +00:00
csmartdalton
12d54ef3e7 Calculate LOD ahead of time for image paints
Since we don't do perspective transformations, the mipmap
level-of-detail for image paints is constant throughout the entire
shape. We can therefore save time by calculating the LOD ahead instead
of relying on shader derivatives in the fragment shader. This also saves
us from having to compute these derivatives explicitly outside of
control flow, which further improves performance.

To make room for LOD in the paintAuxBuffer, we also drop support for GL
bindless textures, which do not work similarly to descriptor indexing in
Vulkan, which we will use in the future if we decide this is a feature
we need.

Diffs=
7bef90845 Calculate LOD ahead of time for image paints (#8260)

Co-authored-by: Chris Dalton <99840794+csmartdalton@users.noreply.github.com>
2024-10-04 16:37:15 +00:00
rivessamr
1b24bf9f89 Initial file moves and renames
Diffs=
25d423274 Initial file moves and renames (#7951)

Co-authored-by: rivessamr <suki@rive.app>
2024-08-27 22:26:30 +00:00