|
d193d51b
|
2024-06-17T22:46:08
|
|
Replace issue ids post migration to new issue tracker
This change replaces anglebug.com/NNNN links.
Bug: None
Change-Id: I8ac3aec8d2a8a844b3d7b99fc0a6b2be8da31761
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5637912
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
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>
|
|
|
1152f9d1
|
2024-04-10T22:05:35
|
|
Remove PPO as observer of its own executable
No messages from PPOs observer come to the PPO for processing anymore.
All messages come from the attached programs.
Bug: angleproject:4559
Bug: angleproject:6358
Change-Id: I55a6884d843655c4dfabd33ea370c61ec27183d1
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5444726
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Yuxin Hu <yuxinhu@google.com>
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
85b3e967
|
2024-04-01T14:31:17
|
|
Fail link and validation of invalid tessellation program
The GL_EXT_tessellation_shader spec says -
The tessellation control and evaluation shaders are both optional.
If neither shader type is present, the tessellation stage has no
effect. However, if either a tessellation control or a tessellation
evaluation shader is present, the other must also be present.
Fail link and validation if a program contains TCS or TES shader but not
both.
Bug: angleproject:3572
Tests: KHR-GLES32.core.tessellation_shader.single.xfb_captures_data_from_correct_stage
Change-Id: I6799f101a186f3bfae738df442e9aeee691fd91a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5410646
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: mohan maiya <m.maiya@samsung.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>
|
|
|
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>
|
|
|
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>
|
|
|
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>
|
|
|
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>
|
|
|
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>
|
|
|
571b4cdb
|
2023-08-14T16:55:28
|
|
Vulkan: Move pipeline/desc-set layout creation to link job
The pipeline and desc-set layout caches are consequently made
thread-safe. The reference counter on the layouts are also made atomic.
With this change, practically all of the link in the Vulkan backend is
moved to the link job.
Bug: angleproject:8297
Change-Id: Iba694ece5fc5510d34cce2c34441ae08ca5bb646
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4774787
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
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>
|
|
|
7b0c78ba
|
2023-07-28T10:00:28
|
|
Remove unused code in ProgramPipeline
shaderUniforms is set but never used.
Bug: b/275102061
Change-Id: Ided52748f6e8925cdbbb996d70966de2d1fc2c9a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4727743
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Roman Lavrov <romanl@google.com>
|
|
|
e21ecd1b
|
2023-05-26T14:06:46
|
|
Vulkan: Add dirty bit processing for uniform buffer change
When app calls glBufferData for the uniform buffer, we may end up
reallocate the storage. This will set DIRTY_BIT_UNIFORM_BUFFER_BINDINGS
on the context, but the exact uniform block index gets lost along the
way. This CL sets mDirtyBits on the program for the corresponding block
index and then changed vulkan backend to utilize the program's
mDirtyBits and only update the buffer if it is dirty, instead of always
update all uniform buffers even if only one of the buffer is dirty. In
order to make this work, this CL also adds the reverse tracking from
buffer binding to uniform blocks. Previously we already have the
tracking of which buffer binding index is used for which buffer block
index. This CL adds mUniformBlockBindingMasks which is an array of
BitSets. Each array element tracks all the uniform block index that is
using this buffer binding index (you can have the same buffer bound to
multiple uniform block index). Then when a buffer binding index is
dirty, that BitSet gets added into program's uniform block dirty bits.
This CL and previous CL improves GfxBench gl_driver2_off score 1.8%
(from average 6797 to average 6919) on pixel 7 pro.
Bug: b/282194402
Change-Id: Ic5002643a5297907276fc9b20ca7d21af9bdc4fe
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4553136
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Roman Lavrov <romanl@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
d375547c
|
2022-08-12T15:54:39
|
|
Do not link program pipeline in glUseProgramStages
1. The commit 3a9f18f135fe82 caused a link to occur everytime
glUseProgramStages is called. This is redundant since the program
pipeline can be linked just before usage, thus allowing for multiple
stages to be bound before linking the executable.
2. Mark PPO as a dirty object and link the PPO in dirty object handler
3. Early return if the same program is being bound to the same stage
of the pipeline.
4. Added ProgramPipelineObjectBenchmark perf test that switches programs
before a draw and observed following data -
1. vulkan profile -
1. wall_time before patch - 102000 ns
2. wall_time after patch - 38000 ns
2. vulkan_null profile -
1. wall_time before patch - 125000 ns
2. wall_time after patch - 52000 ns
Bug: angleproject:5102
Bug: angleproject:6566
Test: ContextNoErrorPPOTest31.*Vulkan
Test: ProgramPipelineTest31.*Vulkan
Test: ProgramPipelineObjectBenchmark*
Change-Id: Idbc2fcb4875bbd040e9ec847eb2a8f96f287173c
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3830170
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: mohan maiya <m.maiya@samsung.com>
|
|
|
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>
|
|
7d6f3d94
|
2022-07-14T13:25:04
|
|
glValidateProgramPipelines: Skip draw state error check
Certain apps will call this API while having a surfaceless context,
making it improperly fail.
dEQP tests that previously relied on the full draw states check
were actually relying on the part where the draw state check included a
check that the pipeline object had programs/shaders. Relax the
validation of the pipeline to only include that validation, and not also
the framebuffer state / VBO state / etc.
Bug: b/223456677
Change-Id: I9211761934668aae8a20f07ac4f36b7f6c1281da
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3764434
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Lingfeng Yang <lfy@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
fb3e2def
|
2022-05-24T15:47:01
|
|
Extend labelObject functionality
Modify interface to fully support labelObject return codes.
Fix issues with texture implementation, including handling
deferred Vulkan object creation.
Bug: b/229105865
Change-Id: I0c64b72dd0b54642fb643ee7f5ccbb2a134c6787
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3703184
Commit-Queue: Ian Elliott <ianelliott@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Ian Elliott <ianelliott@google.com>
|
|
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>
|
|
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>
|
|
|
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>
|
|
|
7c1346bd
|
2022-01-21T11:35:45
|
|
Vulkan: Consolidate uniforms code in ProgramExecutableVk.
De-duplicates several methods. Refactoring change only.
Bug: angleproject:3570
Change-Id: Ib68bc30b3e9b1087871bb268ea292677e0c9fe2e
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3408061
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>
|
|
|
85e2991f
|
2022-01-21T18:14:35
|
|
Fix couple LSAN detected leaks in unit and end2end tests
Bug: angleproject:6937
Change-Id: Ibef9a300056509437edd50e9db18908c0b6d449e
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3413271
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Yuly Novikov <ynovikov@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>
|
|
|
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>
|
|
10846073
|
2021-08-30T14:41:16
|
|
Allow image uniforms to be used in separable programs
This change updates mActiveImagesMask in ProgramExecutable
for separable programs. Previously image uniforms would only
work in the first shader stage.
Bug: angleproject:4512
Tests: ProgramPipelineTest31.ImageUniforms
Change-Id: Ib35bed94bb8fac883fd67f8bfa052186926d0ce4
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3131582
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Brandon Schade <b.schade@samsung.com>
|
|
|
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>
|
|
|
c8ee13c7
|
2021-04-02T12:19:33
|
|
Vulkan: Fix a validation bug in glBeginTransformFeedback
Add logic to check the program or the pipeline before erroring out when
validating glBeginTransformFeedeback.
Bug: angleproject:5557
Test: ProgramPipelineXFBTest31.VaryingIOBlockSeparableProgramWithXFB*
Change-Id: I0df8a8d87b3632745bc91dc2673f2fac31c6cdb1
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2743440
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
Commit-Queue: Mohan Maiya <m.maiya@samsung.com>
|
|
0261b1d3
|
2021-03-31T10:48:08
|
|
PPO: Fix updating sampler uniforms between draws
Updating sampler uniforms when using PPOs is currently broken, since the
Context/State use the currently bound ProgramExecutable which belongs to
the PPO, but the updates only happen to the Program's executable that
the uniform belongs to.
This change updates Program::updateSamplerUniform() to update any PPO
ProgramExecutables with the updated texture information when a Program's
sampler uniforms are updated, so the Context/State use the correct data.
Bug: b/182409935
Test: ProgramPipelineTest31.SampleTextureAThenTextureB
Test: SamplersTest31.SampleTextureAThenTextureB
Change-Id: I3c4e156c6e0c781e706f321f0bd12baf484ff42a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2797951
Commit-Queue: Tim Van Patten <timvp@google.com>
Reviewed-by: Cody Northrop <cnorthrop@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@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>
|
|
|
fe3a9ffb
|
2021-03-17T18:05:40
|
|
Support linking PPOs without attached Shaders
The application "Command & Conquer: Rivals" uses the following pattern:
// Create and link VS, save binary data
glCreateProgram()
glAttachShader()
glLinkProgram()
glGetProgramBinary()
// Create and link FS, save binary data
glCreateProgram()
glAttachShader()
glLinkProgram()
glGetProgramBinary()
...
// Create VS, load binary data
glCreateProgram()
glProgramBinary()
// Create FS, load binary data
glCreateProgram()
glProgramBinary()
...
glUseProgramStages(GL_VERTEX_SHADER_BIT)
glUseProgramStages(GL_FRAGMENT_SHADER_BIT)
glBindProgramPipeline()
Later, when issuing the draw command that uses the PPO, the PPO must be
linked with the Programs that were loaded via binary data. Those
Programs don't have any Shaders attached, just linked. This CL adds
support for linking Programs without attached Shaders.
Bug: b/182409935
Test: ProgramPipelineTest31.ProgramBinary
Change-Id: Ic5a4776e1374322665f45fbbcbf955838d093d02
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2770685
Commit-Queue: Tim Van Patten <timvp@google.com>
Reviewed-by: Cody Northrop <cnorthrop@google.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
|
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>
|
|
|
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>
|
|
|
6d86a0fe
|
2021-01-29T11:08:04
|
|
Fix mActiveImageShaderBits not updated in PPO's executable
Allows the backend to rely on this bitset always being valid, instead of
working around the bug.
Bug: angleproject:5587
Change-Id: I25e1304c0e5e34b5fc1677a819315574603ed034
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2658885
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
|
|
|
2dae09e8
|
2021-01-27T13:54:25
|
|
Fix draw mode validation of PPOs with geometry/tessellation
The properties related to geometry and tessellation shaders were not
being copied from the Program's exectuble to the Program Pipeline's.
Bug: angleproject:5557
Bug: angleproject:5579
Change-Id: Ied6ff82c7e30f24504c9a3f5c008181b179b07ff
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2653909
Reviewed-by: Tim Van Patten <timvp@google.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
cea86910
|
2021-01-14T08:13:00
|
|
Vulkan: Support EXT_clip_cull_distance extension
EXT_clip_cull_distance extension is supported except for
some features related to EXT_tessellation_shader and
EXT_geometry_shader. Also added a few compiler tests to validate
the transformation from ESSL to GLSL for Vulkan backend.
Bug: angleproject:5458
Tests: angle_end2end_tests --gtest_filter=Clip*DistanceTest*
angle_unittests --gtest_filter=*Clip*Distance*
Change-Id: Ie74e6b2b55112ad92ad111191d629b63506032ab
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2585987
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Mohan Maiya <m.maiya@samsung.com>
|
|
|
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>
|
|
|
3e33db95
|
2020-12-30T17:17:17
|
|
Merge Program/ProgramPipeline::getMergedVaryings().
This merges two very similar pieces of code into one simpler function.
The function doesn't use any maps or indirection to build the merged
varyings list. It also fixes a potential bug with IO blocks and name
matching due to the code bifurcation.
Bug: angleproject:5496
Change-Id: Ibf54faeeb01d1940570b366ed153fff7c9135c52
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2606533
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
d9669322
|
2020-12-30T14:33:02
|
|
Remove "init" from VaryingPacking.
Instead we can pass the pack mode and size to the collectAndPack
method. This cleans up the interface and also allows us to merge
two separate code blocks in Program and ProgramPipeline.
Bug: angleproject:5496
Change-Id: I390b5d2e8a3b033374ccc5a250597be1f03dec96
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2606531
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
|
|
|
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>
|
|
|
4accbe92
|
2020-12-04T12:27:01
|
|
Fix separable Geometry shaders.
Geometry shaders weren't being processed in some of the separable
shader logic. This CL fixes two cases: one in Program and one in
ProgramPipeline.
Bug: angleproject:5409
Change-Id: I19adc5c11a54814d28dd20574a5e038ca9dbd021
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2574827
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
24f64249
|
2020-11-16T17:55:02
|
|
Vulkan: Track specialization constant usage bit and feedback to ctx
Right now context does not know which specialization constant is used by
the shader. Whenever a specialization constant changes, we assume shader
program is using it, we always reach into vulkan driver to ask for a new
program. Instead we can track shader's usage of specialization constant
so that context can utilize this information to avoid recompile pipeline
program if an unused specialization constant has changed.
This CL implements the plumbing the usage bits form compiler to program
object, it does not actually utilize the usage bits to avoid unnecessary
compilation yet.
Bug: b/173461931
Change-Id: Iebc9d0638c17b1a282c8b6093ce6bae154246e57
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2542866
Reviewed-by: Ian Elliott <ianelliott@google.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
001c7e8c
|
2020-09-21T13:25:46
|
|
Vulkan: Link PPO during draw validation
From the OpenGL ES 3.1 spec:
11.1.3.11 Validation
It is not always possible to determine at link time if a program object
can execute successfully, given that LinkProgram can not know the state
of the remainder of the pipeline. Therefore validation is done when the
first rendering command which triggers shader invocations is issued, to
determine if the set of active program objects can be executed.
For draws, this CL moves the PPO link operation to ValidateDrawStates()
to generate PPO link failures within ANGLE's validation layer, so we
fail any rendering commands during command validation.
For dispatch, PPOs are linked during Context::prepareForDispatch(),
where the PPO is converted from draw to compute, since that conversion
requires a re-link. This re-link shouldn't fail due to errors that would
have been caught during validation, since the compute shader must have
successfully linked before it can be included in the PPO in the first
place. We don't re-link when converting back to draw, since it's
possible there are validation errors (which we want to catch during
validation of the next rendering command).
Bug: angleproject:5064
Test: dEQP.GLES31/functional_separate_shader_validation_es31_*
Test: ContextNoErrorTest31.DrawWithPPO
Test: ProgramPipelineTest31.VerifyPpoLinkErrorSignalledCorrectly
Change-Id: Ibb249e893c007a83cc6b813f848a660bfa34ecb0
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2422375
Commit-Queue: Tim Van Patten <timvp@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Ian Elliott <ianelliott@google.com>
|
|
|
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>
|
|
c5b5cf6c
|
2020-09-10T16:58:18
|
|
Refactor to pass ProgramMergedVaryings to link impl
Follow-on CL needs the ProgramMergedVaryings in the Vulkan backend to
generate valid SPIRV.
Bug: angleproject:3078
Change-Id: Ic442a3e0bd713fec36bd6b9420f67f3b1118e5ad
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2404336
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Courtney Goeltzenleuchter <courtneygo@google.com>
|
|
|
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>
|
|
|
e0a2bd5e
|
2020-07-15T18:07:45
|
|
Remove ProgramPipelineState::mHasBeenBound
The member ProgramPipelineState::mHasBeenBound is unused and should be
removed.
Bug: angleproject:3570
Test: CQ
Change-Id: Idc41574f79e665ac36bef5b206704c667c49dadb
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2301101
Reviewed-by: Courtney Goeltzenleuchter <courtneygo@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Tim Van Patten <timvp@google.com>
Commit-Queue: Tim Van Patten <timvp@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>
|
|
|
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>
|
|
|
24268826
|
2020-05-04T10:48:48
|
|
Vulkan: Pass Input/Output Varying lists during linking
When linking program varyings, the necessary functions need the
following:
- Lists of Input and Output varyings
- Shader versions
- Shader types
Rather than the full Shader itself, just this information will be
passed around to the functions. This allows us to limit how much data
is saved for each Program when linkProgram() succeeds, so PPos can link
the attached Programs at draw time.
Bug: angleproject:4514
Test: CQ
Change-Id: I27b639cae9a153d0d3f5efab3b38550f09f4f49b
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2181449
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>
|
|
|
39d187b8
|
2020-04-23T19:30:12
|
|
Update Program[Pipeline]State to hold a ProgramExecutable Pointer
This is a refactor CL to convert mExecutable in ProgramState and
ProgramPipelineState to a pointer, so it can be changed to point to a
different ProgramExecutable in a future CL.
Bug: angleproject:4514
Test: end2end
Change-Id: Id8ee9e5f2d1b02313973519cb2b4b0d5f7533b09
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2181447
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>
|
|
|
a4b506f7
|
2020-04-03T18:31:22
|
|
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>
|
|
|
913f4f42
|
2020-04-15T00:54:37
|
|
Vulkan: Support VS, FS, and CS in the same PPO
This CL adds support for a Program Pipeline Object to have a VS, FS,
and CS attached to the same PPO and then using that PPO for both draw
and dispatch calls.
Bug: angleproject:3570
Test: KHR-GLES31.core.compute_shader.sso*
Change-Id: I262cdbdfd442f6db5ba2b45d1308003102b237cb
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2150078
Reviewed-by: Tim Van Patten <timvp@google.com>
Reviewed-by: Courtney Goeltzenleuchter <courtneygo@google.com>
Commit-Queue: Tim Van Patten <timvp@google.com>
|
|
|
405f8e7b
|
2020-02-24T17:38:10
|
|
Vulkan: Support Program Pipeline Objects
Add support for PPOs to the Vulkan back end.
Bug: angleproject:3570
Change-Id: I5403456929847c185467b008d810f31ecfcb60cc
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2072652
Commit-Queue: Tim Van Patten <timvp@google.com>
Reviewed-by: Courtney Goeltzenleuchter <courtneygo@google.com>
|
|
|
68083e89
|
2020-03-04T15:55:53
|
|
Vulkan: Move cached samplers/images and has*() to ProgramExecutable
The active samplers and images are being moved from Program into
ProgramExecutable to unify interacting with them for Programs and
ProgramPipelines
Also, create some helper functions for gl::Program that ProgramExecutable can
call to make it easier for ProgramPipeline to respond to similar
queries for each of the Programs in the ProgramPipeline.
Bug: angleproject:3570
Change-Id: I0b37f1a379e56b9659d82d92f6d7a546beee11cd
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2087648
Commit-Queue: Tim Van Patten <timvp@google.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
|
c431d596
|
2019-12-16T10:59:44
|
|
Add Serial to all GL resources.
The Serial will help track active resources for filtering out
inactive setup calls in capture/replay.
Bug: angleproject:4223
Change-Id: I64ba50f27d656c12d45155dc735e9b6f9c04528f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1969062
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Cody Northrop <cnorthrop@google.com>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
|
|
|
f703443b
|
2019-09-21T14:10:35
|
|
Use Resource IDs in RefCountObject.
This lets us use strongly typed IDs pretty much everywhere. Only one or
two additional places still use GLuint IDs. Mostly for external queries
and for Framebuffer Attachments.
With some clever type reflection helpers lets us define a single
template function for handling operator== and != for resource IDs.
Refactor in preparation for more Capture/Replay work.
Bug: angleproject:3611
Change-Id: I1c0c848e89eb8a4b769714d57686f816daf01634
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1815550
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Tobin Ehlis <tobine@google.com>
|
|
378c1881
|
2019-08-22T16:55:39
|
|
Use ProgramPipelineID in place of GLuint handle
Bug: angleproject:3804
Change-Id: Ice37a4b3d43008e5bcd5d0a7528514d5bb504066
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1767322
Reviewed-by: Jiacheng Lu <lujc@google.com>
Commit-Queue: Jiacheng Lu <lujc@google.com>
|
|
9d737966
|
2019-08-14T12:25:12
|
|
Standardize copyright notices to project style
For all "ANGLE Project" copyrights, standardize to the format specified
by the style guide. Changes:
- "Copyright (c)" and "Copyright(c)" changed to just "Copyright".
- Removed the second half of date ranges ("Y1Y1-Y2Y2"->"Y1Y1").
- Fixed a small number of files that had no copyright date using the
initial commit year from the version control history.
- Fixed one instance of copyright being "The ANGLE Project" rather than
"The ANGLE Project Authors"
These changes are applied both to the copyright of source file, and
where applicable to copyright statements that are generated by
templates.
BUG=angleproject:3811
Change-Id: I973dd65e4ef9deeba232d5be74c768256a0eb2e5
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1754397
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
|
e90d4ee9
|
2018-11-28T14:04:00
|
|
Pass Context to setLabel.
This is useful for triggering a dirty state notification for Textures.
It will lead to improvements for program and texture dirty bits.
Bug: angleproject:2966
Change-Id: Iaba625da8a970a558f7d158bfa2f09c964f6761a
Reviewed-on: https://chromium-review.googlesource.com/c/1347669
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Yuly Novikov <ynovikov@chromium.org>
|
|
|
b980c563
|
2018-11-27T11:34:27
|
|
Reformat all cpp and h files.
This applies git cl format --full to all ANGLE sources.
Bug: angleproject:2986
Change-Id: Ib504e618c1589332a37e97696cdc3515d739308f
Reviewed-on: https://chromium-review.googlesource.com/c/1351367
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
1c7f08c3
|
2018-10-10T16:13:02
|
|
Inline RefCountObject::release.
Also don't return errors from the object release methods. Not returning
errors reduces the amount of code generated. Also we shouldn't be
exiting early from destructor type functions.
Increases object binding performance.
Bug: angleproject:2877
Change-Id: Ieb8120d885b946915e355419825e1f52f31d7b49
Reviewed-on: https://chromium-review.googlesource.com/c/1270218
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
|
|
|
acf2f3ad
|
2017-11-21T19:22:44
|
|
Apply Chromium style fixes.
This addresses several minor code quality issues that are validated
in Chromium, but not yet applied to ANGLE:
* constructors and destructors must be defined out-of-line
* auto is not allowed for simple pointer types
* use override everywhere instead of virtual
* virtual functions must also be defined out-of-line
Slightly reduces binary size for me (~2k on Win, 150k on Linux).
Bug: angleproject:1569
Change-Id: I073ca3365188caf5f29fb28d9eb207903c1843e6
Reviewed-on: https://chromium-review.googlesource.com/779959
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
a336b90f
|
2017-08-02T16:05:21
|
|
ES31: Impl program pipeline object management entries for GL backend.
The program pipeline object management entries are:
GenProgramPipelines
DeleteProgramPipelines
BindProgramPipeline
IsProgramPipeline
BUG:angleproject:2123
Change-Id: I114d054b90caf2ee3f9befef7439552a1c309bc4
Reviewed-on: https://chromium-review.googlesource.com/629978
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
|