|
a05a0e15
|
2024-09-25T22:33:36
|
|
Validate PLS shaders against context state
Add shader introspection for PLS uniforms and validate that they match
context state during draw calls.
Bug: angleproject:40096838
Change-Id: I76cdf8add03de8f8b0b3e772c15c0087c1d97e98
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5893962
Commit-Queue: Kenneth Russell <kbr@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Kenneth Russell <kbr@chromium.org>
|
|
08c1724f
|
2024-10-11T14:29:00
|
|
Vulkan: Support GL_ARM_shader_framebuffer_fetch_depth_stencil
Bug: angleproject:352364582
Change-Id: I63fd78314fa7ebccbf366c252e309a9c0f09c8c1
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5938150
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
a1584f49
|
2024-10-11T21:17:32
|
|
Vulkan: Qualify framebuffer fetch with "Color"
In preparation for depth/stencil framebuffer fetch, many framebuffer
fetch symbols are affixed with Color to indicate that they pertain to
color framebuffer fetch logic.
Bug: angleproject:352364582
Change-Id: I86000ada5e6ef47387dec0b6a3fca589d816cdc2
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5926593
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
c2a9300c
|
2024-09-10T19:33:33
|
|
WGSL: Rewrite input/output variables
GLSL builtin variables and in/out variables correspond to WGSL's main
function params and return value, so rewrite them accordingly.
This is done by generating structs to use as main function params and
return values, generating similar global structs, and copying the
former into the latter so the rest of the program can just use the
variables stored in the global structs.
Bug: angleproject:42267100
Change-Id: Ic3e1196f6fb95b963ce03845096a59ea7599d608
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5835347
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Matthew Denton <mpdenton@chromium.org>
|
|
0ccc018e
|
2024-06-20T10:20:08
|
|
Reland GL: Avoid calling glBindFragDatalocationIndexed on Qualcomm
Track if the output location and index came from a layout qualifier
or from a call to glBindFragDataLocation[Indexed] and only call
glBindFragDataLocationIndexed in the latter case. Re-binding a
location that was already specified in the shader is not allowed.
Qualcomm can fail when trying to bind locations using the API when
the output variable is an array or uses a non-zero index. Only
call glBindFragDataLocationIndexed when the user specifically uses
it to avoid failed links when all outputs should be implcitly
assigned.
Assign the ProgramOutput::pod::index field when doing output assignment
to mirror how the location is assigned.
Bug: angleproject:42267082
Change-Id: I72cdb73dd4c5edea4ad1229ca75c0c7926344d1f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5645123
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Alexey Knyazev <lexa.knyazev@gmail.com>
Commit-Queue: Geoff Lang <geofflang@chromium.org>
|
|
|
800ca8d3
|
2024-06-19T21:04:11
|
|
Revert "GL: Avoid calling glBindFragDatalocationIndexed on Qualcomm"
This reverts commit e768aed37e77dfcba0fe8ec7027348ade2069c85.
Reason for revert: Breaks WebGL tests.
Original change's description:
> GL: Avoid calling glBindFragDatalocationIndexed on Qualcomm
>
> Track if the output location and index came from a layout qualifier
> or from a call to glBindFragDataLocation[Indexed] and only call
> glBindFragDataLocationIndexed in the latter case. Re-binding a
> location that was already specified in the shader is not allowed.
>
> Qualcomm fails to bind any location that is not specified with a
> layout qualifier. Skip tests that do this behaviour and log warnings
> that the driver is unable to handle this case.
>
> Assign the ProgramOutput::pod::index field when doing output assignment
> to mirror how the location is assigned.
>
> Bug: angleproject:42267082
> Change-Id: Icdf83bb93f63a6375b5a6062690e53905c9ffe71
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5415796
> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
> Commit-Queue: Geoff Lang <geofflang@chromium.org>
> Reviewed-by: Alexey Knyazev <lexa.knyazev@gmail.com>
Bug: angleproject:42267082
Change-Id: Ifb866878aa6489b809ba6db4152ea5942274dc45
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5641895
Commit-Queue: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Auto-Submit: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
e768aed3
|
2024-05-28T15:45:50
|
|
GL: Avoid calling glBindFragDatalocationIndexed on Qualcomm
Track if the output location and index came from a layout qualifier
or from a call to glBindFragDataLocation[Indexed] and only call
glBindFragDataLocationIndexed in the latter case. Re-binding a
location that was already specified in the shader is not allowed.
Qualcomm fails to bind any location that is not specified with a
layout qualifier. Skip tests that do this behaviour and log warnings
that the driver is unable to handle this case.
Assign the ProgramOutput::pod::index field when doing output assignment
to mirror how the location is assigned.
Bug: angleproject:42267082
Change-Id: Icdf83bb93f63a6375b5a6062690e53905c9ffe71
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5415796
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Alexey Knyazev <lexa.knyazev@gmail.com>
|
|
818915a9
|
2024-05-27T10:53:35
|
|
PPO: Propagate dirty uniforms via mPPOProgramExecutables
This eliminates the need for ProgramUniformUpdated notification
Update mDefaultUniformBlocksDirty rather than just add a check to
hasDirtyUniforms, as mDefaultUniformBlocksDirty can then be used
elsewhere (for example, calcUniformUpdateRequiredSpace)
Also adds ProgramExecutable.mIsPPO flag for an easy check for PPO
without inspecting mPPOProgramExecutables
Bug: angleproject:8666
Bug: b/335295728
Change-Id: I7725d02460104997df5c89a54d0e5ef3c3079946
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5569184
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
3b470cf5
|
2024-05-13T12:43:25
|
|
Move PPO executables to ProgramExecutable
This will allow to recursively deal with PPO uniforms
Bug: angleproject:8666
Bug: b/335295728
Change-Id: Iadc2d009937fb5e8a39b070674ef5d67c9f0fb19
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5532715
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Roman Lavrov <romanl@google.com>
|
|
06472a7e
|
2024-04-04T21:07:02
|
|
Extend ProgramExecutableImpl API
waitForPostLinkTasks(...) will be called into by the frontend.
Backends can now choose to defer or avoid waiting for post-link tasks.
Also, move warmUp task code to ProgramExecutableVk in the Vulkan backend
Bug: angleproject:8297
Change-Id: Ia8a0682923e2f8c6287d62a606eed7f481cda08f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5427000
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
ac654931
|
2024-04-04T15:42:47
|
|
ProgramExecutable manages post-link tasks
Post-link tasks are now owned and managed by ProgramExecutable.
Also, update `LinkTask::link` API so backends have a choice to populate
either the linkSubTask or postLinkSubTask containers (but not both).
Bug: angleproject:8297
Change-Id: I5dbed6a070efe851fc1376699e9eccd3a21bd03f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5406487
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: mohan maiya <m.maiya@samsung.com>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
ecc35205
|
2024-01-25T23:58:25
|
|
Move uniform block dirty bits to State
When glUniformBlockBinding changes the mapping from a program uniform
block to a buffer binding, all contexts in the share group need to
reprocess the affected block index. Prior to this change, the dirty
bits that indicated which blocks have their mapping redefined were
placed in the program executable, and were reset by the first context
that processed them. As a result, the other contexts in the share group
where not aware of such modifications.
Similarly, when a buffer changed in one context, the mapped program
blocks were marked dirty, with similar cross-context issues.
In this change, the dirty bits are moved to State, so every context
would react to these changes.
Bug: angleproject:8493
Change-Id: I5712002224cbc4a576bf2ac46e8e75f26ebc5b2a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5238991
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@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>
|
|
|
c6fbf93d
|
2024-01-19T09:57:12
|
|
Vulkan: Fix input attachments leaking into uniform list
To communicate the existence of input attachments added to the shader,
the translator was adding `ShaderVariable`s for each to the list of
uniforms exported from the shader. This was incorrect, as this list is
visible to the application through `glGetActiveUniform`. Additionally,
this was unnecessarily causing these uniforms to go through program
link.
Reserving SPIR-V ids for these uniforms, all that is needed from the
translator is the mere existence of these input attachments. This
change removes the addition of uniforms, and instead exports a bitset.
Elsewhere, that bitset is consulted and reserved SPIR-V ids are used.
Bug: b/320563594
Bug: angleproject:5792
Change-Id: Id93846cbc3996248f391fd2d5a65af1e48d6d46e
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5215089
Reviewed-by: mohan maiya <m.maiya@samsung.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
a1143857
|
2023-12-18T15:24:42
|
|
Fix UBO dirty bits vs PPOs
This change fixes propagation of UBO dirty bits (such as through
glUniformBlockBinding and glBindBufferRange) to program pipeline
objects. Since PPOs concatenate the attached programs' UBOs in a list,
a map of program UBO indices to PPO UBO indices is introduced to
offset these dirty bits appropriately. Additionally, when the program's
executable's buffer bindings change (through glUniformBlockBinding), a
notification is send to the PPO to update its executable's buffer
binding accordingly (which is otherwise only updated during PPO link).
Bug: angleproject:8462
Change-Id: I4965ae23e6fc6cac0842e1643755e42e95d3d5cc
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5131418
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Cody Northrop <cnorthrop@google.com>
|
|
1ea49a22
|
2023-10-13T11:28:41
|
|
Move uniform dirty bits to ProgramExecutable
Rather than try to funnel them through Program and ProgramPipeline to
the executable in the backend, just move them to ProgramExecutable in
the front end.
This fixes Dota Underlords at the same time due to not needing to set
the Program dirty to propagate bits.
Test: Dota Underlords
Test: ProgramPipelineTest31.ProgramPipelineBindBufferRange
Bug: b/299532942
Change-Id: Ic73c45608e22f89ca400ebf684f8cd287ed2f43a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4922969
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Cody Northrop <cnorthrop@google.com>
|
|
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>
|
|
|
936694e3
|
2023-09-15T16:03:25
|
|
Cache isSeparable in the executable
For convenience, particularly for the next CL.
Bug: angleproject:8297
Change-Id: I55690aecf3936a51a2a2163d7c354a710b81d7f8
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4864069
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
65220256
|
2023-09-18T12:29:59
|
|
Add ProgramOutput struct for ProgramExecutable::mOutputVariables
Right now ProgramExecutable::mOutputVariables is a vector of
sh::ShaderVariable. ShaderVariable. itself is not a POD struct and can't
memcpy. And most of variables are not needed for mOutputVariables. This
CL adds a custom struct for mOutputVariables so that we only store what
we actually needed and data can be memcpy.
Bug: b/275102061
Change-Id: I045d0618b6dab5f8d58afe40e55147d12987cf61
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4862977
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
29561184
|
2023-09-06T22:08:33
|
|
Remove forward-to-executable helpers from program
This helps avoid accidental usage of the executable that is in the
program instead of the installed executable in the GL context.
The program's executable is still accessed in specific cases of:
- During link
- GL program queries
Bug: angleproject:8297
Change-Id: I40a956e740944f2ecfbf6e4a3060aac08c21f7f3
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4864448
Commit-Queue: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
7b0bb0f6
|
2023-09-01T13:52:28
|
|
Properly "install" program executables
According to GL:
- The program has an executable
- The executable is overwritten during link.
- After a failed link, queries of the executable may return
half-linked information
- On glUseProgram, the executable is installed in the context
- On glUseProgramStages, the executable is installed in the program
pipeline
- After a successful link, the executable is updated wherever the
previous executable of the program was installed.
This change implements exactly the above:
- The program's and the program pipeline's executables are now
shared_ptr. References to an executable in the context and PPO are
also through a shared_ptr. Installing an executable thus translates
to sharing the executable.
- The context and PPOs are made to not reference the program directly,
but work solely through the executable. As a result, the program is
free to create a new executable for link.
With this change, the link job will be free to modify the executable as
necessary because that will not be accessed until the link is done.
Note that previous changes made the backend executable accessed through
the frontend one, and moved all link results to the frontend and backend
executables as appropriate.
Bug: angleproject:6358
Bug: angleproject:8297
Change-Id: Ie636b23ff7420ad284d18b525ec4f5fb559dd9d1
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4823089
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
ebf1e716
|
2023-08-31T17:19:44
|
|
Cache transform feedback varying names in the executable
Currently, ANGLE actually does a full link of the programs inside PPOs.
This was never the intention of the spec (hence why an explicit link
doesn't exist). During this link operation, the transform feedback
varying names are used, and they are retrieved from the program itself.
This is not correct, because the transform feedback varyings may have
changed, the program may have failed to relink, and the program pipeline
is expected to continue functioning using the "installed" executable.
Bug: angleproject:5486
Bug: angleproject:8297
Change-Id: I583dbd2abcc51e8536b4c460b92211bdddebda16
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4834055
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
962fdf7b
|
2023-08-31T17:44:51
|
|
Add templated BinaryOutputStream::writeVector and writeStruct
To avoid repeated code pattern, this CL adds templated
BinaryInputStream::readVector and readStruct and
BinaryOutputStream::writeVector and writeStruct, that does the static
assertion to ensure they are trivially copyable.
readIntVector/writeIntVector is removed.
This CL also padding warning for ProgramExecutable::PODStruct to avoid
potential Msan complain.
Bug: b/296433003
Change-Id: I8e718b41cde898960b9e86a2d7d1bc5a837fe561
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4834700
Reviewed-by: Roman Lavrov <romanl@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
9624db05
|
2023-08-21T00:00:00
|
|
Validate missing fragment outputs for dual-source blending
* A secondary fragment output must be declared when
dual-source blending is enabled in WebGL contexts.
* Omitting locations for multiple fragment
outputs is not allowed in WebGL contexts.
Bug: angleproject:1085
Change-Id: I57febdc02c9ccc571971a81b6671869f19b0aa96
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4834672
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Alexey Knyazev <lexa.knyazev@gmail.com>
|
|
|
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>
|
|
|
d9672ada
|
2023-08-25T11:37:09
|
|
Move left over link state to ProgramExecutable
Previously, only things that needed sharing with ProgramPipeline was
moved to ProgramExecutable, and in particular only state that the Vulkan
backend needed to access. In truth, everything that's a result of
link needs moving.
Bug: angleproject:8297
Change-Id: I1ca01c5dedbfc62ddcfb4ef945336ceb8ad0f1c4
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4812044
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
|
3822ea3a
|
2023-08-24T22:42:43
|
|
D3D: Move program state to ProgramExecutableD3D
Bug: angleproject:8297
Change-Id: Ieead87d2f0ebe5937f262f598443a00504ea1492
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4812139
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@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>
|
|
|
558df6f1
|
2023-08-21T00:00:00
|
|
Fix fragment output variables validation
* Reject fragment shaders that assign
out-of-range fragment locations
* Reject fragment shaders that assign
output variables of different types
to the same location
* Apply similar validation for fragment
outputs bound via API calls
* Ensure that masks for active output
variables and draw buffer types are
set after processing all fragment
output bindings
Bug: angleproject:1085
Change-Id: If29cbb58be1981279fc97c67739fe4136b0cdc98
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4813656
Commit-Queue: Alexey Knyazev <lexa.knyazev@gmail.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
e066b689
|
2023-08-25T09:25:19
|
|
Ensure struct SamplerBinding is tightly packed without padding
crrev.com/c/4798195 might have caused MSan bot failure in chromium due
to use of memcpy on the struct. TextureType and SamplerFormat are both
uint8_t, which means extra paddings added for the struct. This CL adds
warning for struct padding and fixes the warning as well.
Bug: b/275102061
Bug: chromium:1475844
Change-Id: Ia3f8a7e7697c6e354efb8a8dc5dfc7861118a818
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4812245
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
c8ec8739
|
2023-08-22T11:30:08
|
|
Frontend: Remove link job dependence to context
The part of link that needs the context is moved up. Usage of
gl::Context is eliminated from the rest of the link (whatever is done in
the front-end).
Bug: angleproject:8297
Change-Id: Ifa71d2b2c0c0bc7c0c0b7ee89e1cbb203c3018cc
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4803109
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
b8d5a423
|
2023-08-21T14:43:42
|
|
Add static_assert(std::is_trivially_copyable<LinkedUniform>(),"")
Since we are using memcpy for LinkedUniform, it is desirable to utilize
compile time assertion to ensure that in future if anyone modifies POD
struct (and the class of data members of POD struct) and made it that no
longer memcopy-able, we would immediately caught at compile time.
std::is_trivially_copyable<>is exactly for this reason. In order to make
this work, the POD struct and any data it uses can not have user defined
copy constructor. The problem is that right now ANGLE is using
clang_use_chrome_plugins=true, and chrome-style generates warnings if
the complex struct (has more than 10 data members) does not define a
copy constructor, and that warning causes build failure with -Werror. So
clang_use_chrome_plugins=true and std::is_trivially_copyable have this
conflicting requirements that I can not apply both. This has been raised
to compiler team, but before we get a solution from them, if we have to
make a choice, I think the better choice is to disable
clang_use_chrome_plugins and apply std::is_trivially_copyable, since the
later is more critical to ensure safety, while chrome-style is mostly
trying to minimize the code size, but won't affect
correctness/robustness. This CL sets clang_use_chrome_plugins to false,
and removes the copy constructor and copy assignment operator from
BitSetT and LinkedUniform and added static assertion
is_trivially_copyable for LinkedUniform. Same thing applied to
ProgramInput as well.
In future once we have a better solution from compile team, we can
re-enable clang_use_chrome_plugins and disable only for structs that
requires is_trivially_copyable assertion.
Bug: b/275102061
Change-Id: If33415ea61deda568d855a7dd6a4fd6042058be5
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4799342
Reviewed-by: Roman Lavrov <romanl@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
03f9dff6
|
2023-08-21T16:57:12
|
|
Separate out std::vector<GLuint> boundTextureUnits from SamplerBinding
SamplerBinding struct is trivial copy-able except the
std::vector<GLuint> boundTextureUnits. This CL moves boundTextureUnits
out of the SamplerBinding struct and becomes a vector in
ProgramExecutable. This means all of sampler binding's texture units
will be stored in one vector and SamplerBinding will remember where its
own texture units is stored in that vector by keeping
textureUnitsStartIndex and textureUnitsCount. In other word,
SamplerBinding::boundTextureUnits (before this CL) is equivalent to
mSamplerBoundTextureUnits[SamplerBinding.textureUnitsStartIndex], ...,
mSamplerBoundTextureUnits[SamplerBinding.textureUnitsStartIndex +
SamplerBinding.textureUnitsCount - 1] after this CL. With this,
ProgramExecutable::mSamplerBindings are load/stored with one
readBytes/writeBytes call since it is trivially copyable.
Bug: b/275102061
Change-Id: I0974cf940875ecbcf655b4469b3bbc910717f1ec
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4798195
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Roman Lavrov <romanl@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
3479f4a1
|
2023-08-16T14:43:35
|
|
Move more ProgramExecutable basic type vars to mBasicDataTypeStruct
They can be just load/saved along with mBasicDataTypeStruct, no need to
do them separately:
mLinkedShaderVersions was previously only saved if
it is separate program, now it is always saved along with
mBasicDataTypeStruct, since the extra cost of a few more bytes of memcpy
is ignorable, but will make it more consistent.
mActiveUniformBlockBindings was previously updated instead of load, now
it is load (and verified with ASSERT)
mCanDrawWith was previously updated, now chnaged to load.
Bug: b/275102061
Change-Id: I4e15b955606f34966d56b1c5e3d9d2f22ddeb14d
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4786308
Reviewed-by: Roman Lavrov <romanl@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
c34f83d9
|
2023-08-16T11:53:27
|
|
Group all ProgramExecutable basic data type members into a struct
So that we can load/save with a simple memcpy.
Bug: b/275102061
Change-Id: I178404fd72b615174a7a0412ea5482ae2bea2f80
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4785567
Reviewed-by: Roman Lavrov <romanl@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
1e1c9d9d
|
2023-08-11T15:16:26
|
|
Pack and reduce Program::mProgramInput size
Right now mProgramInput is std::vector<sh::ShaderVariable>. It really
only need a subset of ShaderVariable struct. This CL adds a ProgramInput
struct so that we can add data members that actually required. This CL
also makes bools into bitfield and some variables to uint16_t to further
compact the size. This CL also groups the data memebers other than
string to basicDataTypeStruct which only contains basic data types and
the entire struct is memcpied during program binary load and save. This
not just reduces number of memcpy calls, but also improves reliability
so that when someone adds a new member into the struct, it will
automatically load/save correctly.
Bug: b/275102061
Change-Id: Ic055c986453ed46e56057a0122c9926245fef4d1
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4776267
Reviewed-by: Roman Lavrov <romanl@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
eff12c1e
|
2023-08-03T12:10:05
|
|
Move name and mappedName out of LinkedUniform struct
These are std::string objects. This CL moves these two data out of
LinkedUniform and into ProgramExecutable class, side by side with
mUniforms. With these two data moved out, LinkedUniform is now a simple
struct with basic data types, and I can memcpy entire vector of
uniforms.
Bug: b/275102061
Change-Id: I9ae13e7daca85f8e5f3662a4718f190bebb5f5d2
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4750442
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
5446e87e
|
2023-07-24T16:46:56
|
|
Improve ProgramExecutable::load performance
We are calling push_back for each vector inside ProgramExecutable. This
causes c++ run time to constantly re-allocate storage and copy the
vector over to new storage, and impacts performance negatively. Since
the vector size is know when we load program from cache, this CL calls
resize to the correct size first and then update each element as we walk
over, thus reduces the vector storage reallocation. This CL reduces
blade_and_soul_revolution frame time from 4.48 ms to 4.35 ms on pixel 7
pro.
This CL also changes ProgramBinaryTest tests to use slightly more
complicated program instead of the simplest program.
Bug: b/275102061
Change-Id: I8d92117b07a9ad2d0851850e473ea1b86f9868f8
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4713685
Reviewed-by: Roman Lavrov <romanl@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
681ca074
|
2023-06-16T15:03:13
|
|
Vulkan: Deduplicate SpvAssignLocations call in program pipeline
Some logic already in SpvGetShaderSpirvCode was duplicated for program
pipelines. In particular, this necessitated exposing UniformBindingInfo
which is an internal detail of SpvAssignLocations.
In a follow up, UniformBindingInfo will be removed altogether.
Bug: angleproject:7220
Change-Id: I9fa60c716de6dfb0d3a72c4f4dd3822043bab308
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4622010
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Roman Lavrov <romanl@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
cc34aa73
|
2022-12-19T14:03:27
|
|
Move BinaryStream to common and expose ShaderState to compiler
This is a refactor change in preparation for adding support for
glShaderBinary.
Move BinaryStream to common so that it is accessible by both libANGLE
and the Compiler.
Extract members that hold the result of compilation from ShaderState
and move into new CompiledShaderState struct.
Move helper functions & classes relevant to ShaderVar serialization to
the CompiledShaderState header.
Tests: EGLBlobCacheTest*
Bug: angleproject:7833
Change-Id: I7ec575247eccb3afbc6ab6bfa24d36e69d4576f5
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4080998
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: mohan maiya <m.maiya@samsung.com>
|
|
|
28e7adca
|
2022-12-09T00:00:00
|
|
GL: Implement clip distance state emulation
Pass the current set of enabled clip distances
to vertex shaders via an internal uniform and
dynamically set disabled elements to zero.
Bug: angleproject:7880
Change-Id: I709d31dc7ca0606decf49adf674460a941837683
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4094314
Commit-Queue: Alexey Knyazev <lexa.knyazev@gmail.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
f0e3d8f9
|
2022-10-18T13:51:31
|
|
Vulkan: Shader component type in GraphicsPipelineDesc
Currently, there's some program state used in creating pipelines
alongside what's in GraphicsPipelineDesc. This works because the
pipeline cache lives in the program executable.
With VK_EXT_graphics_pipeline_library however, we could create vertex
input and fragment output partial pipelines that are independent from
and are shared between multiple programs. To support this, any program
state that's necessary for pipeline creation should be part of the
GraphicsPipelineDesc structure.
This change places the state affecting vertex input in
GraphicsPipelineDesc. A follow up change will do the same for state
affecting fragment output.
Bug: angleproject:7369
Change-Id: Iccf691a1597d786efa1625f7b1c22f906201f2e5
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3964751
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
2ebd5100
|
2022-08-11T10:43:32
|
|
Add gl::Context as a parameter to Shader::resolveCompile
This prepares us to access the Context's shader cache in resolveCompile
in the next commit.
Bug: angleproject:7036
Change-Id: I7995c54b290a5a48f0c8985cb56ea0048598ab2f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3827642
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Cody Northrop <cnorthrop@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
493b5aff
|
2022-08-09T14:57:24
|
|
Vulkan: Workaround ARM bug with stencil write mask
Bug: angleproject:7556
Change-Id: I0aa17c178071cc15d8ee15f700b0c4932819c72a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3821367
Reviewed-by: Ian Elliott <ianelliott@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Cody Northrop <cnorthrop@google.com>
|
|
|
9ea3967d
|
2022-05-22T13:06:18
|
|
Bug fix in GL_EXT_YUV_target
Shaders with multiple samplers need to account for conflicting
YUV sampler states and accordingly reevaluate them when sampler
uniforms are updated.
Tests: ImageTestES3.ProgramWithBothExternalY2YAndExternalOESSampler*
Bug: angleproject:4852
Change-Id: Ie633e62f0bbb89f217183623d4fc6ab5b3acfd81
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3661211
Reviewed-by: Trevor Black <vantablack@google.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: mohan maiya <m.maiya@samsung.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
fea19567
|
2022-05-17T17:44:06
|
|
Vulkan: Remove removeEarlyFragmentTestsOpt flag
* Removed removeEarlyFragmentTestsOptimization and the related
SPIRV transformation and variables.
* Removed mUsesEarlyFragmentTestsOptimization.
* Removed SH_EARLY_FRAGMENT_TESTS_OPTIMIZATION.
* Merged updateUsesEarlyFragmentTestsOptimization() into
updateFragmentInoutRange().
Bug: angleproject:7347
Change-Id: I7299bd4e8ab5363e5cf06eb48419d4f469106e12
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3648217
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
d4442f53
|
2022-04-28T15:23:19
|
|
Reset the program executable if async linking fails.
In this case, there is no exectuable to reset back to and the current
executable is filled with state that is "valid" because the program
failed to link for implementation specific reasons.
Bug: chromium:1319332
Change-Id: I1aeb4f22394a0b5d1127eb313e4d550e4fc8af66
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3615016
Reviewed-by: Lingfeng Yang <lfy@google.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Geoff Lang <geofflang@chromium.org>
|
|
|
5113ae8e
|
2022-04-29T22:42:59
|
|
Vulkan: Explicitly enable per-sample shading if `sample` used
The Vulkan spec is not explicit about the `Sample` decoration implicitly
enabling per-sample shading. While this is being corrected in the spec,
the ARM Vulkan driver does not have this implicit behavior.
A workaround is added such that the usage of the `sample` qualifier is
reported, and used to explicitly enable per-sample shading through the
API.
Bug: angleproject:6876
Change-Id: Idb8345aacdcfa45cb37fefcd30aa5405168d21e3
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3615738
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
2d6e42fc
|
2022-04-22T14:04:21
|
|
Update Program Pipeline TODOs.
Bug: angleproject:3570
Bug: angleproject:7232
Change-Id: I0923e6b232b80ee26cb4c5788232c25a545ff87a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3600916
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Auto-Submit: Jamie Madill <jmadill@chromium.org>
|
|
|
e77be663
|
2022-04-14T05:04:13
|
|
Use ProgramExecutable directly in GlslangWrapper.
Using the ProgramExecutable instead of the state means
we can deal with merged samplers and images immediately.
This will make it easier to use linear maps when indexing
program resources for descriptor sets.
Bug: angleproject:3570
Bug: angleproject:4524
Change-Id: Icd8ee9fe61730b81fafa2bdc59a2788a0d92ad12
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3580882
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
|
|
|
c5271e8e
|
2022-04-04T23:28:35
|
|
Vulkan: Emulate GL_KHR_blend_equation_advanced
Based on a change by Brandon Schade <b.schade@samsung.com>
In the translator, when advanced blend is enabled, an input attachment
is added. Based on the listed advanced blend equations, emulation code
is added that performs those equations' functions. The blend equation
itself is passed through a driver uniform.
Note that the advanced blend extension only allows a single output to
use advanced blend, and that should be at location 0.
In the Vulkan backend, when advanced blend is used, the driver uniform
to select the equation is updated and normal blending is disabled.
Bug: angleproject:3586
Change-Id: Icc42e8be238d34fca149087eb9cfe616a7643a6b
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3575738
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
6768aff7
|
2022-04-07T23:25:08
|
|
Fix Geometry Shader Conformance Test Failure on Pixel6
Add code in shader linker stage
to check the number of AtomicCounterBuffers
against these values:
GL_MAX_VERTEX_ATOMIC_COUNTER_BUFFERS
GL_MAX_FRAGMENT_ATOMIC_COUNTER_BUFFERS
GL_MAX_COMPUTE_ATOMIC_COUNTER_BUFFERS
GL_MAX_GEOMETRY_ATOMIC_COUNTER_BUFFERS_EXT
GL_MAX_COMBINED_ATOMIC_COUNTER_BUFFERS
GL_MAX_TESS_CONTROL_ATOMIC_COUNTER_BUFFERS
GL_MAX_TESS_EVALUATION_ATOMIC_COUNTER_BUFFERS
Bug: angleproject:6918
Change-Id: If1c1d0dc2452f5aafc72d81f4f5523608810bba9
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3576629
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Ian Elliott <ianelliott@google.com>
Commit-Queue: Yuxin Hu <yuxinhu@google.com>
|
|
|
4e644b33
|
2022-01-22T16:17:46
|
|
Vulkan: Remove ProgramExecutableVk back-pointers.
This removes the mProgram and mProgramPipeline back-pointers from
ProgramExecutableVk. In order to fix this, we needed to refactor
the VkPipeline init functions to call through ProgramExecutableVk
only instead of passing through ProgramVk. We also needed to move
the early fragment shader optimization boolean out from Program.
This CL also fixes a few places where the early fragment test
optimization boolean wasn't properly updated.
Bug: angleproject:3570
Change-Id: Ie4c48087f6eb022e6f0a4dacc2710085165d49e1
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3408267
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
|
|
|
374e0c43
|
2022-01-20T14:04:27
|
|
ProgramPipeline: Remove mHas members.
These are no longer needed now that the excutable mirrors uniforms/
samplers/sahder buffers/etc.. Refactoring change only.
Bug: angleproject:3570
Change-Id: I768381ac64a750f04180ab824302e3550030911c
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3403047
Reviewed-by: Tim Van Patten <timvp@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
|
|
|
0dc0dc2a
|
2021-12-30T11:35:40
|
|
Re-land: "Vulkan: Remove "fillProgramStateMap"."
This copies additional shader info like uniforms from the Program
to the Program Piplines. There is now a duplication between PPOs
and Programs. There is no additional storage required for non-PPO
Programs.
Re-land fixes fragment in/out uniform updating with PPOs.
Bug: angleproject:3570
Change-Id: I64b2db6fbc3a610f3b5e617301f94eb30d915939
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3412999
Reviewed-by: Tim Van Patten <timvp@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
|
|
6a14e328
|
2022-01-25T00:49:45
|
|
Revert "Vulkan: Remove "fillProgramStateMap"."
This reverts commit 38deffe40db83836588e0cd50864945a9ddba36b.
Reason for revert: angle_end2end_tests failures on Pixel 6.
Original change's description:
> Vulkan: Remove "fillProgramStateMap".
>
> This copies additional shader info like uniforms from the Program
> to the Program Piplines. There is now a duplication between PPOs
> and Programs. There is no additional storage required for non-PPO
> Programs.
>
> Bug: angleproject:3570
> Change-Id: I5ed6c946df945aaf2f65752f797b16e7649d5584
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3362297
> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
> Reviewed-by: Tim Van Patten <timvp@google.com>
> Commit-Queue: Jamie Madill <jmadill@chromium.org>
Bug: angleproject:3570
Change-Id: I3a4822c8a65d024070a9fe5df103b88a3c8333d3
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3414024
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Yuly Novikov <ynovikov@chromium.org>
|
|
|
38deffe4
|
2021-12-30T11:35:40
|
|
Vulkan: Remove "fillProgramStateMap".
This copies additional shader info like uniforms from the Program
to the Program Piplines. There is now a duplication between PPOs
and Programs. There is no additional storage required for non-PPO
Programs.
Bug: angleproject:3570
Change-Id: I5ed6c946df945aaf2f65752f797b16e7649d5584
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3362297
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
|
|
|
400175d8
|
2022-01-07T14:54:03
|
|
Copy shader buffers into pipeline executables.
Bug: angleproject:3570
Change-Id: I82e4fc15aac9f60f40aae69785b24e5dc233fd78
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3371528
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
|
|
|
bd64b3ea
|
2021-12-30T13:47:09
|
|
Move pipeline uniforms into the executable.
Refactoring change only.
Bug: angleproject:3570
Change-Id: I8cfe41d86aa63d395d7da02dcc3c85a18fde553e
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3359002
Reviewed-by: Tim Van Patten <timvp@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
|
|
|
cabc3b98
|
2021-12-30T14:33:31
|
|
Move atomic counter uniform range counter to executable.
This makes the code more consistent with the other ranges. It will
make way for future refactorings to moving more uniform code to
the executable.
Bug: angleproject:3570
Change-Id: Ie365c0e184039f813f19d3f38b401ad8a0b72120
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3359001
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
|
|
|
3a9f18f1
|
2021-10-18T10:44:38
|
|
Refactor program pipeline handling.
In preparation for moving more code from gl::Program to
gl::ProgramExecutable so it can be shared with ProgramPipeline.
Bug: angleproject:6566
Change-Id: Icb7ecccb37ae8e0d7d5fef8968f0dd7ef6fe6150
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3226305
Reviewed-by: Tim Van Patten <timvp@google.com>
Reviewed-by: Cody Northrop <cnorthrop@google.com>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
|
|
|
66e8faf7
|
2021-10-20T14:06:08
|
|
Remove ProgramExecutable's "isCompute" property.
This consolidates the lists of uniforms, ssbos, etc into one.
Requires a few checks to change from graphics shader stages into
all shaders.
Bug: angleproject:6596
Change-Id: Ic8f6bfc4fa295c3bea9f5f1ded11e8fbca1c3164
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3233361
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
aac5d678
|
2021-10-20T11:48:57
|
|
Make "isCompute" private to ProgramExecutable.
This eliminates uses of "isCompute" is the Vulkan back-end. Instead
of checking the state flag, we can use the context of the current
command to determine if we're running a compute or a graphics
command. This will eventually lead to us being able to compile the
program pipeline objects before we run a draw or dispatch command.
Changes the driver uniforms descriptor desc to bind to both graphics
and compute shader stages to simplify the code. This could have
theoretical but low-risk performance implications.
Bug: angleproject:6595
Change-Id: Ie30d419b6ece5b33f5066a034d3805fe96519b36
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3233903
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
|
|
cc52e7cd
|
2021-04-19T21:37:20
|
|
Prevent separable programs from relying on attached shaders
Previously, several linking functions were reliant on the
HasAttachedShaders interface. The information stored there has been
moved to ProgramExecutable.
Linking information such as uniforms and uniform blocks from
attached shaders is now also stored in temporary pending variables
inside ProgramExecutable.
Bug: angleproject:5506
Test: ProgramPipelineTest31.VaryingLocationMismatch*
Test: GeometryShaderTest.RecompileSeparableVSWithVaryings*
Test: ProgramBinaryES31Test.SeparableProgramLinkedUniforms*
Change-Id: I93591431959c1c4c547ada92ec358369a3417723
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2909760
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
Commit-Queue: Brandon Schade <b.schade@samsung.com>
|
|
|
c664601d
|
2021-04-26T17:08:06
|
|
Allow drawing if a fragment shader isn't present
According to the OpenGL ES 3.1 spec:
7.3 PROGRAM OBJECTS
If there is no active program for the vertex or fragment shader
stages, the results of vertex and fragment shader execution will
respectively be undefined.
If there isn't an active program for only one of these shader
stages, the results of the other shader stage are still defined.
To handle this, we no longer no-op the draw call if one of these
is missing. We only no-op the draw if there's no vs.
This allows for transform feedback to be captured when there's only
a geometry and vertex shader.
Tests: KHR-GLES32.core.geometry_shader.api.program_pipeline_vs_gs_capture
Tests: KHR-GLES32.core.separable_programs_tf.geometry_active
Tests: ProgramPipelineTest31.PipelineWithoutVertexShader*
Tests: ProgramPipelineTest31.PipelineWithoutShaders*
Bug: angleproject:5579
Change-Id: If9849cc398c307232435b167ab12431fa4258201
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2906723
Commit-Queue: Brandon Schade <b.schade@samsung.com>
Reviewed-by: Tim Van Patten <timvp@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
323c5f24
|
2021-03-29T17:47:53
|
|
Validate PPO sampler uniforms
"Command & Conquer: Rivals" uses PPOs and was hitting the following
assert:
angle::Result ContextVk::updateActiveTextures(const gl::Context *context)
{
...
for (size_t textureUnit : activeTextures)
{
gl::Texture *texture = textures[textureUnit];
gl::TextureType textureType = textureTypes[textureUnit];
ASSERT(textureType != gl::TextureType::InvalidEnum);
This is the same assert that is generated by the test
ProgramPipelineTest31.DifferentTextureTypes which is currently being
skipped since it's known to fail.
This CL refactors sampler validation into the ProgramExecutable to allow
PPOs to take advantage of the shared code and behave correctly, since
the necessary data is already copied into the PPO's ProgramExecutable
via ProgramExecutable::updateActiveSamplers(). This also takes advantage
of the subject/observer pattern that's already established between
programs and PPOs to ensure only the PPOs that the program is a part of
are updated when a program's sampler uniforms are updated.
Bug: angleproject:3570
Bug: b/182409935
Test: ProgramPipelineTest31.DifferentTextureTypes
Change-Id: I3d34efd66dc85e7ff23a8422cb14d5f90a5f7085
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2792862
Commit-Queue: Tim Van Patten <timvp@google.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Cody Northrop <cnorthrop@google.com>
|
|
|
e3b9dbef
|
2021-03-17T18:01:02
|
|
Update PPO's executable when attached program is re-linked
When a program that's being used by a PPO is successfully re-linked, the
PPO's ProgramExecutable needs to be updated. This takes advantage of the
subject/observer pattern that's already established between programs and
PPOs to ensure only the PPOs that the program is a part of are updated.
Bug: b/182409935
Test: ProgramPipelineTest31.ModifyAndRelinkShader
Change-Id: Idcc11e7e819b4a9bef02bdd71afc8ea58111acc6
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2770684
Commit-Queue: Tim Van Patten <timvp@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Cody Northrop <cnorthrop@google.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
|
0af8cfa7
|
2021-03-17T17:43:03
|
|
Reland "Save/Load missing members"
This is a reland of b2e76cf58fc012b068aab4716a432bb8951e93e3
Always call saveLinkedStateInfo() so we fill in the necessary values
with valid data for monolithic programs also.
Original change's description:
> Save/Load missing members
>
> There are several class/struct members that are missing when a program
> is serialized/deserialized. This leads to errors when attempting to link
> programs that have been deserialized. For example, when drawing with a
> PPO that contains programs which were created with glProgramBinary().
>
> This CL adds saving/loading the missing members.
>
> Bug: b/182409935
> Change-Id: I637c6cd8c174acd6da8d51433893323a32e5d7c0
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2770683
> Commit-Queue: Tim Van Patten <timvp@google.com>
> Reviewed-by: Jamie Madill <jmadill@chromium.org>
> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
> Reviewed-by: Cody Northrop <cnorthrop@google.com>
Bug: b/182409935
Bug: angleproject:5793
Change-Id: I07ca8f5dfed8c0a9eac3a0defb1602d2ba021c5f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2782189
Commit-Queue: Tim Van Patten <timvp@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Cody Northrop <cnorthrop@google.com>
|
|
|
550f2a3e
|
2021-02-24T09:49:42
|
|
Vulkan: Shader support for EXT_shader_framebuffer_fetch_non_coherent
Translator can accept gl_LastFragData and 'inout' variable to gain
access to framebuffer attachment data. The Vulkan translator replaces
it with the SubpassInput type variable. Note that this works only for
the noncoherent version of the extension.
Bug: angleproject:5454
Test: *EXTShaderFramebufferFetchNoncoherent*.*
Change-Id: I392f84ee3ad3eb9fbd09d0b7ff83731a9a3f33f6
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2598060
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Mohan Maiya <m.maiya@samsung.com>
|
|
|
907a3cee
|
2021-02-17T08:07:45
|
|
Vulkan: Add support for EXT_shader_framebuffer_fetch_non_coherent
EXT_shader_framebuffer_fetch_non_coherent is implemented using subpass
input attachments. The extension will be enabled in a follow up change
that adds required changes to the Vulkan translator.
Bug: angleproject:5454
Test: FramebufferFetchNonCoherentES31.*Vulkan
Change-Id: Ic73c66a476c4a21db5269431166a198841f1dc0c
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2598059
Commit-Queue: Mohan Maiya <m.maiya@samsung.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
|
6cc845bb
|
2020-12-07T18:14:50
|
|
Vulkan: Add support for EXT_blend_func_extended
This implementation utilizes vulkan's dualSrcBlend
feature. Expose this extension if the underlying vulkan
backend allows the use of this feature.
Test: angle_end2end_tests --gtest_filter=EXTBlendFuncExtendedDrawTest*
Bug: angleproject:5074
Change-Id: I7d2f611df89d65e5cac35158cb5f41a0ebd58aae
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2593151
Commit-Queue: Brandon Schade <b.schade@samsung.com>
Commit-Queue: Mohan Maiya <m.maiya@samsung.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
ddba70da
|
2021-01-27T13:52:12
|
|
Fix xfb mode validation with geometry/tessellation
In the presence of geometry and/or tessellation shaders, transform
feedback mode must match what these shaders produce, instead of what's
passed to glDrawArrays.
Bug: angleproject:5557
Bug: angleproject:5579
Change-Id: I6a21621e66b31553ed6a3a50c3aebf60e1ac7be5
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2653908
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
|
|
|
bb3adfa4
|
2020-12-01T15:43:13
|
|
Rename ShaderVariable::structName to structOrBlockName
Bug: angleproject:3580
Change-Id: Ic53a5267972f153dad2e20948e493e9767a45d16
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2568247
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
|
b912eec5
|
2020-11-27T11:08:41
|
|
Vulkan: Support GL_EXT_tessellation_shader.
Shader translator changes done in http://crrev.com/c/2633936
Adds a new DIRTY_BIT_PATCH_VERTICES state to Context.
Supportes state query and transform feedback.
4 test suppressions remain as follow-up fixes.
Adds a new varying packing mode for a simple Vulkan rule set.
Based on work by Mohan Maiya (m.maiya@samsung.com).
Test: dEQP-GLES31.functional.tessellation.*
Bug: angleproject:3572
Change-Id: I4cad2cca30adb754fd12c83027673906541f566a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2568234
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Mohan Maiya <m.maiya@samsung.com>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
|
|
|
d654ac9b
|
2020-12-30T12:28:41
|
|
Program: Support multiple varying packings.
Instead of using a single varying packing for all program stages,
we switch to using a varying register packing for each pair of
input/output shaders. This allows several valid use cases that use
many varying to succeed. For instance Geometry Shaders have both
an input and output varying packing. With tessellation shaders the
upper bound of valid varying packings in one Program goes up even
more.
We keep multiple varying packings at once inside a new
"ProgramVaryingPacking" class. Internally the class keeps a unique
varying mapping for each input/output interface in the program.
Separable programs with "open" interfaces are handled specially.
Fixes a bug where varying counting was artificially limited for
programs with more than two shaders.
This CL also disables GS support when we're emulating line raster
so we don't have to figure out the details on how to place the
special position varying.
Bug: angleproject:5496
Change-Id: I1f9a327c4750caef570c608d86953e9d0cc5eea3
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2606532
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
|
|
|
e4497d60
|
2020-12-31T20:12:13
|
|
Program: Move more common code to ProgramLinkedResources.
Refactoring change only.
Bug: angleproject:5496
Change-Id: Ic1c8301a070e91ad28791c23831b8236058ab9ab
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2606535
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
fa449cf3
|
2021-01-06T10:02:12
|
|
Fix separable Geometry Shaders.
Was a needed fix for a new varying test.
Bug: angleproject:3571
Bug: angleproject:5496
Change-Id: I49ae69967510b7a6330ea217a0e0e19e3bebe865
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2613198
Reviewed-by: Tim Van Patten <timvp@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
|
|
|
92e7bc89
|
2020-12-23T15:18:42
|
|
Remove ProgramLinkedResources from ProgramExecutable.
Instead of storing the entire LinkedResources struct, we can keep it
only for the duration of the linking calls. Refactoring change only.
It sets the stage for more refactoring. This change also switches the
link call to use LinkingState's ProgramLinkedResources directly to
avoid the need to copy the varying packing or use a pointer.
Bug: angleproject:4514
Bug: angleproject:5496
Change-Id: Iefea3c16a33213dc338cc54efaa7c3064ea6ae08
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2601403
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
|
|
|
eeb14308
|
2020-12-23T01:45:35
|
|
Vulkan: Support xfb capture of I/O block fields
In the emulation path, it's ensured that the generated code references
the I/O block field correctly (using the instance name if provided, and
without it otherwise).
In the extension path, the info map is augmented with an array of xfb
decorations for its fields. Then when `OpDecorate %IOBlockId Block` is
encountered, the transform feedback decorations on the fields are
inserted:
OpMemberDecorate %IOBlockId MemberN XfbBuffer buffer
OpMemberDecorate %IOBlockId MemberN XfbStride stride
OpMemberDecorate %IOBlockId MemberN Offset offset
Future work includes removing the duplicate varying added for
gl_PointSize and use this mechanism to decorate gl_PerVertex directly.
Bug: angleproject:3606
Change-Id: I6fed0b1ee7245fe695337043b40b281fb01a1fb0
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2599953
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
f6df8692
|
2020-12-09T12:46:35
|
|
Vulkan: Support XFB in non-Vertex stages.
This updates the code in several places to support Geometry and
Tessellation Evaluation shaders to output transform feedback.
Does not turn on any new tests but enables support for XFB when we
turn on GS/TS.
Bug: angleproject:3571
Bug: angleproject:3572
Change-Id: I6dcb768f2df4eeee81a4a500e999fcf16716f58f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2581941
Reviewed-by: Tim Van Patten <timvp@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
|
|
|
2ffff6d0
|
2020-11-12T10:56:06
|
|
Vulkan: Support image buffers
This change does not support reinterpreted formats yet. Additionally,
despite lack of support for RGB32 formats, EXT_texture_buffer is exposed
by this extension. Those formats don't support the STORAGE_TEXEL_BUFFER
feature on any known hardware.
Bug: angleproject:3573
Change-Id: I85f45eb23f6a0aa533488bb98d9f226d59af4d76
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2534395
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
|
5b419533
|
2020-11-03T13:33:44
|
|
GL: Implement EXT_YUV_target
Add test coverage of YUV format sampling as RGB or directly as YUV and
rendering as YUV using layout(yuv).
Initializing YUV AHardwareBuffers requires Android API 29 so ANGLE must
be compiled with:
android32_ndk_api_level = 29
android64_ndk_api_level = 29
The following tests can still run with Android API 26 because they don't
need to initialize the buffer:
ImageTestES3.ClearYUVAHB
ImageTestES3.YUVValidation
Bug: angleproject:4852
Bug: b/172649538
Change-Id: I4fe9afb2a68fb827dc5a5732b213b5eb60d585ac
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2517562
Commit-Queue: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
fa616931
|
2020-09-03T14:58:03
|
|
Mark uniform samplers in an array unused per element
https://bugs.webkit.org/show_bug.cgi?id=215630
Fix an issue with the OpenGL backend where entire arrays of
uniforms would be marked as unused if a single element was
reported as unused by the driver.
Bug: angleproject:5006
Change-Id: I9bbb75a5f113472393e8d9f1fb60a7865aa9529a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2486540
Reviewed-by: Tim Van Patten <timvp@google.com>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: James Darpinian <jdarpinian@chromium.org>
|
|
|
7a0faa82
|
2020-09-24T20:15:26
|
|
Revert "Pass #pragma optimize setting down to compilation."
This reverts commit 499173de1c91932ba272269cab6918bf7e8d7c11.
Reason for revert: Causes unexpected HLSL compiler errors in some
cases. See bug.
Bug: angleproject:5094
Original change's description:
> Pass #pragma optimize setting down to compilation.
>
> This will allow us to disable optimizations in the back-end. This can
> be useful both for developers and for ANGLE to disable very slow
> shader compilation on D3D11.
>
> Also apply this pragma to VerifyMaxVertexUniformVectorsWithSamplers.
> Reduces compilation time by half in local testing.
>
> Bug: angleproject:5076
> Change-Id: I64ad576e11b9cee5b41f8af0d3621570304d65c2
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2420749
> Commit-Queue: Jamie Madill <jmadill@chromium.org>
> Reviewed-by: Jonah Ryan-Davis <jonahr@google.com>
> Reviewed-by: Geoff Lang <geofflang@chromium.org>
TBR=geofflang@chromium.org,jonahr@google.com,jmadill@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: angleproject:5076
Change-Id: I733e788fe8e9421ae0af662c0eb51af1ed79dde3
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2429517
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
|
|
|
499173de
|
2020-09-20T10:42:56
|
|
Pass #pragma optimize setting down to compilation.
This will allow us to disable optimizations in the back-end. This can
be useful both for developers and for ANGLE to disable very slow
shader compilation on D3D11.
Also apply this pragma to VerifyMaxVertexUniformVectorsWithSamplers.
Reduces compilation time by half in local testing.
Bug: angleproject:5076
Change-Id: I64ad576e11b9cee5b41f8af0d3621570304d65c2
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2420749
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Jonah Ryan-Davis <jonahr@google.com>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
|
|
|
b3545b42
|
2020-07-29T16:50:53
|
|
Get storage buffers/images from ProgramExecutable
Update StateCache::updateActiveShaderStorageBufferIndices() and
StateCache::updateActiveImageUnitIndices to get the storage buffers and
image bindings from the ProgramExecutable, respectively. This requires
updating the ProgramPipeline's ProgramExecutable to build up its vector
of buffers/images from each Program's ProgramExecutable.
Bug: angleproject:4869
Test: VertexAttributeTestES31.UsePpoComputeShaderToUpdateVertexBuffer
Test: SimpleStateChangeTestES31.InvalidateThenStorageWriteThenBlendPpo
Change-Id: I68b7d23eedda910c3dcbf5f9c50b74b5e80134d8
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2327701
Commit-Queue: Tim Van Patten <timvp@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
80d7725d
|
2020-07-15T15:14:17
|
|
Use Subject/Observer pattern for Programs/Executables in PPOs
This CL updates the frontend to use the subject/observer pattern for
Programs and ProgramExecutables in PPOs.
This allows us to remove the hack that iterated through all PPOs and
marking them all dirty when a Program is re-linked. Instead, just the
PPOs the Program is bound to are signalled, and only when the Program
is in a PPO.
Additionally the necessary PPOs are signalled when an Executable's
textures are updated, rather than iterating through all PPOs and
signalling them.
Bug: angleproject:4559
Test: CQ
Change-Id: Iaefb88c64c13259e921c8dfe95cf640247d17f85
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2300705
Commit-Queue: Tim Van Patten <timvp@google.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
289365fa
|
2020-06-12T17:09:13
|
|
Remove ProgramExecutable::mProgram[Pipeline]State
Remove the ProgramExecutable::mProgram[Pipeline]State pointers.
Bug: angleproject:4520
Test: Build/CQ
Change-Id: I1717e291ff9beec226bd2888e990b27d8078797c
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2243764
Commit-Queue: Tim Van Patten <timvp@google.com>
Reviewed-by: Courtney Goeltzenleuchter <courtneygo@google.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
|
ce29916b
|
2020-06-12T14:40:22
|
|
Remove mProgramState from ProgramExecutable::isCompute()
ProgramExecutable::isCompute() is being updated to no longer use
mProgramState or mProgramPipelineState, as part of the effort to remove
those members from ProgramExecutable. Functionally, things are the same
for PPOs, but Programs are being updated to use the boolean
ProgramExecutable::mIsCompute rather than checking the linked shader
stages to determine draw vs compute.
Slightly unrelated, but this CL also removes the unused function
ProgramPipeline::hasImages() which was missed in one of the earlier CLs
in this relation chain.
Bug: angleproject:4520
Test: Build/CQ
Change-Id: Ief28021310d6d0b1be5b7608a59deb87b0cf591d
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2243326
Commit-Queue: Tim Van Patten <timvp@google.com>
Reviewed-by: Courtney Goeltzenleuchter <courtneygo@google.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
|
a28efb2f
|
2020-06-12T13:14:48
|
|
Remove mProgramState from ProgramExecutable::updateActiveImages()
Use of the member variable mProgramState is being removed to reduce the
circular coupling of ProgramExecutable and ProgramState.
Bug: angleproject:4520
Test: Build/CQ
Change-Id: I31d7e607fb06a374a0b0e1d35eb2a092614badf5
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2243323
Commit-Queue: Tim Van Patten <timvp@google.com>
Reviewed-by: Courtney Goeltzenleuchter <courtneygo@google.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
|
c5014259
|
2020-06-11T23:30:47
|
|
Move ProgramState::mImageBindings to ProgramExecutable
The member ProgramState::mImageBindings is being moved to
ProgramExecutable to allow ProgramExecutable::getImageBindings() to
answer the query without relying on the Program[Pipeline]State.
Bug: angleproject:4520
Test: Build/CQ
Change-Id: Ia4934c8e57b5ba49b0a399dcad7c1b324c43385d
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2241750
Reviewed-by: Courtney Goeltzenleuchter <courtneygo@google.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Tim Van Patten <timvp@google.com>
|
|
|
c117e360
|
2020-06-05T15:48:36
|
|
Move ProgramState::mSamplerBindings to ProgramExecutable
The member ProgramState::mSamplerBindings is being moved to
ProgramExecutable to allow ProgramExecutable::getSamplerBindings() to
answer the query without relying on the Program[Pipeline]State.
Bug: angleproject:4520
Test: Build/CQ
Change-Id: I0daa997424d6e2aa5172e0731da221db72063435
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2233363
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Courtney Goeltzenleuchter <courtneygo@google.com>
Commit-Queue: Tim Van Patten <timvp@google.com>
|
|
|
db3ef872
|
2020-05-28T20:04:06
|
|
Move ProgramState::mDefaultUniformRange to ProgramExecutable
The member ProgramState::mDefaultUniformRange is being moved to
ProgramExecutable to allow ProgramExecutable::hasDefaultUniforms() to
answer the query without relying on the Program[Pipeline]State.
Bug: angleproject:4520
Test: Build/CQ
Change-Id: Ic0d78b7193a28962b7ab6480964f8920a23bb7be
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2220776
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Courtney Goeltzenleuchter <courtneygo@google.com>
Commit-Queue: Tim Van Patten <timvp@google.com>
|
|
|
77851053
|
2020-05-26T18:14:56
|
|
Reduce dependency on ProgramExecutable::mProgram[Pipeline]State
Remove the dependency on mProgramState/mProgramPipelineState for the
following functions in ProgramExecutable:
hasUniformBuffers()
hasStorageBuffers()
hasAtomicCounterBuffers()
hasTransformFeedbackOutput()
getTransformFeedbackBufferCount()
The data structures those function were querying were recently moved
into the ProgramExecutable, so the call stack was:
ProgramExecutable -> ProgramState -> ProgramExecutable
This change updates the functions to return the results immediately.
Remaining functions to be cleaned up in later CLs:
hasDefaultUniforms()
hasTextures()
hasImages()
Bug: angleproject:4520
Test: Build/CQ
Change-Id: Ieaa041ff128e389f322745d55f688d4b07a5a23d
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2216764
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Tim Van Patten <timvp@google.com>
|
|
|
d34ab323
|
2020-05-04T10:48:48
|
|
Vulkan: Save linked ProgramExecutable data
PPOs need to support drawing with Programs that failed their last
linkProgram() if they had previously successfully linked. This requires
saving the ProgramExecutable when linkProgram() succeeds, and not
overwriting it with subsequent linkProgram() calls unil the next
successful one.
To achieve this, the new member ProgramState::mLinkedExecutable will
point to the last successfully linked ProgramExecutable and
ProgramState::mExecutable will point to a new ProgramExecutable when the
next linkProgram() is attempted. If the link fails, the newly allocated
ProgramExecutable will be delete()'ed and mExecutable will point to the
previous 'good' ProgramExecutable still being tracked by
mLinkedExecutable. If it succeeds, the old mLinkedExecutable will be
delete()'ed and mLinkedExecutable will be updated to point to the ne
one.
Bug: angleproject:4514
Test: KHR-GLES31.core.sepshaderobjs.StateInteraction
Change-Id: I0677602a6d652a055404667ec9e9305fed5b4177
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2181450
Commit-Queue: Tim Van Patten <timvp@google.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
|
fecd1afc
|
2020-05-04T10:24:57
|
|
Vulkan: Move necessary members from ProgramState to ProgramExecutable
ProgramPipeline's need to be able to link Programs before drawing, even
if the Program's previous linkProgram() failed. To work towards this,
some ProgramState members are being moved to ProgramExecutable so they
can be saved when linkProgram() succeeds and not overwritten by any
subsequent linkProgram() attempts that may fail.
This also allows the second half of this change, which is to pass in the
Program's ProgramExecutable to GlslangAssignLocations() and
GlslangWrapperVk::TransformSpirV() so the values saved from the last
successful linkProgram() are used.
Bug: angleproject:4514
Test: CQ
Change-Id: I68aa429be76c0c6e1b886be09a12200217fcc7ab
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2181448
Commit-Queue: Tim Van Patten <timvp@google.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
|
12b6a82e
|
2020-04-03T18:31:22
|
|
No-Op draws when no active VS and/or FS is present
Re-land CL with WebGL fixes:
This required some extra pointer checking during validation to handle
the fact that a Program and/or ProgramExecutable may not be present when
attempting to draw. This isn't an error, just undefined behavior, which
we (eventually) treat as a no-op.
According to the OpenGL ES 3.1 spec:
7.3. PROGRAM OBJECTS
If there is no active program for the vertex or fragment shader
stages, the results of vertex and fragment shader execution will
respectively be undefined. However, this is not an error.
To handle this, if no VS or FS is present in the active Program/PPO,
we will no-op the draw command.
Bug: angleproject:3570
Test: KHR-GLES31.core.sepshaderobjs.StateInteraction
Change-Id: I70d688bf344a78cf3b4fd66c995ae03ce4b9b807
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2185156
Reviewed-by: Courtney Goeltzenleuchter <courtneygo@google.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Tim Van Patten <timvp@google.com>
|
|
1ab55d96
|
2020-05-06T14:45:18
|
|
Revert "No-Op draws when no active VS and/or FS is present"
This reverts commit a4b506f79e3286ffcf3a5d68f20aa97a63edab8e.
Reason for revert: WebGL crash
https://bugs.chromium.org/p/angleproject/issues/detail?id=4616
Original change's description:
> No-Op draws when no active VS and/or FS is present
>
> According to the OpenGL ES 3.1 spec:
>
> 7.3. PROGRAM OBJECTS
> If there is no active program for the vertex or fragment shader
> stages, the results of vertex and fragment shader execution will
> respectively be undefined. However, this is not an error.
>
> To handle this, if no VS or FS is present in the active Program/PPO,
> we will no-op the draw command.
>
> Bug: angleproject:3570
> Test: KHR-GLES31.core.sepshaderobjs.StateInteraction
> Change-Id: If19e9fbb1bc09fa0d490832079bb9f514eab6035
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2136386
> Reviewed-by: Jamie Madill <jmadill@chromium.org>
> Commit-Queue: Tim Van Patten <timvp@google.com>
TBR=timvp@google.com,jmadill@chromium.org,cclao@google.com
Change-Id: Ia24c4156ff7779b69c1f3f705f1a91cbb1c9684c
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: angleproject:3570
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2184849
Reviewed-by: Courtney Goeltzenleuchter <courtneygo@google.com>
Commit-Queue: Courtney Goeltzenleuchter <courtneygo@google.com>
|