|
18bb6e54
|
2024-06-06T00:00:00
|
|
Metal: Support non-layered 2D array shader images
Fixed: angleproject:8125
Change-Id: Id148c09d948487bb677c4a3af746e6ea151d84a7
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5604225
Reviewed-by: Quyen Le <lehoangquyen@chromium.org>
Commit-Queue: Alexey Knyazev <lexa.knyazev@gmail.com>
|
|
4109a90e
|
2024-04-16T17:31:11
|
|
LinkedUniform: avoid frequent GLenum -> index conversion
Certain functions such as getElementComponents() are frequently called
in driver_overhead benchmark, causing repeated GLenum -> index
conversion of the uniform type which shows up in profiling
(driver_overhead_2 trace)
Change LinkedUniform.pod.type to LinkedUniform.pod.typeIndex storing the
UniformTypeInfo index with conversion helpers.
Bug: b/335295728
Change-Id: Iae5cd58f4e2703589d23b8e52991fc4b97c5fb08
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5458741
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Roman Lavrov <romanl@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
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>
|
|
|
6d9f0aee
|
2023-11-30T00:00:00
|
|
Metal: Ensure helper invocations when derivatives are used
Set sample coverage mask to ensure that
fragment shader helper invocations are
performed when derivatives are used.
Fixed the following tests on Apple silicon:
dEQP-GLES2.functional.texture.mipmap
.2d.projected.nearest_linear_repeat
.2d.projected.linear_linear_repeat
.cube.projected.linear_nearest
.cube.projected.linear_linear
dEQP-GLES3.functional.texture.mipmap
.2d.projected.nearest_nearest_mirror
.2d.projected.linear_nearest_clamp
.2d.projected.linear_nearest_repeat
.2d.projected.linear_nearest_mirror
.2d.projected.nearest_linear_repeat
.2d.projected.linear_linear_clamp
.2d.projected.linear_linear_repeat
.3d.projected.nearest_nearest_mirror
.3d.projected.linear_nearest_clamp
.3d.projected.linear_nearest_repeat
.3d.projected.nearest_linear_clamp
.3d.projected.nearest_linear_mirror
.3d.projected.linear_linear_clamp
.3d.projected.linear_linear_repeat
Fixed: angleproject:8443
Fixed: angleproject:7023
Change-Id: I13fc52532b94de098dcf3e9f5f02d48a6c8913c7
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5089131
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Alexey Knyazev <lexa.knyazev@gmail.com>
|
|
34e5620b
|
2023-11-01T17:52:34
|
|
Metal: Reuse UBO conversion buffer only if size matches
BufferMtl::getUniformConversionBuffer will recycle an existing buffer if
the request has the same buffer index and offset that is a multiple of
existing block size. This disregards the GL std size of the request
leading to incorrect allocation of blocks in the conversion buffer. The
fix is to create a new conversion buffer when stdSize !=
buffer.uniformBufferBlockSize.
Bug: angleproject:8393
Change-Id: Ife87309e66f65baa7f636b734a5586d0ae3b9768
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4995450
Reviewed-by: Yuly Novikov <ynovikov@chromium.org>
Commit-Queue: Yuly Novikov <ynovikov@chromium.org>
Reviewed-by: Quyen Le <lehoangquyen@chromium.org>
|
|
e076d6cf
|
2023-10-17T11:39:10
|
|
Move invalid uniform protection to the frontend.
The frontend potentialy indexes into mUniformLocations with invalid
uniform locations while validation is disabled too. Move the validation
from the Metal backend to the frontend.
Bug: chromium:1484878
Change-Id: I92bc43aa28cfa26d601bb28f318860375f618608
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4947652
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
d55893cd
|
2023-09-27T16:40:58
|
|
Issue 1484512: Out of bounds access to Metal uniform blocks
Fixed conversion offset for Uniform buffers: Dynamic buffers
were being allocated and copied from the 'updateBufferSubData'
offset, than from the previously allocated offset. This meant that when
creating a new dynamic buffer to hold the metal uniforms,
ANGLE didn't re-convert blocks from the initial source offset,
nor did we allocate enough space to read those blocks.
Important use cases to test include any UBO-heavy sites.
Bug: chromium:1484512
Change-Id: Ia9f505e3df871a401d40682d737019bd5d3f443f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4899369
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Kyle Piddington <kpiddington@apple.com>
|
|
|
2c0f9d20
|
2023-09-26T11:50:54
|
|
Metal: Protect against invalid locations in setUniformImpl
Chrome disables validation and a common bug is that the wrong program
is used during uniform setting in Skia. Make this bug less catastrophic
while the root cause is investigated.
Bug: chromium:1484878
Change-Id: I521e99cdf6cebc56775e484fa8d61ad18f506479
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4886384
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Geoff Lang <geofflang@chromium.org>
|
|
8fcd4a50
|
2023-09-19T14:08:14
|
|
Cleanup POD struct usage to make them more consistent
In recent months, I have made many CLs to wrap various data structures
into a trivially copy-able struct. Some of them uses different
terminology. This CL replaces all of these to use a consistent name
"pod" in the struct, and "mPod" in a class.
This CL also turns ActiveVariable methods into macros to remove the code
duplication.
This CL also moves ProgramInput/ProgramOutput struct implementations
from Program.cpp to ProgramExecutable.cpp
Bug: b/275102061
Change-Id: Ia2a4210a9ea633f3d323bebe674ee74f8b90b363
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4877335
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Roman Lavrov <romanl@google.com>
|
|
|
9ca025d2
|
2023-09-18T15:50:48
|
|
Flatten BufferVariable/ShaderVariableBuffer/InterfaceBlock struct
InterfaceBlock inherits from ShaderVariableBuffer, ShaderVariableBuffer
is not a trivially copyable struct, this made InterfaceBlock not
trivially copyable. InterfaceBlock is being used by some app traces for
uniform blocks. BufferVariable inherits from sh::ShaderVariable which is
very complicated and not trivially copyable. This CL flattens all of
these three structs to simple structs without inheritance, and wraps all
trivially copyable data into one POD struct, thus load/save are cheaper.
Bug: b/275102061
Change-Id: I96f89176ce3d3131cb1d3ea3280c3c36c257560f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4874610
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Roman Lavrov <romanl@google.com>
Reviewed-by: 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>
|
|
|
68bfa1ed
|
2023-08-22T22:02:15
|
|
Support for link to be entirely parallelized
The link job is split as such:
- Front-end link
- Back-end link
- Independent back-end link subtasks (typically native driver compile
jobs)
- Post-link finalization
Each step depends on the previous. These steps are executed as such:
1. Program::link calls into ProgramImpl::link
- ProgramImpl::link runs whatever needs the Context, such as releasing
resources
- ProgramImpl::link returns a LinkTask
2. Program::link implements a closure that calls the front-end link and
passes the results to the backend's LinkTask.
3. The LinkTask potentially returns a set of LinkSubTasks to be
scheduled by the worker pool
4. Once the link is resolved, the post-link finalization is run
In the above, steps 1 and 4 are done under the share group lock. Steps
2 and 3 can be done in threads or without holding the share group lock
if the backend supports it. Step 2 is not yet made independent of the
Context on some backends, and a frontend feature is used to make that
step either run on the main thread or as a worker thread.
Bug: angleproject:8297
Change-Id: I12f1e6bbaf365543dfcac969e166e0b5aa622104
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4808191
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@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>
|