kc3-lang/angle/src/libANGLE/Program.h

src/libANGLE/Program.h

Log

Author Commit Date CI Message
Roman Lavrov df90bbc5 2024-07-12T18:04:53 Refactoring: move angle::HashMap and HashSet to own header Underlying abseil includes pull in a large set of headers Bug: angleproject:42266508 Change-Id: Icee47143a8a59bb0795a054b67c0aa4ddcfca4d4 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5704137 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Igor Nazarov c41cbb3d 2024-06-03T18:59:27 Fix binary is not cached after isBinaryReady() is true Backend may wait and clear `mPostLinkSubTasks`. The `isBinaryReady()` will check, that there are no tasks, and will skip the caching. This change renamed `cacheProgramBinaryIfNotAlready()` to more general `cacheProgramBinaryIfNecessary()`, because it skips caching if there are post link tasks. The `cacheProgramBinary()` renamed to `cacheProgramBinaryIfNotAlready()`, to better reflect it's behavior. Call `cacheProgramBinaryIfNotAlready()` from `isBinaryReady()` if there no post link tasks to ensure binary is cached. Removed check for empty `mPostLinkSubTasks` before calling executable's wait, because same check already performed internally. The `waitForPostLinkTasks()` is not on hot path and does not require avoiding no-op method call. Bug: angleproject:8297 Change-Id: I2bd78c15231805cda4b62a9889287d8cf780cd1e Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5593928 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
Shahbaz Youssefi c3a1cae4 2024-04-15T14:58:55 Use angle::SimpleMutex everywhere in libGLESv2 Only cases left that use std::mutex are: - Share group and the context ErrorSet mutexes as they need try_lock() - Anywhere mutexes are used in conjunction with std::condition_variables (as they explicitly require std::mutex) Bug: angleproject:8667 Change-Id: Ib6d68938b0886f9e7c43e023162557990ecfb300 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5453294 Reviewed-by: Roman Lavrov <romanl@google.com> Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi f4d3041a 2024-04-13T22:37:11 Remove double-serialization for glGetProgramBinary The applications get the binary length first, and then get the binary itself. Prior to this change, ANGLE was serializing the program binary twice. What's more, if the blob cache is enabled, ANGLE serialized the program binary yet another time for that. With this change, the program binary is serialized only once. If the application queries the program binary, serialization is done the first time needed, is cached and then discarded as soon as the binary itself is returned. Bug: angleproject:7393 Change-Id: If6e3011097ca4d4a1cdcd2dcc23496901196d999 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5448090 Reviewed-by: Geoff Lang <geofflang@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi 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>
Shahbaz Youssefi e41286e1 2024-04-10T11:05:09 Vulkan: Fix internal caching missing Since the backend wait for post-link tasks was made possible [1], the front-end may never get a chance to internally cache its binary. This is because the decision to cache the binary was based on the existence of post-link tasks, and the backend clearing that list made the front-end confused. In this change, a specific bool tracks whether binary is cached, and that is checked at various times to make sure the binary cache is eventually done. [1]:https://chromium-review.googlesource.com/c/angle/angle/+/5427001 Bug: angleproject:8297 Change-Id: Iceefd0bca79d570d4910983be3660d6e725684a0 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5445484 Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: mohan maiya <m.maiya@samsung.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi d9943e44 2024-04-09T23:53:48 Remove Program::syncState The last bit of responsibility still left in Program::syncState was to wait for post-link tasks for the sake of EGLBlobCacheTest tests. A new extension, GL_ANGLE_program_binary_readiness_query is created so that the wait can be done in the test itself. This extension is ultimately useful for applications as well, so they can avoid blocking the CPU by calling glGetProgramBinary prematurely. Bug: angleproject:8297 Change-Id: Ied6b755cb9b060198f82c7948bfd03441435a578 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5440302 Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: mohan maiya <m.maiya@samsung.com> Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Charlie Lao <cclao@google.com>
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 58ecad7a 2024-04-03T23:12:05 Remove assertion that program is not linking when bound/unbound It's valid to link a program, let it happen in parallel and in the meantime bind and unbind the program in other contexts. The add/release ref functions were asserting that link is resolved, which is not true in that case. Bug: angleproject:8647 Change-Id: I784b5adbb04f062752a873deb1e7a4aaf4527e33 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5420990 Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Geoff Lang <geofflang@chromium.org> Commit-Queue: Geoff Lang <geofflang@chromium.org>
Mohan Maiya ee02014d 2024-03-22T11:52:35 Selectively wait for LinkSubTasks Backends have the option to request frontend to run their LinkSubTask post-link. Do not wait for such sub tasks during most glProgram APIs. Note that we do wait for these "post-link sub tasks" incase of a program relink or first use by a draw call. Bug: angleproject:8297 Change-Id: I936fb5a127570f9dfa567ee8cbc02e25c4b70a6b Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5387064 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi ad013650 2024-03-22T03:42:44 Revert "Rename LinkSubTask -> PostLinkTask" This reverts commit 00eb6edba074a22389b09990ab856adfd417dd64. Reason for revert: Sub tasks are not actually post-link tasks for all the other backends (other than Vulkan), but they are a real part of the link job. Original change's description: > Rename LinkSubTask -> PostLinkTask > > This is a renaming change, no behavior changes are expected. > > Bug: angleproject:8297 > Change-Id: I734c7959f5ed6db2447853cc6f6256e3c8e86213 > Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5382224 > Commit-Queue: mohan maiya <m.maiya@samsung.com> > Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> > Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Bug: angleproject:8297 Change-Id: Iaebf9d165d810344bfc524042206ca427d270034 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5386432 Reviewed-by: Shahbaz Youssefi <syoussefi@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Mohan Maiya 00eb6edb 2024-03-20T06:49:38 Rename LinkSubTask -> PostLinkTask This is a renaming change, no behavior changes are expected. Bug: angleproject:8297 Change-Id: I734c7959f5ed6db2447853cc6f6256e3c8e86213 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5382224 Commit-Queue: mohan maiya <m.maiya@samsung.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> 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 b007c74d 2024-01-23T14:17:54 GL: Separate dirty bits leading to glUniformBlockBinding The GL backend is special in that it needs to make actual calls (native glUniformBlockBinding) in response to (application) glUniformBlockBinding calls. The other backends just remap the bindings based on that information when creating descriptor sets. Previously, an optimization to track which bindings have changed used the same dirty bits that were used to signify when the GL backend needs to make these native calls. That ended up as a source of bugs. In a previous change [1], the context DIRTY_BIT_UNIFORM_BUFFER_BINDINGS is set when these mappings change, which fixes some of these issues. That change obviates the need for an actual backend sync of programs, except for GL programs that need to make these native calls. This change splits the dirty bits maintained for the purposes of the GL backend, moves them to that backend and removes the program backend sync. [1]: https://chromium-review.googlesource.com/c/angle/angle/+/5228599 Bug: angleproject:8493 Bug: b/318806125 Change-Id: I73c6514e88a116f1cd701cb06da0d8c38f07f7f6 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5230137 Reviewed-by: Geoff Lang <geofflang@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi 572323cc 2024-01-11T16:20:02 Fix program link after backend rejects program binary If ANGLE believes the program binary is fine, it populates the program executable. If the backend then rejects the program binary, the executable was not reset. After the rejection, ANGLE proceeds to redo the program link, in which case it fails in various ways (ASSERT failures, incorrect data etc) as it tries to accumulate info on top of the previous executable. Bug: angleproject:8471 Change-Id: Ia4d626f5f9643c39a81062da3d5d58aa4c6be762 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5189152 Reviewed-by: Quyen Le <lehoangquyen@chromium.org> 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>
Shahbaz Youssefi 4bf40237 2023-12-18T15:24:15 GL: Fix missing glUniformBlockBinding handling When a program is current and this call is made, the program is made dirty so that the GL backend reacts to this call. Prior to https://chromium-review.googlesource.com/c/angle/angle/+/4922969, the program was made dirty when its executable was installed as well (if it had any UBOs dirty), but that change removed it. As a result, if this call was made while the program was _not_ current, the GL backend would miss processing it. This call ensures that the appropriate dirty bit is set when the program is made current again. This revealed a bug in the Vulkan backend where sometimes the executable's dirty bits would not get reset. This was benign but fired an assertion, and is fixed in this CL as well. Bug: chromium:1511506 Change-Id: Iae86ba0aa5b8f9e4f20dd6df6002d37e405280e7 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5123005 Reviewed-by: Cody Northrop <cnorthrop@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com>
Shahbaz Youssefi 3680a5dc 2023-11-17T13:51:07 Vulkan: Let program warmup continue passed link The warmup task does not actually affect the link results, so there is no reason to wait for it when the application queries the link status. This change allows the warm up task to continue in parallel until the program is used at draw time. This allows the warm up to be more efficient when the link itself is not parallelized. For applications that create programs in the middle of every frame, it's still likely best to disable warm up (as the following immediate draw will already effectively do the warm up). Note that currently the warm up code in the Vulkan backend is not completely thread-safe, and so the program still blocks on that task before the first draw can happen (or the program is modified in any way). Bug: angleproject:8417 Change-Id: I0877fef39a0585c3279e32699ce817d4643d7cd6 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5037538 Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Geoff Lang <geofflang@chromium.org>
Shahbaz Youssefi dd8432b5 2023-11-14T14:39:45 Remove angle::Result::Incomplete from shader/program paths angle::Result is not an error code, and having Incomplete made it very unclear what the purpose of this class is. A follow up will remove it entirely. Bug: angleproject:8414 Change-Id: Ica8271b9f7d8868671c7658161e50a53ef23c681 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5028091 Reviewed-by: Geoff Lang <geofflang@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi ade3dacd 2023-11-06T21:56:41 Do compile/link unlocked if not threaded (but thread-safe) If GL_KHR_parallel_shader_compile is not supported, or it is not used to do threaded compilation and link, this change lets the compile and link jobs be done after releasing the share group lock. With multithreaded/multi-context applications, this allows the other context (typically the main context) to make progress in the meantime. A typical scenario where this optimization matters is games seamlessly loading a new area of the game and performing compilation and link in a separate context. Before this change, the game would stutter as the compile/link jobs prevent the main thread from drawing anything. With this change, the hitching is removed. Bug: angleproject:8297 Change-Id: I702d84324a7442561b49677bf42c16d650304313 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5006640 Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Geoff Lang <geofflang@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi 93b97a59 2023-11-03T22:07:23 Make link job directly wait on compile job Previously, program link waited on the compile job on the calling thread before launching the link job. As a result, sequences of intermixed compile and link would get largely serialized as such: Main Thread Thread 1 Thread 2 Thread 3 Thread 4 Compile -------> Compile Compile -----------|----------> Compile Link | | Wait | | | | | |<--------------/--------------/ \------------------------------------------> Link Compile -------> Compile | Compile -----------|----------> Compile | Link | | | Wait | | | | | | | |<--------------/--------------/ | \---------------------------------------------|-----------> Link Compile -------> Compile | | Compile -----------|----------> Compile | | Link | | | | Wait | | | | | | | | | ... With this change, the main thread no longer waits for compilation to finish. It's the link job itself that does the waiting. This allows the main thread to go through Compile and Link commands without blocking, generating as many jobs as needed. The above scenario therefore becomes: Main T1 T2 T3 T4 T5 T6 T7 T8 T9 C ----> C C ------|----> C L ------|------|----> L C ------|------|-------W---> C C ------|------|-------|-----|----> C L ------|------|-------|-----|------|----> L C ------|------|-------|-----|------|-------W---> C C ------|------|-------|-----|------|-------|-----|----> C L ------|------|-------|-----|------|-------|-----|------|----> L . \-----\------>/ | | | | | W . | \-----\------>/ | | | . | | \-----\------>/ . | | | . | | | This greatly improves the amount of parallelism compile and link jobs get. The careful observer may note that the link job being blocked on the compile job is now wasting a thread from the thread pool. While this change is strictly an improvement, parallelism can be further improved if the link job is just not assigned to a thread until the corresponding compile jobs are finished. This is currently not possible, but may be if: - Instead of a thread pool, the operating system's FIFO scheduler is used. Then the operating system would automatically put blocking tasks to sleep and pick up another task. This has the downside of requiring threads to be created for each task. - The thread pool work scheduler is enhanced to be made aware of relationship between tasks and avoid scheduling jobs whose dependencies are not yet met. Alternatively, the number of threads in the pool can be increased by 30% and hope for the best. Bug: angleproject:8297 Change-Id: If4e6540ade47558a10cfab55e2286f073b904928 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5006874 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Geoff Lang <geofflang@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com>
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 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 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>
Shahbaz Youssefi 68bfa1ed 2023-08-22T22:02:15 Support for link to be entirely parallelized The link job is split as such: - Front-end link - Back-end link - Independent back-end link subtasks (typically native driver compile jobs) - Post-link finalization Each step depends on the previous. These steps are executed as such: 1. Program::link calls into ProgramImpl::link - ProgramImpl::link runs whatever needs the Context, such as releasing resources - ProgramImpl::link returns a LinkTask 2. Program::link implements a closure that calls the front-end link and passes the results to the backend's LinkTask. 3. The LinkTask potentially returns a set of LinkSubTasks to be scheduled by the worker pool 4. Once the link is resolved, the post-link finalization is run In the above, steps 1 and 4 are done under the share group lock. Steps 2 and 3 can be done in threads or without holding the share group lock if the backend supports it. Step 2 is not yet made independent of the Context on some backends, and a frontend feature is used to make that step either run on the main thread or as a worker thread. Bug: angleproject:8297 Change-Id: I12f1e6bbaf365543dfcac969e166e0b5aa622104 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4808191 Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Geoff Lang <geofflang@chromium.org> Reviewed-by: Shahbaz Youssefi <syoussefi@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
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 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 33be2590 2023-08-30T21:58:54 Move transform feedback buffer mode to program state This is link input and should persist between relinks. A copy of it is still left in ProgramExecutable as it is used later after the executable is installed (and the program might get relinked; a future change reworks things so that the installed executable and the originating program are independent). Bug: angleproject:8297 Change-Id: Ifba6ac18ea09fd804b89d8fdb14930ef3d839cf4 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4827764 Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Yuxin Hu <yuxinhu@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
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 b9e9c58b 2023-08-28T15:25:59 Move pre-link program state to ProgramState Bug: angleproject:8297 Change-Id: I2522bbe6250a0527112fc8161f62c94f2457555b Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4817828 Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
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>
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 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 8f64b51d 2023-08-09T16:51:13 Reland: Vulkan: Move default uniform init to link job This is a reland of d8cd4dcdc9c55c88f030f7fca41357e99e600ed2 Bug: angleproject:8297 Change-Id: Ib4f8e9dd258da71d44983bbb619b6b4abda0b109 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4793218 Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Yuxin Hu <yuxinhu@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
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 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>
Shahbaz Youssefi 4ba4af61 2023-08-17T11:28:18 Revert recompile blocking on link Causing timeouts on some platforms. An alternative implementation will follow. This change also reverts two changes that depend on it: Vulkan: Move SPIR-V set up to link job 10f54902e816fa7e4cf314384e00590e2b9bfa1d. Vulkan: Move default uniform init to link job d8cd4dcdc9c55c88f030f7fca41357e99e600ed2. Bug: angleproject:8297 Change-Id: I9a258460e7bcaeac214be5e63c16c20681e0bcde Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4789843 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Yuly Novikov <ynovikov@chromium.org>
Shahbaz Youssefi d8cd4dcd 2023-08-09T16:51:13 Vulkan: Move default uniform init to link job Bug: angleproject:8297 Change-Id: I5bab916f452439d92afa65b9172574000ee0b587 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4762838 Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Shahbaz Youssefi 424f43e4 2023-08-11T17:07:16 Prevent shaders from recompiling while a link job is in progress This will prevent a guarantee that link jobs can take further advantage of. In particular, a good chunk of the link job is done serially and under the share group lock due to this recompile-while-link issue. After this change, that is no longer a problem, and most of the link can be made lockless/parallelized. Bug: angleproject:8297 Change-Id: Ic41ac62fb8c40131a69cd90fa9430584964677fa Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4776338 Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Geoff Lang <geofflang@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
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 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>
Alexey Knyazev b57d5638 2023-06-29T00:00:00 Reland "Cleanup multiview support" This is a reland of commit 9a7c0b88ba68e328d3f5f7991a6df0ab5de92311 Original change's description: > Cleanup multiview support > > * Removed remaining mentions of ANGLE_multiview > > * Removed AST transformations used only in > the side-by-side multiview implementation > > * Changed the type of the internal ViewID_OVR > variable to use the dedicated qualifier > > * Removed side-by-side multiview support > from the D3D11 renderer > > * Removed an unused helper for side-by-side > multiview support from the OpenGL renderer > > * Removed obsoleted test suppressions Fixed: angleproject:3341 Change-Id: I3ce9304c79c0873462c73e8cf02b85f7a1aaf874 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4669604 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Alexey Knyazev <lexa.knyazev@gmail.com>
Shahbaz Youssefi f0deadab 2023-07-06T15:19:03 Revert "Cleanup multiview support" This reverts commit 9a7c0b88ba68e328d3f5f7991a6df0ab5de92311. Reason for revert: Suspected cause of crash on Canary Original change's description: > Cleanup multiview support > > * Removed remaining mentions of ANGLE_multiview > > * Removed AST transformations used only in > the side-by-side multiview implementation > > * Changed the type of the internal ViewID_OVR > variable to use the dedicated qualifier > > * Removed side-by-side multiview support > from the D3D11 renderer > > * Removed an unused helper for side-by-side > multiview support from the OpenGL renderer > > * Removed obsoleted test suppressions > > Fixed: angleproject:3341 > Change-Id: I5e0706cbf26ea820b51400124ddbf2624b738f17 > Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4660046 > Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> > Commit-Queue: Alexey Knyazev <lexa.knyazev@gmail.com> Bug: chromium:1462504 Bug: chromium:1462505 Bug: chromium:1462506 Bug: chromium:1462478 Bug: chromium:1462531 Change-Id: Ie0e76b1c6823db19f68bb67fdfc8abc00cc62f88 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4666209 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Alexey Knyazev 9a7c0b88 2023-06-29T00:00:00 Cleanup multiview support * Removed remaining mentions of ANGLE_multiview * Removed AST transformations used only in the side-by-side multiview implementation * Changed the type of the internal ViewID_OVR variable to use the dedicated qualifier * Removed side-by-side multiview support from the D3D11 renderer * Removed an unused helper for side-by-side multiview support from the OpenGL renderer * Removed obsoleted test suppressions Fixed: angleproject:3341 Change-Id: I5e0706cbf26ea820b51400124ddbf2624b738f17 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4660046 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Alexey Knyazev <lexa.knyazev@gmail.com>
Charlie Lao 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>
Geoff Lang be5e767e 2023-02-01T11:03:26 dump_shader_source: Also dump program links. When the dump_shader_source is enabled, dump a small file for each program link containing which shaders were attached to the program. This allows us to build perf tests knowing which shaders can link together. Bug: angleproject:7760, chromium:1385510 Change-Id: I0713e9f04cc157c3a3eeeec6d597db27b08575d1 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4214011 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Cody Northrop <cnorthrop@google.com> Commit-Queue: Geoff Lang <geofflang@chromium.org>
Mohan Maiya cc34aa73 2022-12-19T14:03:27 Move BinaryStream to common and expose ShaderState to compiler This is a refactor change in preparation for adding support for glShaderBinary. Move BinaryStream to common so that it is accessible by both libANGLE and the Compiler. Extract members that hold the result of compilation from ShaderState and move into new CompiledShaderState struct. Move helper functions & classes relevant to ShaderVar serialization to the CompiledShaderState header. Tests: EGLBlobCacheTest* Bug: angleproject:7833 Change-Id: I7ec575247eccb3afbc6ab6bfa24d36e69d4576f5 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4080998 Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: mohan maiya <m.maiya@samsung.com>
Charlie Lao b19d17b8 2022-12-09T14:38:08 Vulkan: Split Serial class into UniqueSerial and Serial This CL splits Serial class into two classes: UniqueSerial and Serial. UniqueSerial supports the object unique serial usage where there is == and != operator but no > or < comparison. UniqueSerial can have invalid value, but Serial will not have invalid value (in next CL). The main reason is for next CL we can further optimize out the invalid value check in the QueueSerial comparison. Bug: b/262047600 Change-Id: Ieaed2a0d5546b012a6d63aa18b6006595e4aee1b Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4093557 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Eddie Hatfield 955adb77 2022-08-12T10:14:48 Cache compiled shader By storing the compiled shader in the blob cache, the time to recompile the same shader is reduced. Based on work by <hckim.kim@samsung.com> Bug: angleproject:7036 Change-Id: I884ae40e715c49a9ccd12903012e8327811e3557 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3808235 Commit-Queue: Cody Northrop <cnorthrop@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Cody Northrop <cnorthrop@google.com>
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>
Mark Lobodzinski 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>
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>
Shahbaz Youssefi 3ddb21fd 2022-02-23T14:15:48 Front-end support for KHR_blend_equation_advanced Bug: angleproject:3586 Change-Id: I27086295e7455ce8848db1c6004917fea40202e8 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3484785 Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Jamie Madill b2d55742 2022-01-21T12:28:32 Program: Add generic uniform update methods. This will make it easier to make central changes to all the update methods. Otherwise we'd have to replicate changes in each separate member. Bug: angleproject:3570 Change-Id: Ia765720507642338d6e9777b7e38fb323800359b Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3407734 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com> Commit-Queue: Jamie Madill <jmadill@chromium.org>
Jamie Madill 892511fc 2022-01-05T17:35:30 Isolate LinkValidateProgramInterfaceBlocks. This moves the function to a common place, similar to other "LinkValidate" functions. Refactoring change only. Bug: angleproject:3570 Change-Id: Ib94d7961d919308d29680e7e28bdbca1f08b93f0 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3373161 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>
Yuly Novikov f64f9546 2021-12-07T20:17:32 Reland "Decouple gl_BaseVertex/gl_BaseInstance uniforms" This reverts commit 10e5f34d1439f0bcd5b30bea5bfbf6bdaafd4935. Reason for revert: exonerated from flaky crash suspect Original change's description: > Revert "Decouple gl_BaseVertex/gl_BaseInstance uniforms" > > This reverts commit 36bf1ebe5e9500704dd235254bd22a1f2bbd7059. > > Reason for revert: suspect causing flaky crashes > > Bug: angleproject:6763 > > Original change's description: > > Decouple gl_BaseVertex/gl_BaseInstance uniforms > > > > These are builtin uniforms removed in > > https://github.com/KhronosGroup/WebGL/pull/3278 > > > > Decouple them from the original ANGLE_base_vertex_base_instance > > extension. > > > > Make a new ANGLE_base_vertex_base_instance_shader_builtin > > extension for these builtin uniforms. > > > > Bug: angleproject:3402 > > Change-Id: I77b93917976ce435db9c578c0ade37bff18a42b0 > > Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3290304 > > Commit-Queue: Shrek Shao <shrekshao@google.com> > > Reviewed-by: Geoff Lang <geofflang@chromium.org> > > Reviewed-by: Kenneth Russell <kbr@chromium.org> > > Bug: angleproject:3402 > Change-Id: I75830baa14cf4e7c53750fd14ff76501145b4823 > Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3315610 > Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> > Reviewed-by: Yuly Novikov <ynovikov@chromium.org> > Reviewed-by: Kenneth Russell <kbr@chromium.org> > Commit-Queue: Shrek Shao <shrekshao@google.com> Bug: angleproject:6763 Bug: angleproject:3402 Change-Id: Ie436dc5d55364e464897d407a53b793941cd5d0b Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3321703 Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Yuly Novikov <ynovikov@chromium.org>
Shrek Shao 10e5f34d 2021-12-04T00:10:21 Revert "Decouple gl_BaseVertex/gl_BaseInstance uniforms" This reverts commit 36bf1ebe5e9500704dd235254bd22a1f2bbd7059. Reason for revert: suspect causing flaky crashes Bug: angleproject:6763 Original change's description: > Decouple gl_BaseVertex/gl_BaseInstance uniforms > > These are builtin uniforms removed in > https://github.com/KhronosGroup/WebGL/pull/3278 > > Decouple them from the original ANGLE_base_vertex_base_instance > extension. > > Make a new ANGLE_base_vertex_base_instance_shader_builtin > extension for these builtin uniforms. > > Bug: angleproject:3402 > Change-Id: I77b93917976ce435db9c578c0ade37bff18a42b0 > Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3290304 > Commit-Queue: Shrek Shao <shrekshao@google.com> > Reviewed-by: Geoff Lang <geofflang@chromium.org> > Reviewed-by: Kenneth Russell <kbr@chromium.org> Bug: angleproject:3402 Change-Id: I75830baa14cf4e7c53750fd14ff76501145b4823 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3315610 Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Reviewed-by: Yuly Novikov <ynovikov@chromium.org> Reviewed-by: Kenneth Russell <kbr@chromium.org> Commit-Queue: Shrek Shao <shrekshao@google.com>
Shrek Shao 36bf1ebe 2021-11-17T13:31:17 Decouple gl_BaseVertex/gl_BaseInstance uniforms These are builtin uniforms removed in https://github.com/KhronosGroup/WebGL/pull/3278 Decouple them from the original ANGLE_base_vertex_base_instance extension. Make a new ANGLE_base_vertex_base_instance_shader_builtin extension for these builtin uniforms. Bug: angleproject:3402 Change-Id: I77b93917976ce435db9c578c0ade37bff18a42b0 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3290304 Commit-Queue: Shrek Shao <shrekshao@google.com> Reviewed-by: Geoff Lang <geofflang@chromium.org> Reviewed-by: Kenneth Russell <kbr@chromium.org>
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>
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>
Geoff Lang f97b8193 2021-05-12T12:28:57 Make ANGLE's program hash key deterministic. ANGLE's program hash iterates over hash maps which do not guarantee a determinisitic iteration order. Copy these maps to std::map before iteration. It's unclear what must change to make these maps iterate differently, EGLBlobCacheTest.Functional does cover this path but doesn't trigger any issues. Bug: angleproject:5913 Change-Id: Ib5f2c0a0a4e05cbaeeec5d9c889718d53c5fcf1c Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2892254 Reviewed-by: Sunny Sun <sunny.sun@arm.com> Reviewed-by: Geoff Lang <geofflang@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Geoff Lang <geofflang@chromium.org>
Jamie Madill ccc0fbaa 2021-03-24T17:56:38 Vulkan: Related fixes for buffer descriptor set cache. Includes some stats counter gathering and a few related refactors and cleanups. Also includes a new overlay widget. Bug: angleproject:5736 Change-Id: Ida8d2cd815c5b598c6a442dd9bbfdf51e9c05180 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2785431 Commit-Queue: Jamie Madill <jmadill@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Tim Van Patten <timvp@google.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 ae937aae 2021-03-19T20:10:42 Detach separable shaders This effectively reverts the following CL: Vulkan: Don't detach separable shaders in Program::detachShader() https://chromium-review.googlesource.com/c/angle/angle/+/2084399 Bug: angleproject:3570 Bug: b/182409935 Test: ProgramPipelineTest31.DetachAndModifyShader Change-Id: Id69f732d1d4f3eea70b2de8c008452878eaf1682 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2776267 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 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>
Mohan Maiya 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>
Brandon Schade 6cc845bb 2020-12-07T18:14:50 Vulkan: Add support for EXT_blend_func_extended This implementation utilizes vulkan's dualSrcBlend feature. Expose this extension if the underlying vulkan backend allows the use of this feature. Test: angle_end2end_tests --gtest_filter=EXTBlendFuncExtendedDrawTest* Bug: angleproject:5074 Change-Id: I7d2f611df89d65e5cac35158cb5f41a0ebd58aae Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2593151 Commit-Queue: Brandon Schade <b.schade@samsung.com> Commit-Queue: Mohan Maiya <m.maiya@samsung.com> Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Tim Van Patten 351e6e8c 2021-01-26T17:08:59 Add 'UniformBlockIndex' struct Add the new structure 'UniformBlockIndex'. This is in preparation for capturing glUniformBlockBinding() calls, which requires the (new) corresponding ParamType::TUniformBlockIndex. Bug: angleproject:5564 Change-Id: I88613dd96d058659dd253e8088fab49670c32316 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2651287 Commit-Queue: Tim Van Patten <timvp@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Cody Northrop <cnorthrop@google.com>
Jamie Madill b912eec5 2020-11-27T11:08:41 Vulkan: Support GL_EXT_tessellation_shader. Shader translator changes done in http://crrev.com/c/2633936 Adds a new DIRTY_BIT_PATCH_VERTICES state to Context. Supportes state query and transform feedback. 4 test suppressions remain as follow-up fixes. Adds a new varying packing mode for a simple Vulkan rule set. Based on work by Mohan Maiya (m.maiya@samsung.com). Test: dEQP-GLES31.functional.tessellation.* Bug: angleproject:3572 Change-Id: I4cad2cca30adb754fd12c83027673906541f566a Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2568234 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Mohan Maiya <m.maiya@samsung.com> Commit-Queue: Jamie Madill <jmadill@chromium.org>
Jamie Madill 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>
Jamie Madill 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>
Jamie Madill fa449cf3 2021-01-06T10:02:12 Fix separable Geometry Shaders. Was a needed fix for a new varying test. Bug: angleproject:3571 Bug: angleproject:5496 Change-Id: I49ae69967510b7a6330ea217a0e0e19e3bebe865 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2613198 Reviewed-by: Tim Van Patten <timvp@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Jamie Madill <jmadill@chromium.org>
Jamie Madill 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>
Jamie Madill 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>
Shahbaz Youssefi 282fb409 2020-12-11T16:09:10 Fix link validation of I/O block members Location and struct name matching for fields was missing as they only apply to I/O blocks and not varyings of struct type. Bug: angleproject:3580 Change-Id: I69083f39088458da72828b418be3068187a30fcc Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2587456 Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Jamie Madill f6df8692 2020-12-09T12:46:35 Vulkan: Support XFB in non-Vertex stages. This updates the code in several places to support Geometry and Tessellation Evaluation shaders to output transform feedback. Does not turn on any new tests but enables support for XFB when we turn on GS/TS. Bug: angleproject:3571 Bug: angleproject:3572 Change-Id: I6dcb768f2df4eeee81a4a500e999fcf16716f58f Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2581941 Reviewed-by: Tim Van Patten <timvp@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Jamie Madill <jmadill@chromium.org>
Tim Van Patten c859c0ac 2020-11-24T17:21:38 Batch replace std::unordered_map with angle::HashMap in src/ There are a few places that will remain std::unordered_map due to build or run-time errors, which will need to be evaluated more closely to determine if they should remain std::unordered_map or if there is another Abseil data structure that would be more efficient while still working correctly. Bug: angleproject:4873 Change-Id: Ib04253e3ad6398e63f4cc2bfe12c0f9e57cb112b Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2558873 Commit-Queue: Tim Van Patten <timvp@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com>
Charlie Lao 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>
Geoff Lang 5b419533 2020-11-03T13:33:44 GL: Implement EXT_YUV_target Add test coverage of YUV format sampling as RGB or directly as YUV and rendering as YUV using layout(yuv). Initializing YUV AHardwareBuffers requires Android API 29 so ANGLE must be compiled with: android32_ndk_api_level = 29 android64_ndk_api_level = 29 The following tests can still run with Android API 26 because they don't need to initialize the buffer: ImageTestES3.ClearYUVAHB ImageTestES3.YUVValidation Bug: angleproject:4852 Bug: b/172649538 Change-Id: I4fe9afb2a68fb827dc5a5732b213b5eb60d585ac Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2517562 Commit-Queue: Geoff Lang <geofflang@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Tim Van Patten e78d9a61 2020-07-24T11:58:45 Convert unordered_map to absl::flat_hash_map for select files This is the initial CL to start migrating to abseil in various places: - formatutils.h - FramebufferVk.h - Program.h - ProgramExecutableVk.h - RewriteRowMajorMatrices.cpp This intentionally hits a couple different places in the code to make sure the abseil dependencies are added to the required targets. Bug: angleproject:4873 Change-Id: Idd6084dff2ebce47833f304c605bbf3151b97414 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2402382 Commit-Queue: Tim Van Patten <timvp@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com>
Jamie Madill 8d412db2 2020-08-29T22:25:18 Revert "Convert unordered_map to absl::flat_hash_map for select files" This reverts commit 1acaf4eced42a26f09b4d9180a9e5db0f37bc9a4. Reason for revert: Fails when is_component_build is not set: lld-link: error: <root>: undefined symbol: public: __cdecl absl::Condition::Condition<struct std::__1::atomic<bool> const>(bool (__cdecl *)(struct std::__1::atomic<bool> const *), struct std::__1::atomic<bool> const *) <snip> Original change's description: > Convert unordered_map to absl::flat_hash_map for select files > > This is the initial CL to start migrating to abseil in various places: > - formatutils.h > - FramebufferVk.h > - Program.h > - ProgramExecutableVk.h > - RewriteRowMajorMatrices.cpp > > This intentionally hits a couple different places in the code to make > sure the abseil dependencies are added to the required targets. > > Bug: angleproject:4873 > Change-Id: I68c7d067b6912b0cc0ecde231501dbed92f0b189 > Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2321735 > Commit-Queue: Tim Van Patten <timvp@google.com> > Reviewed-by: Jamie Madill <jmadill@chromium.org> > Reviewed-by: Charlie Lao <cclao@google.com> TBR=timvp@google.com,jmadill@chromium.org,cclao@google.com Change-Id: I75041532fc5126b4c7cc5e0d4529883fb357e05b No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: angleproject:4873 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2383870 Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Jamie Madill <jmadill@chromium.org>
Tim Van Patten 1acaf4ec 2020-07-24T11:58:45 Convert unordered_map to absl::flat_hash_map for select files This is the initial CL to start migrating to abseil in various places: - formatutils.h - FramebufferVk.h - Program.h - ProgramExecutableVk.h - RewriteRowMajorMatrices.cpp This intentionally hits a couple different places in the code to make sure the abseil dependencies are added to the required targets. Bug: angleproject:4873 Change-Id: I68c7d067b6912b0cc0ecde231501dbed92f0b189 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2321735 Commit-Queue: Tim Van Patten <timvp@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com>
Tim Van Patten 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>
Manh Nguyen fba96e90 2020-07-30T10:04:59 Add shaders and programs serialization capability Serializes shaders and programs' states stored on CPU. Adds shaders and programs serialization to serializeContext method so that capture replay regresssion testing now compares the states of shaders and programs too. Bug: angleproject:4817 Change-Id: I026762ffcd85c9cf209f17d02025730aa286bd2f Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2329830 Commit-Queue: Manh Nguyen <nguyenmh@google.com> Reviewed-by: Cody Northrop <cnorthrop@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org>
Tim Van Patten 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>
Tim Van Patten 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>
Tim Van Patten a28efb2f 2020-06-12T13:14:48 Remove mProgramState from ProgramExecutable::updateActiveImages() Use of the member variable mProgramState is being removed to reduce the circular coupling of ProgramExecutable and ProgramState. Bug: angleproject:4520 Test: Build/CQ Change-Id: I31d7e607fb06a374a0b0e1d35eb2a092614badf5 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2243323 Commit-Queue: Tim Van Patten <timvp@google.com> Reviewed-by: Courtney Goeltzenleuchter <courtneygo@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org>
Tim Van Patten 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>
Tim Van Patten 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>
Tim Van Patten 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>
Tim Van Patten 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>
Rafael Cintron e8b8b816 2020-05-19T18:58:55 Eliminate Program::mLinkResolved boolean Since mLinkResolved boolean is always kept in sync with the presence of mLinkingState structure, we can remove the former and replace access with checks for the latter being nullptr. Bug: angleproject:4644 Change-Id: Ib385b5c3881946d762ad48e6534c84d15e50f673 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2209319 Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com> Commit-Queue: Rafael Cintron <rafael.cintron@microsoft.com>
Tim Van Patten d10ba166 2020-05-19T18:00:38 Rename ProgramState::getProgramExecutable() to getExecutable() The "Program" part of ProgramState::getProgramExecutable() is already implied by being part of a ProgramState, so it can be removed. Bug: angleproject:3570 Change-Id: I35ffb2af81196fa7f189f7d3a37158f5f1951141 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2209317 Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Tim Van Patten <timvp@google.com>
Tim Van Patten 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>
Tim Van Patten 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>
kmx.io     mail     discord kmxgit v0.4.0