|
62d9f847
|
2024-07-17T13:27:07
|
|
Speed up UniformBuffer support on Metal
If the sizes are different but all fields match
then only padding remains. So, as long as the
buffer can safely handle the offset and size of
usage, allow drawing without converting the
uniform buffer.
Fixed: angleproject:348270693
Change-Id: I91196ca9839cf064b573d912f125ff4879a85b02
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5719193
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Commit-Queue: Quyen Le <lehoangquyen@chromium.org>
Auto-Submit: Gregg Tavares <gman@chromium.org>
Reviewed-by: Quyen Le <lehoangquyen@chromium.org>
|
|
8ed4d427
|
2024-07-11T00:00:00
|
|
Metal: Remove link tasks dependency on context
Bug: angleproject:351165323
Change-Id: If9e5d141cb15a6fc6df8a5fd9a2cfe70efe19dfc
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5701902
Commit-Queue: Alexey Knyazev <lexa.knyazev@gmail.com>
Reviewed-by: Kenneth Russell <kbr@chromium.org>
|
|
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>
|
|
|
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>
|
|
99d39241
|
2023-09-07T16:48:22
|
|
Metal: Increase the size of the default uniform block
Use a buffer pool per shader type and size it to be a nice multiple of
the block that will be allocated for each uniform update.
Set the buffer pool size to unbounded. When the pool runs out of
buffers it currently does a full CPU/GPU sync which is catastrophic
for performance when uniforms are updated every draw call.
Bug: angleproject:8301
Change-Id: I7f826feb4e766fd1cf1b2db01954af7089e3fe90
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4850950
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Commit-Queue: Geoff Lang <geofflang@chromium.org>
|
|
|
d664543f
|
2023-09-01T23:11:59
|
|
Metal: Move setupDraw and associated code to executable
Last bits of state left in ProgramMtl that are now moved to
ProgramExecutableMtl, and now ContextMtl does not reference the program
at all.
This fix was necessary for a follow up change that allows the program to
be modified while the executable is installed, and the metal backend was
crashing after a failed relink due its direct access to the program.
Bug: angleproject:8297
Change-Id: Iadf623bf6baf612767ff372adee2e7f4eeedb593
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4833624
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
6ff209bc
|
2023-08-30T00:02:30
|
|
Clean up InfoLog usage during link
The info log doesn't really belong to ProgramExecutable; it belongs to
ProgramState. However, it is placed there for convenience since many
functions access it.
This change cleans up usage of InfoLog so the one in ProgramExecutable
is consistently used, but also that is turned into a reference to
ProgramState's InfoLog.
This is necessary for a follow up change that restores the previous
executable on link failure (and would thus otherwise lose the info log
of the failing link).
Bug: angleproject:8297
Change-Id: I088408e3fce9ebb35b1ec4ad3dc599bdb90bf5c5
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4825624
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
|
ae67a24b
|
2023-08-25T14:51:50
|
|
Metal: Move program state to ProgramExecutableMtl
Bug: angleproject:8297
Change-Id: I1d13f7aee1ff5b0ce799b486d8a57c83c4481983
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4812047
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
|
|
|
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>
|