src/libANGLE/renderer/gl/ProgramExecutableGL.h


Log

Author Commit Date CI Message
Shahbaz Youssefi 0c4d6446 2024-01-24T10:38:45 Rework uniform block <-> uniform buffer mapping In GLES, the shader declares which buffer binding a block (uniform, storage or atomic counter) is bound to. For example: layout(binding = 1) uniform ubo0 { ... }; layout(binding = 2) uniform ubo1 { ... }; layout(binding = 1) uniform ubo2 { ... }; In the above, ubo0 and ubo2 use data from the buffer bound to index 2 (through glBindBufferRange), while ubo1 uses data from the buffer bound to index 1. For uniform blocks in particular, omitting the binding is allowed, in which case it is implicitly bound to buffer 0. GLES allows uniform blocks (and only uniform blocks) to remap their bindings through calls to glUniformBlockBinding. This means that the mapping of uniform blocks in the program (ubo0, ubo1, ubo2) to the buffer bindings is not constant. For storage blocks and atomic counter buffers, this binding _is_ constant and is determined at link time. At link time, the mapping of blocks to buffers is determined based on values specified in the shaders. This info is stored was stored in gl::InterfaceBlock::binding (for UBOs and SSBOs), and gl::AtomicCounterBuffer::binding. For clarity, this change renames these members to ...::inShaderBinding. When glUniformBlockBinding is called, the mapping is updated. Prior to this change, gl::InterfaceBlock::binding was directly updated, trumping the mapping determined at link time. A bug here was that after a call to glProgramBinary, GL expects the mappings to reset to their original link-time values, but instead ANGLE restored the mappings to what was configured at the time the binary was retrieved. This change tracks the uniform block -> buffer binding mapping separately from the link results so that the original values can be restored during glProgramBinary. In the process, the support data structures for tracking this mapping are moved to ProgramExecutable and the algorithms are simplified. Program Pipeline Objects maintain this mapping identically to Programs and no longer require a special and more costly path when a buffer state changes. This change prepares for but does not yet fix the more fundamental bug that the dirty bits are tracked in the program executable instead of the context state, which makes changes not propagate to all contexts correctly. Bug: angleproject:8493 Change-Id: Ib0999f49be24db06ebe9a4917d06b90af899611e Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5235883 Reviewed-by: Geoff Lang <geofflang@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi b007c74d 2024-01-23T14:17:54 GL: Separate dirty bits leading to glUniformBlockBinding The GL backend is special in that it needs to make actual calls (native glUniformBlockBinding) in response to (application) glUniformBlockBinding calls. The other backends just remap the bindings based on that information when creating descriptor sets. Previously, an optimization to track which bindings have changed used the same dirty bits that were used to signify when the GL backend needs to make these native calls. That ended up as a source of bugs. In a previous change [1], the context DIRTY_BIT_UNIFORM_BUFFER_BINDINGS is set when these mappings change, which fixes some of these issues. That change obviates the need for an actual backend sync of programs, except for GL programs that need to make these native calls. This change splits the dirty bits maintained for the purposes of the GL backend, moves them to that backend and removes the program backend sync. [1]: https://chromium-review.googlesource.com/c/angle/angle/+/5228599 Bug: angleproject:8493 Bug: b/318806125 Change-Id: I73c6514e88a116f1cd701cb06da0d8c38f07f7f6 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5230137 Reviewed-by: Geoff Lang <geofflang@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Alexey Knyazev 3b555e8d 2023-10-26T00:00:00 GL: Add emulateClipOrigin workaround Older Adreno drivers apply GL_CLIP_ORIGIN_EXT to the framebuffer instead of the clip space, thus causing various side-effects. Used a uniform to emulate the correct behavior. Drive-by: * Fixed a typo in ClipControlTest.OriginFrontFacing Fixed: angleproject:8392 Change-Id: I2f7145977ab0e11dc88e8dbfec2cd32c4c31f830 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4987326 Reviewed-by: Geoff Lang <geofflang@chromium.org> Commit-Queue: Alexey Knyazev <lexa.knyazev@gmail.com>
Shahbaz Youssefi eb0d5997 2023-09-15T16:41:13 Move set/get uniform machinery to ProgramExecutable This is done because some uniforms are internally added by the compiler (draw ID, base vertex, and base instance) and are automatically set **on the installed executable**. This change fixes scenarios where a draw is done after a program has failed a relink, and therefore is unable to correctly set the uniforms (as it does not have access to the executable that is installed). It also fixes draws that use those uniforms in a PPO. Bug: angleproject:8297 Change-Id: Id74b4984b88aa09b5b81be1c91412d6c91711136 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4864693 Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Yuxin Hu <yuxinhu@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi 48e2c605 2023-09-07T14:30:46 More instances of program usage converted to executable Bug: angleproject:8297 Change-Id: I8e4eeef8f4f20610bbe0f994ce1141c17d588765 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4850888 Reviewed-by: Shahbaz Youssefi <syoussefi@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Geoff Lang <geofflang@chromium.org>
Shahbaz Youssefi 06411d16 2023-09-06T13:23:34 GL: Use the executable instead of program In a few places, the program was still being directly referenced instead of the executable (in particular when dealing with multiview). Bug: angleproject:8297 Change-Id: I15d0865bf58376a9f85efeec739dd93b49ceaea7 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4846475 Reviewed-by: Geoff Lang <geofflang@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi 4c0c837e 2023-08-25T13:46:36 GL: Move program state to ProgramExecutableGL Bug: angleproject:8297 Change-Id: Ie6a1d536c93f841c792052c58249952e8468348d Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4811439 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Geoff Lang <geofflang@chromium.org>
Shahbaz Youssefi bb135f0e 2023-08-24T15:29:11 Make ProgramExecutableImpl managed by ProgramExecutable This change allows both parts of the program executable to be safely backed up and swapped on link. Bug: angleproject:8297 Change-Id: I17e4b6c05e4e481a66a227d6047dbf943d2c2603 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4812138 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Geoff Lang <geofflang@chromium.org>