kc3-lang/angle/src/libANGLE/ProgramExecutable.cpp

src/libANGLE/ProgramExecutable.cpp

Log

Author Commit Date CI Message
Mohan Maiya b3ec3a5f 2025-06-23T14:51:13 Track active uniform and storage buffer blocks Track active uniform and storage buffer block indices so we can process updates to only active buffer blocks Bug: angleproject:426412564 Change-Id: I54fa6fbe795073887646d672303d231ed4317b65 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6663825 Commit-Queue: mohan maiya <m.maiya@samsung.com> Reviewed-by: Charlie Lao <cclao@google.com>
Aurora Zhang dfefcbc6 2025-06-09T16:30:55 glGetProgramiv should return the properties in effect glProgramParameteri can set values to GL_PROGRAM_BINARY_RETRIEVABLE_HINT. However, this setting will not be in effect until the next time glLinkProgram or glProgramBinary has been called successfully. Also, glGetProgramiv returns the properties currently in effect for program. Therefore, we need to add a variable to record the ineffective value and copy it at the stage of glLinkProgram or glProgramBinary. Bug: angleproject:421219220 Change-Id: Ib564e6df03d34f3fc7389f926795cb3e64cbf687 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6606372 Reviewed-by: Yuxin Hu <yuxinhu@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Auto-Submit: Aurora Zhang <Aurora.Zhang@arm.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Mavis Deng 3c554454 2025-04-03T16:55:11 Incorrect BUFFER_DATA_SIZE and UNIFORM_OFFSET for ACB array of array The buffer size and offset calculation for the atomic counter buffer defined as an array of arrays is incorrect. The issue occurs with the following declaration: layout (binding=0, offset=0) uniform atomic_uint ac[2][2]; Observed Results: GL_BUFFER_DATA_SIZE -> 8; GL_UNIFORM_OFFSET of "ac[1][0]" -> 0; Expected Results: GL_BUFFER_DATA_SIZE -> 16; GL_UNIFORM_OFFSET of "ac[1][0]" -> 8; Bug: angleproject:407564097 Change-Id: Ibf99ccd5412629f0feb74a9a34337b82894e74c6 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6429625 Auto-Submit: Mavis Deng <mavis.deng@arm.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com> Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Xinyu Fang e914b53d 2025-02-18T17:13:08 Add validation of null pointers for certain APIs Bug: angleproject:397315932 Change-Id: I3b253a7ca0bbdf4fd55cf67943971426d825cd24 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6275697 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Geoff Lang <geofflang@chromium.org>
Chris Dalton 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>
Charlie Lao 0e0e5eae 2024-10-28T14:12:30 Minor clean up for mSamplerBindings usage Use "const" keyword for samplerBinding. Bug: None Change-Id: Ic2c0b133c405012a111919ad07f45d84c07eecee Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5972764 Reviewed-by: Yuxin Hu <yuxinhu@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi 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>
Geoff Lang 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>
Geoff Lang 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>
Geoff Lang 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>
Igor Nazarov d0280f09 2024-06-03T13:21:06 Cleanup Program Executable post link task wait Frontend changes: - Add `ASSERT` into `ProgramExecutable::waitForPostLinkTasks()` to check that `mPostLinkSubTasks` must be empty after backend wait. - Add `UNIMPLEMENTED` into `ProgramExecutableImpl` `waitForPostLinkTasks()`, because this method is only required if backend fills `postLinkSubTasksOut` in `LinkTask`, and frontend must not call this method if `mPostLinkSubTasks` are empty. Vulkan backend changes: - Add public `ProgramExecutableVk::waitForComputePostLinkTasks()` with ASSERT to only allow usage with Compute executable. This change avoids confusion calling `waitForPostLinkTasksIfNecessary()` with `nullptr` in case of the Compute pipelines, which will always wait. - Rename `waitForPostLinkTasksIfNecessary()` to `waitForGraphicsPostLinkTasks()`, add ASSERT to only allow usage with Graphics executable, and change optional pointer to the `GraphicsPipelineDesc` to the reference. - Add `WaitableEvent::AllReady()` check into `ProgramExecutableVk` `waitForGraphicsPostLinkTasks()` when going to skip waiting, in order to process tasks (by calling wait) when all tasks are ready. Without this change, post link task may never be processed, causing repeated `GraphicsPipelineDesc` comparisons. - Replace `GraphicsPipelineDesc` hash comparison in `waitForGraphicsPostLinkTasks()` with `keyEqual()` call. This method is around 7 times faster, however effect on the overall performance will likely be unmeasurable. Changed for clarity. - Remove unnecessary `mWarmUpGraphicsPipelineDesc` reset from: `ProgramExecutableVk` initializer list (has default constructor), Compute warmup (already clean after constructor), wait post link tasks (not used when no tasks). - Other minor changes. Bug: angleproject:8297 Change-Id: I7d790da6712be013243083e314af75f82e73886d Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5592474 Reviewed-by: mohan maiya <m.maiya@samsung.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
Igor Nazarov 11c92f77 2024-03-29T16:19:05 Vulkan: Optimize ProgramExecutable::shouldIgnoreUniform() Increases GFX Bench offscreen driver overhead performance on Samsung S24 S921B (locked frequencies) 6201 -> 6327 frames (+2%) Regression commit: Fix off-by-one bounds check on uniform location. fba482b7107ccf3e178f6bf56b6b0285407ace3a Bug: chromium:1504162 Bug: chromium:1484878 Change-Id: I164cbb9feeacd35979cc60aa3489252397a3e2bf Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5585896 Reviewed-by: Geoff Lang <geofflang@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Roman Lavrov 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>
Roman Lavrov 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>
Mohan Maiya 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>
Mohan Maiya 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>
Shahbaz Youssefi 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>
Shahbaz Youssefi 0c4d6446 2024-01-24T10:38:45 Rework uniform block <-> uniform buffer mapping In GLES, the shader declares which buffer binding a block (uniform, storage or atomic counter) is bound to. For example: layout(binding = 1) uniform ubo0 { ... }; layout(binding = 2) uniform ubo1 { ... }; layout(binding = 1) uniform ubo2 { ... }; In the above, ubo0 and ubo2 use data from the buffer bound to index 2 (through glBindBufferRange), while ubo1 uses data from the buffer bound to index 1. For uniform blocks in particular, omitting the binding is allowed, in which case it is implicitly bound to buffer 0. GLES allows uniform blocks (and only uniform blocks) to remap their bindings through calls to glUniformBlockBinding. This means that the mapping of uniform blocks in the program (ubo0, ubo1, ubo2) to the buffer bindings is not constant. For storage blocks and atomic counter buffers, this binding _is_ constant and is determined at link time. At link time, the mapping of blocks to buffers is determined based on values specified in the shaders. This info is stored was stored in gl::InterfaceBlock::binding (for UBOs and SSBOs), and gl::AtomicCounterBuffer::binding. For clarity, this change renames these members to ...::inShaderBinding. When glUniformBlockBinding is called, the mapping is updated. Prior to this change, gl::InterfaceBlock::binding was directly updated, trumping the mapping determined at link time. A bug here was that after a call to glProgramBinary, GL expects the mappings to reset to their original link-time values, but instead ANGLE restored the mappings to what was configured at the time the binary was retrieved. This change tracks the uniform block -> buffer binding mapping separately from the link results so that the original values can be restored during glProgramBinary. In the process, the support data structures for tracking this mapping are moved to ProgramExecutable and the algorithms are simplified. Program Pipeline Objects maintain this mapping identically to Programs and no longer require a special and more costly path when a buffer state changes. This change prepares for but does not yet fix the more fundamental bug that the dirty bits are tracked in the program executable instead of the context state, which makes changes not propagate to all contexts correctly. Bug: angleproject:8493 Change-Id: Ib0999f49be24db06ebe9a4917d06b90af899611e Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5235883 Reviewed-by: Geoff Lang <geofflang@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi 1100cc5c 2024-01-23T16:18:52 Rename ShaderVariableBuffer It was only ever aliased to AtomicCounterBuffer after refactorings that made other buffers not use this class anymore. Bug: b/275102061 Change-Id: I09079d52bd107ed656c4c59a11e8a8027554a5ef Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5230141 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com>
Shahbaz Youssefi 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>
Shahbaz Youssefi 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>
Geoff Lang fba482b7 2023-11-22T12:01:31 Fix off-by-one bounds check on uniform location. Log an error when the user provides an invalid uniform location. Bug: chromium:1504162 Bug: chromium:1484878 Change-Id: Ieb7eb964d508954ac8dfa8e4d9bd941778185223 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5054238 Commit-Queue: Geoff Lang <geofflang@chromium.org> Reviewed-by: James Godfrey-Kittle <jamesgk@google.com>
Geoff Lang e076d6cf 2023-10-17T11:39:10 Move invalid uniform protection to the frontend. The frontend potentialy indexes into mUniformLocations with invalid uniform locations while validation is disabled too. Move the validation from the Metal backend to the frontend. Bug: chromium:1484878 Change-Id: I92bc43aa28cfa26d601bb28f318860375f618608 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4947652 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Cody Northrop 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>
Charlie Lao 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>
Charlie Lao 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>
Shahbaz Youssefi eb0d5997 2023-09-15T16:41:13 Move set/get uniform machinery to ProgramExecutable This is done because some uniforms are internally added by the compiler (draw ID, base vertex, and base instance) and are automatically set **on the installed executable**. This change fixes scenarios where a draw is done after a program has failed a relink, and therefore is unable to correctly set the uniforms (as it does not have access to the executable that is installed). It also fixes draws that use those uniforms in a PPO. Bug: angleproject:8297 Change-Id: Id74b4984b88aa09b5b81be1c91412d6c91711136 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4864693 Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Yuxin Hu <yuxinhu@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi 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>
Charlie Lao 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>
Shahbaz Youssefi 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>
Charlie Lao c5d19d76 2023-09-07T09:58:24 Reland "Load mUniformLocations using loadVector" This is a reland of commit 6f526b8f52d17bf89082a901f06df6edb75a7dbd Original change's description: > Load mUniformLocations using loadVector > > Bug: b/275102061 > Change-Id: I1da5bdd6bf0ec40cd877c2274a8fe1ee0b11267a > Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4849551 > Reviewed-by: Roman Lavrov <romanl@google.com> > Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> > Commit-Queue: Charlie Lao <cclao@google.com> Bug: b/275102061 Change-Id: If501db97a37b00104a9d16fc40200f772ffcd2fc Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4856749 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com>
Shahbaz Youssefi 79691400 2023-09-09T20:50:24 Revert "Load mUniformLocations using loadVector" This reverts commit 6f526b8f52d17bf89082a901f06df6edb75a7dbd. Reason for revert: Suspected cause of MSAN failure. See: https://chromium-review.googlesource.com/c/angle/angle/+/4851776 Original change's description: > Load mUniformLocations using loadVector > > Bug: b/275102061 > Change-Id: I1da5bdd6bf0ec40cd877c2274a8fe1ee0b11267a > Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4849551 > Reviewed-by: Roman Lavrov <romanl@google.com> > Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> > Commit-Queue: Charlie Lao <cclao@google.com> Bug: b/275102061 Bug: chromium:1480543 Change-Id: I50c39758d180320465b152ad32ba9447878f7d8a Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4855538 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Charlie Lao 57761d85 2023-09-08T10:02:48 Attempt to fix the MSan failure on chromium bots struct BlockMemberInfo was not tightly packed. This CL makes it packed. Bug: b/296433003 Change-Id: I38da3e463cf304028236e651b6b4e334ce9220e2 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4851063 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com>
Charlie Lao 6f526b8f 2023-09-07T09:58:24 Load mUniformLocations using loadVector Bug: b/275102061 Change-Id: I1da5bdd6bf0ec40cd877c2274a8fe1ee0b11267a Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4849551 Reviewed-by: Roman Lavrov <romanl@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com>
Shahbaz Youssefi 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>
Shahbaz Youssefi 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>
Charlie Lao 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>
Alexey Knyazev 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>
Shahbaz Youssefi 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>
Shahbaz Youssefi 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>
Shahbaz Youssefi 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>
Shahbaz Youssefi bb135f0e 2023-08-24T15:29:11 Make ProgramExecutableImpl managed by ProgramExecutable This change allows both parts of the program executable to be safely backed up and swapped on link. Bug: angleproject:8297 Change-Id: I17e4b6c05e4e481a66a227d6047dbf943d2c2603 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4812138 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Geoff Lang <geofflang@chromium.org>
Alexey Knyazev 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>
Shahbaz Youssefi 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>
Charlie Lao 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>
Charlie Lao 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>
Shahbaz Youssefi f3c1de36 2023-08-17T15:29:24 Make shader recompile while parallel linking safe Prior to this change, Program* objects held references to Shader* objects. This poses a problem where a shader recompile can race with a program link, if the program link is done in parallel. As a result, a good chunk of the link job is done serially and under the share group lock. After this change, that is no longer a problem, and most of the link can be made lockless/parallelized. This change separates out the "compiled state" from the rest of the shader state. This was already done for the front-end state (for the sake of caching), but is also now done for the backends that need it. The compiled state in turn is placed in a shared_ptr, and is shared with the program. When a shader is compiled, its own shared_ptr is replaced with a new object, leaving all programs currently compiling unaffected and using the previous compilation results. Once a program is linked, its references to compiled shader states is updated. Bug: angleproject:8297 Change-Id: Iff7094a37088fbad99c6241f1c48b0bd4c820eb2 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4791065 Reviewed-by: Geoff Lang <geofflang@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com>
Charlie Lao 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>
Charlie Lao 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>
Charlie Lao 5217beb2 2023-08-15T13:43:12 Reland "Tightly pack LinkedUniform by using int16_t" This is a reland of commit 152cf62b38874238095a91307e4ea9bcdedf8f46 Original change's description: > Tightly pack LinkedUniform by using int16_t > > There is a check of vector size when we link uniforms and the maximum > vector size is 4096 due to we clamp the maxUniformBlockSize to 64KB. In > reality, if we exceeds this number, program link will take really long > time and then hit failure. So there is no real need to keep all the > variables in 32 bit integer. This CL changes to 16 bit integer. Further, > sh::BlockMemberInfo and ActiveVariable data members are embeded into > LinkedUniform struct as well so that the unused variables can be removed > and data can be tightly packed. This also makes LinkedUniform easier to > maintain as a simple struct with basic data types. With this change, > LinkedUniform size is reduced from 108 bytes down to 60 bytes, 48 bytes > reduction. Given some apps has 200-ish uniforms, this CL reduces 48 > bytes x 200 = ~9K memory just for uniforms per program (which goes > through hash compute and decompression and file reads). > > Bug: b/275102061 > Change-Id: I7fae20f5b75f3239305e2094a992e3040b8c8e4c > Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4754133 > Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> > Commit-Queue: Charlie Lao <cclao@google.com> Bug: b/275102061 Change-Id: I1cdec9407e930608d3239a104dcbf77c8d8e2113 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4791661 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com>
Charlie Lao 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>
Vivian Pao 9f48f931 2023-08-16T06:38:15 Revert "Tightly pack LinkedUniform by using int16_t" This reverts commit 152cf62b38874238095a91307e4ea9bcdedf8f46. Reason for revert: Suspect cause of failure in for several Linux MSan Tests, e.g. https://ci.chromium.org/ui/p/chromium/builders/ci/Linux%20MSan%20Tests/42403/overview https://ci.chromium.org/ui/p/chromium/builders/ci/WebKit%20Linux%20MSAN/22174/overview https://ci.chromium.org/ui/p/chromium/builders/ci/Linux%20MSan%20Tests/42403/overview Original change's description: > Tightly pack LinkedUniform by using int16_t > > There is a check of vector size when we link uniforms and the maximum > vector size is 4096 due to we clamp the maxUniformBlockSize to 64KB. In > reality, if we exceeds this number, program link will take really long > time and then hit failure. So there is no real need to keep all the > variables in 32 bit integer. This CL changes to 16 bit integer. Further, > sh::BlockMemberInfo and ActiveVariable data members are embeded into > LinkedUniform struct as well so that the unused variables can be removed > and data can be tightly packed. This also makes LinkedUniform easier to > maintain as a simple struct with basic data types. With this change, > LinkedUniform size is reduced from 108 bytes down to 60 bytes, 48 bytes > reduction. Given some apps has 200-ish uniforms, this CL reduces 48 > bytes x 200 = ~9K memory just for uniforms per program (which goes > through hash compute and decompression and file reads). > > Bug: b/275102061 > Change-Id: I7fae20f5b75f3239305e2094a992e3040b8c8e4c > Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4754133 > Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> > Commit-Queue: Charlie Lao <cclao@google.com> Bug: b/275102061 Change-Id: Id344e306307553731097f06edafc40bfeb73ff80 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4780494 Reviewed-by: Geoff Lang <geofflang@chromium.org> Commit-Queue: Geoff Lang <geofflang@chromium.org>
Charlie Lao 152cf62b 2023-08-15T13:43:12 Tightly pack LinkedUniform by using int16_t There is a check of vector size when we link uniforms and the maximum vector size is 4096 due to we clamp the maxUniformBlockSize to 64KB. In reality, if we exceeds this number, program link will take really long time and then hit failure. So there is no real need to keep all the variables in 32 bit integer. This CL changes to 16 bit integer. Further, sh::BlockMemberInfo and ActiveVariable data members are embeded into LinkedUniform struct as well so that the unused variables can be removed and data can be tightly packed. This also makes LinkedUniform easier to maintain as a simple struct with basic data types. With this change, LinkedUniform size is reduced from 108 bytes down to 60 bytes, 48 bytes reduction. Given some apps has 200-ish uniforms, this CL reduces 48 bytes x 200 = ~9K memory just for uniforms per program (which goes through hash compute and decompression and file reads). Bug: b/275102061 Change-Id: I7fae20f5b75f3239305e2094a992e3040b8c8e4c Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4754133 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com>
Charlie Lao 719165c8 2023-08-04T12:13:37 Remove "const UniformTypeInfo *typeInfo" from struct LinkedUniform This is a cached pointer to the const kInfoTable. There isn't much of performance benefit to cache here compare to directly retrieve from the table. This cached pointer is removed in this CL, which means we do not need to update the pointer in the ProgramExecutable::load(). This and a few earlier CLs that attempt to do memcpy for entire mUniforms reduced average frame time of blade_and_soul_revolution app trace 3%, from 4.3359 ms to 4.2066ms on pixel 7 pro. Bug: b/275102061 Change-Id: I6fd34d665234e3a5cc85344924049bf5b13aaa80 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4753933 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Charlie Lao d1117834 2023-08-04T10:48:22 Simplify struct LinkedUniform a bit more In earlier CL crrev.com/c/4740298, we added mFixedSizedData structure to group the data memebrs that can be memcpy-able into one variable, so that we can memcpy that. Since then, we have made entire LinkedUniform struct memcpy-able (crrev.com/c/4750443 is doing memcpy of entire std::vector<LinkedUniform>). Thus, there is no longer a need for mFixedSizedData. This CL removes that. This CL also removes isStruct and inArrayOfArrays from LinkedUniform, since they are always false. This CL also removes some unused APIs from LinkedUniform. Bug: b/275102061 Change-Id: I6ead3d8f179efc0d383352f7ac0efa6bf3dc8a1b Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4753932 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Yuxin Hu <yuxinhu@google.com> Commit-Queue: Charlie Lao <cclao@google.com>
Charlie Lao 41d27ec3 2023-08-03T18:06:08 load/save entire std::vector<LinkedUniform> with one call. Now LinkedUniform is a simple data struct with only fundamental types, we can load the entire vector at once. Bug: b/275102061 Change-Id: I7c030677d02517f86d960de85b0e7ae2c916a26e Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4750443 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Yuxin Hu <yuxinhu@google.com> Commit-Queue: Charlie Lao <cclao@google.com>
Charlie Lao 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>
Charlie Lao 9c588180 2023-08-02T16:39:44 Change LinkedUniform::arraySizes from std::vector to unsigned int We always flatten multiple dimensional arrays in the uniform to a one dimensional array, so the arraySizes can be simplified to unsigned int instead of a vector. With this, we can now move the arraySize into the simple mFixedSizeData struct and the normal memcpy will cover the load/save. Bug: b/275102061 Change-Id: I24c026f783b755f7aa691a5db5746b6309a21227 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4735275 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Yuxin Hu <yuxinhu@google.com> Commit-Queue: Charlie Lao <cclao@google.com>
Charlie Lao 22438ad8 2023-08-02T14:01:45 Embed ActiveVariable into BufferVariable and ShaderVariableBuffer This CL embeds ActiveVariable into BufferVariable and ShaderVariableBuffer struct instead of subclass. This allows us to remove the virtual function of ~ActiveVariable(), which means ActiveVariable is a simple struct with basic types and memcpy can be used for load/save. Thus, in this CL, I also moved activeVariables to LinkedUniform::mFixedSizeData structure and let memcpy handle the load/save. Bug: b/275102061 Change-Id: I8d21080cfdd72d4d22cef927d136ca428d9b12e4 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4722265 Reviewed-by: Roman Lavrov <romanl@google.com> Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Charlie Lao ee019f58 2023-08-01T17:03:24 Group fixed sized data of LinkedUniform into a struct Most of gl::LinkedUniform struct is a basic types and can be simply initialized with memcpy. This CL groups these together and encapsulate them with get APIs. The load/save is now a single memcpy for the entire fixed size data structure of basic types. Bug: b/275102061 Change-Id: I49120c06ec941c783790ac0ecb0ee314a4234b26 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4740298 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Roman Lavrov <romanl@google.com> Commit-Queue: Charlie Lao <cclao@google.com>
Charlie Lao 7bb13226 2023-08-01T12:10:44 Pack booleans inside struct LinkedUniform into bitfields Right now every bool is load/stored as integer, which itself is a memcpy. This CL moves them into a bitfield and load/store with one uint32_t, thus improves efficiency of cache load/save. Bug: b/275102061 Bug: angleproject:8223 Change-Id: Id8e8e8861c8fcbd75dbef6056e4ff6c8ad2fc4a1 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4740292 Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Roman Lavrov <romanl@google.com>
Charlie Lao 79973750 2023-07-27T17:53:24 Let UniformLinker uses its own struct instead of LinkedUniform UniformLinker itself needs more detailed information than the final linked uniforms. Right now they are using the same data structure. This CL adds a new structure for linker to use. Since the linker data structure is temporary, we never needs to load/save from cache, we have more freedom here to use complex data types. The benefit of separate out intermediate structure from LinkedUniform is that it allows us to further simplify LinkedUniform structure without change much of ProgramLinkedResource implementation. As result of this, this CL removes field and outerArraySizes (both are std::vector type) from LinkedUniform. Bug: b/275102061 Change-Id: Ic1291b51b8906ac586a2f25eb1dbbe74eae8fdc5 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4727742 Reviewed-by: Roman Lavrov <romanl@google.com> Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Charlie Lao f24ea41e 2023-07-31T11:12:44 Embed sh::ShaderVariable data member into gl::LinkedUniform ProgramExecutable::load and save function is load/save each individual data members. Uniform can be quite large as shown in some app traces and this causes performance problem even when program memory has a cache hit. This CL flattens gl::LinkedUniform structure by embedding sh::ShaderVariable data members so that we can remove unrelated members and also prepare for further optimization in future CLs. Bug: b/275102061 Change-Id: I7c18cb73e359fba7cd6375b4b1635e9040ef140d Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4735152 Reviewed-by: Roman Lavrov <romanl@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com>
Charlie Lao 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>
Shahbaz Youssefi c1ba8e6f 2023-06-20T16:03:20 Vulkan: Flatten shader interface variable maps This change removes duplicate entries added in the shader shader interface variable maps. One level of arrayness (indexed by shader type) is removed from these maps as now there is only a single entry per linked resource/etc. Bug: angleproject:7220 Change-Id: Ibf2d06a0e1f68e68797c2066f36e14cb9e667f77 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4628677 Reviewed-by: Yuxin Hu <yuxinhu@google.com> Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi 24f4007b 2023-06-08T00:41:55 Vulkan: Use SPIR-V ids instead of names in the transformer This change removes the SPIR-V transformer's reliance on type and variable names. As a result: - String hashing is removed from the info map data structure and the SPIR-V transformer - The ID discovery class is entirely removed - Internal variable names have become a detail of the compiler alone (and are no longer exposed as part of the compiler interface) - Some front-end name tracking is removed ("parentStructMappedName", etc) This change also properly cleans up xfb emulation types that were previously left over. This change allows the SPIR-V compiler to emit user strings as-is instead of prefixing them with `u_` leading to more readable debug shaders. Additionally, it will make it possible not to emit debug info at all. Both of these changes will be done in follow ups. Bug: angleproject:7220 Change-Id: Iaa127496209a27aaae2e0d14c41b22fffb0b72a2 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4600610 Reviewed-by: Roman Lavrov <romanl@google.com> Reviewed-by: Yuxin Hu <yuxinhu@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Alexey Knyazev 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>
Eddie Hatfield 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>
Shahbaz Youssefi 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>
Brandon Schade 5911243c 2022-07-06T15:55:28 Fix linkValidateTransformFeedback for glLinkProgram From OpneGLES 3.2 spec. 11.1.2.1: A program will fail to link if the count specified by TransformFeedbackVaryings is non-zero, but the program object has no vertex, tessellation evaluation, or geometry shader. Add check in validation to account for this. Bug: angleproject:5557 Tests: ProgramPipelineTest32.CreateProgramWithTransformFeedbackVarying Change-Id: Ia86cbe8e85cb6a69fd35ddc4bc6ee37b9500c78f Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3723861 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Mohan Maiya 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>
Amirali Abdolrashidi 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>
Geoff Lang 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>
Shahbaz Youssefi 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>
Jamie Madill 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>
Jamie Madill 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>
Shahbaz Youssefi 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>
Yuxin Hu 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>
Jamie Madill dd86dd15 2022-03-25T14:55:05 Cache outer array offset in linked uniforms. Our current tracking would only track one array dimension. For nested arrays the flattened parent index would be incorrect. Update this tracking so we can use it in the Vulkan descriptor set caching. Store this value as a separate integer member to avoid conflicting with other back-ends. Bug: angleproject:6776 Change-Id: Ie1a5dc3d64ccac23dffcc73684d619336cb0f0da Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3550824 Reviewed-by: Yuxin Hu <yuxinhu@google.com> Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Jamie Madill <jmadill@chromium.org>
Jamie Madill 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>
Jamie Madill 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>
Jamie Madill 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>
Yuly Novikov 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>
Jamie Madill 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>
Jamie Madill 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>
Jamie Madill 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>
Jamie Madill 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>
Lingfeng Yang 6d3435fd 2021-12-01T17:08:01 Validate SamplerFormat We weren't validating sampler formats in ProgramExecutable validation. Bug: chromium:1273661 Change-Id: Ida0c67c0c7169ea3f47ceb2d433bee17012a7e5e Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3312717 Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Lingfeng Yang <lfy@google.com>
Jamie Madill 019ddad5 2021-11-04T13:22:47 Reset cache in ProgramExecutable::updateActiveSamplers. This missing reset was causing incorrect state validation to persist in a few instances. Bug: chromium:1266437 Change-Id: I7ab47c81bf9f855e3ad75048f9d1aaefbc2291df Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3262477 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Jamie Madill <jmadill@chromium.org>
Jamie Madill 4a2446c6 2021-10-19T11:55:17 Vulkan: Implement robust shader outputs. In this CL we change ANGLE to pass the mask of missing shader outputs down to pipeline creation. We then use the color mask bits to block SwiftShader writing to unused outputs. This fixes the undefined behaviour present in Genshin Impact. Note that the other GLES implementations we tested don't seem to modify outputs even if they're unused. It was easier to mask out the color attachments in initialize rather than set up the pipeline desc to mask out the attachments. This was because we manipulate the color mask in a fairly complex way before we initialize the pipeline desc. Bug: angleproject:6566 Change-Id: Ie659fcd511cd286fa573fd25e3e6a0b9e123ebd6 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3232435 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com>
Jamie Madill 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>
Jamie Madill 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>
Jamie Madill 1ca1589f 2021-09-13T10:56:58 Give GLES extension bools a vendor suffix. This is in preparation for auto-generation which will give all of these bools suffixes. Bug: angleproject:6379 Change-Id: I7e3f6c9b644c41a2165e6bf7b62d661fd352a250 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3158503 Reviewed-by: Jonah Ryan-Davis <jonahr@google.com> Reviewed-by: Cody Northrop <cnorthrop@google.com> Commit-Queue: Jamie Madill <jmadill@chromium.org>
Brandon Schade 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>
Brandon Schade 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>
Brandon Schade 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>
Mohan Maiya 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>
Tim Van Patten 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>
Tim Van Patten 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>
Tim Van Patten 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>
kmx.io     mail     discord kmxgit v0.4.0