|
d193d51b
|
2024-06-17T22:46:08
|
|
Replace issue ids post migration to new issue tracker
This change replaces anglebug.com/NNNN links.
Bug: None
Change-Id: I8ac3aec8d2a8a844b3d7b99fc0a6b2be8da31761
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5637912
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
562d4be3
|
2023-10-20T14:33:05
|
|
Clear pending program linking in Context::onDestroy
When destroying Context, ANGLE resets any internal state before
releasing allocated objects, such as Programs and Shaders. When
destroying a program, any pending program linking is resolved via
Program::resolveLink. This results in trying to access the Context state
that’s just been reset.
To work around this, we ensure there are no pending links before
resetting the Context state.
Bug: angleproject:8380
Change-Id: I599c7e5a82b0e6bf14df1263006e10d8a9cb0b38
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4957715
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Kenneth Russell <kbr@chromium.org>
|
|
|
7b0bb0f6
|
2023-09-01T13:52:28
|
|
Properly "install" program executables
According to GL:
- The program has an executable
- The executable is overwritten during link.
- After a failed link, queries of the executable may return
half-linked information
- On glUseProgram, the executable is installed in the context
- On glUseProgramStages, the executable is installed in the program
pipeline
- After a successful link, the executable is updated wherever the
previous executable of the program was installed.
This change implements exactly the above:
- The program's and the program pipeline's executables are now
shared_ptr. References to an executable in the context and PPO are
also through a shared_ptr. Installing an executable thus translates
to sharing the executable.
- The context and PPOs are made to not reference the program directly,
but work solely through the executable. As a result, the program is
free to create a new executable for link.
With this change, the link job will be free to modify the executable as
necessary because that will not be accessed until the link is done.
Note that previous changes made the backend executable accessed through
the frontend one, and moved all link results to the frontend and backend
executables as appropriate.
Bug: angleproject:6358
Bug: angleproject:8297
Change-Id: Ie636b23ff7420ad284d18b525ec4f5fb559dd9d1
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4823089
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
68f2c10c
|
2023-08-15T22:47:32
|
|
Remove program executable backup during link
This was added in
https://chromium-review.googlesource.com/c/angle/angle/+/2181450/30 to
support the case where a program fails to relink, but needs to still be
usable.
However, this does not seem to be an issue anymore. New tests are
specifically added for this, and they, along with every other test,
pass.
If this needs to be reintroduced, it needs to be rethought. It does not
play well with parallel link as it changes the executable pointer while
link is in progress (and it was done on the assumption that everything
needing the executable is linked serially). A better solution would
likely be an `mLastSuccessfullyLinkedExecutable` that normally points to
`mExecutable`, but not during link. On `resolveLink`, it would either
make `mExecutable` point back to `mLastSuccessfullyLinkedExecutable`, or
the other way around based on whether the link was successful or not.
Bug: angleproject:8297
Change-Id: Ic9d55bccb75fff0253fe299a244bf1e4bbc416a6
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4781632
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
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>
|
|
|
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>
|
|
|
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>
|
|
89e38b57
|
2022-06-22T15:04:08
|
|
Refactor to use ANGLETest vs ANGLETestWithParam
Bug: angleproject:6747
Change-Id: I72ad52d0268eae0e1a401f12f3e94cc5efa402f2
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3719002
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Cody Northrop <cnorthrop@google.com>
|
|
a6b16d29
|
2021-03-02T19:04:57
|
|
Suppress UNINSTANTIATED_PARAMETERIZED_TEST failures on Ozone
We only support ES2 on Ozone, so tests that depend on ES3 or ES31
support are not instantiated there.
Bug: chromium:1183147
Change-Id: Id58bcd9b44a5b9a70b5ae8115e27c44f5dc81226
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2726550
Reviewed-by: Jonah Ryan-Davis <jonahr@google.com>
Commit-Queue: Yuly Novikov <ynovikov@chromium.org>
|
|
a87964cd
|
2020-09-20T21:59:23
|
|
Suppress Linux GL Compute Tests on Intel.
ComputeShaderTest.AtomicFunctionsInNonInitializerSingleAssignment/ES3_1_OpenGL
ComputeShaderTest.AtomicFunctionsInitializerWithUnsigned/ES3_1_OpenGL
ComputeShaderTest.AtomicFunctionsNoReturnValue/ES3_1_OpenGL
ComputeShaderTest.AtomicFunctionsReturnWithMultipleTypes/ES3_1_OpenGL
ComputeShaderTest.AtomicFunctionsReturnWithUnsigned/ES3_1_OpenGL
ComputeShaderTest.DispatchDraw/ES3_1_OpenGL
ComputeShaderTest.DrawDispatchDispatchDraw/ES3_1_OpenGL
ComputeShaderTest.LoadImageThenStore/ES3_1_OpenGL
ComputeShaderTest.NonArraySharedVariable/ES3_1_OpenGL
ComputeShaderTest.NonStructArrayAsSharedVariable/ES3_1_OpenGL
ComputeShaderTest.StoreImageThenLoad/ES3_1_OpenGL
ComputeShaderTest.StructArrayAsSharedVariable/ES3_1_OpenGL
ComputeShaderTest.UniformDirty/ES3_1_OpenGL
ComputeShaderTest.groupMemoryBarrierAndBarrierTest/ES3_1_OpenGL
GLSLTest_ES31.ArraysOfArraysImage/ES3_1_OpenGL
GLSLTest_ES31.MixOfAllResources/ES3_1_OpenGL
LinkAndRelinkTestES31.RelinkProgramSucceedsFromRenderingToCompute/ES3_1_OpenGL
Bug: angleproject:5072
Change-Id: I506c931d7e8714e0393fb5a7b9671b2fc74caeee
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2420332
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Jonah Ryan-Davis <jonahr@google.com>
|
|
12b6a82e
|
2020-04-03T18:31:22
|
|
No-Op draws when no active VS and/or FS is present
Re-land CL with WebGL fixes:
This required some extra pointer checking during validation to handle
the fact that a Program and/or ProgramExecutable may not be present when
attempting to draw. This isn't an error, just undefined behavior, which
we (eventually) treat as a no-op.
According to the OpenGL ES 3.1 spec:
7.3. PROGRAM OBJECTS
If there is no active program for the vertex or fragment shader
stages, the results of vertex and fragment shader execution will
respectively be undefined. However, this is not an error.
To handle this, if no VS or FS is present in the active Program/PPO,
we will no-op the draw command.
Bug: angleproject:3570
Test: KHR-GLES31.core.sepshaderobjs.StateInteraction
Change-Id: I70d688bf344a78cf3b4fd66c995ae03ce4b9b807
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2185156
Reviewed-by: Courtney Goeltzenleuchter <courtneygo@google.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Tim Van Patten <timvp@google.com>
|
|
1ab55d96
|
2020-05-06T14:45:18
|
|
Revert "No-Op draws when no active VS and/or FS is present"
This reverts commit a4b506f79e3286ffcf3a5d68f20aa97a63edab8e.
Reason for revert: WebGL crash
https://bugs.chromium.org/p/angleproject/issues/detail?id=4616
Original change's description:
> No-Op draws when no active VS and/or FS is present
>
> According to the OpenGL ES 3.1 spec:
>
> 7.3. PROGRAM OBJECTS
> If there is no active program for the vertex or fragment shader
> stages, the results of vertex and fragment shader execution will
> respectively be undefined. However, this is not an error.
>
> To handle this, if no VS or FS is present in the active Program/PPO,
> we will no-op the draw command.
>
> Bug: angleproject:3570
> Test: KHR-GLES31.core.sepshaderobjs.StateInteraction
> Change-Id: If19e9fbb1bc09fa0d490832079bb9f514eab6035
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2136386
> Reviewed-by: Jamie Madill <jmadill@chromium.org>
> Commit-Queue: Tim Van Patten <timvp@google.com>
TBR=timvp@google.com,jmadill@chromium.org,cclao@google.com
Change-Id: Ia24c4156ff7779b69c1f3f705f1a91cbb1c9684c
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: angleproject:3570
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2184849
Reviewed-by: Courtney Goeltzenleuchter <courtneygo@google.com>
Commit-Queue: Courtney Goeltzenleuchter <courtneygo@google.com>
|
|
|
a4b506f7
|
2020-04-03T18:31:22
|
|
No-Op draws when no active VS and/or FS is present
According to the OpenGL ES 3.1 spec:
7.3. PROGRAM OBJECTS
If there is no active program for the vertex or fragment shader
stages, the results of vertex and fragment shader execution will
respectively be undefined. However, this is not an error.
To handle this, if no VS or FS is present in the active Program/PPO,
we will no-op the draw command.
Bug: angleproject:3570
Test: KHR-GLES31.core.sepshaderobjs.StateInteraction
Change-Id: If19e9fbb1bc09fa0d490832079bb9f514eab6035
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2136386
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Tim Van Patten <timvp@google.com>
|
|
1a01b4b3
|
2019-11-11T16:41:07
|
|
Refactor end2end test macros
This is a foundational CL to enabling the end2end tests on swiftshader.
Refactored infrastructure with new ANGLE_INSTANTIATE_TEST_ES*
macros that will run tests over all various combinations of all
platforms for different ES versions.
Just skipping failing tests initially to get the refactor landed.
Bug: angleproject:4081
Bug: angleproject:4092
Change-Id: I017f6c3267179e49b6ae08cc7488096b423dcdb5
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1904635
Commit-Queue: Tobin Ehlis <tobine@google.com>
Reviewed-by: Courtney Goeltzenleuchter <courtneygo@google.com>
|
|
fb568849
|
2019-10-04T18:45:55
|
|
Suppress failure on Linux FYI Ozone
BUG=angleproject:3969
Change-Id: Idcefab4b5f07b018c58acb27f47721445c6a6316
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1842051
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
|
|
|
f10bf6bf
|
2019-09-26T10:27:18
|
|
Vulkan: Implement multi-threaded GL.
The main component of this change is to make vk::BufferHelper,
vk::ImageHelper and vk::SyncHelper use a common path. We introduce a
new "vk::SharedGarbage" helper class that stores small lists of garbage
from individual objects like an ImageHelper or BufferHelper. The
SharedGarbage is stored in the RendererVk with the ResourceUse of the
helper object. The ResourceUse tells RendererVk when it is safe to
destroy the GarbageObjects.
New "onGraphAccess" commands are added in a few places to enable the
common garbage collection path. A couple Context-only resources like
default attributes now are referenced where they were not before.
Also reorganizes some functions so we can add a few helpful ASSERTs
to our graph dependencies. Added "updateCurrentAccessNodes" for this.
Also adds a "RendererScoped" helper to replace many uses of
"ContextScoped".
The multithreading EGL tests mostly pass but have some remaining
flakiness so cannot yet be enabled.
Bug: angleproject:2464
Change-Id: Ia3e3ae8848d731abf3f21ebe04c33e381e130be0
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1808444
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
|
|
86b0868d
|
2019-01-05T19:12:26
|
|
Enable RenderingProgramFailsWithProgramInstalled.
Enable end2end test
LinkAndRelinkTest.RenderingProgramFailsWithProgramInstalled on Vulkan.
It works now because Vulkan was rolled and a shader with no output is
now a warning instead of an error.
BUG=angleproject:2648
Change-Id: Ie92d28b53c18a9a2b74fc2d1b951923512910a33
Reviewed-on: https://chromium-review.googlesource.com/c/1396264
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Frank Henigman <fjhenigman@chromium.org>
|
|
|
35cd7332
|
2018-12-02T12:03:33
|
|
Refactor test shader style.
This change enforces a lot more consistency. We pass const char * to
the Compile functions instead of std::string. Also fixes the
indentation of C++11 block comments to be more consistent.
Bug: angleproject:2995
Change-Id: Id6e5ea94055d8cbd420df4ea2e81b2d96cb5ce78
Reviewed-on: https://chromium-review.googlesource.com/c/1357103
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
|
|
af883628
|
2018-06-08T15:57:31
|
|
Vulkan: enable as many end2end tests as possible
Bug: angleproject:2615
Change-Id: I918cc18984b2e5b22b5e13398355a2fd60e4eb00
Reviewed-on: https://chromium-review.googlesource.com/1093564
Commit-Queue: Luc Ferron <lucferron@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
|
|
ece12535
|
2017-11-21T15:50:21
|
|
ES31: Fix the issue for relink rendering/compute program.
When link or relink fails, if we try to install the unsuccessfully linked
program (via UseProgram) and start rendering or dispatch compute, We can
not always report INVALID_OPERATION for rendering/compute pipeline.
The result depends on the previous state: Whether a valid program has been
installed in pipeline before. If a valid program has been installed, it
should be OK to use the old executable residing in the GL state to start
rendering or dispatch compute. No error should be reported.
This change also add unit tests for unsuccessfully linked/relinked program
for rendering pipeline to avoid potential error.
If a program successfully relinks when it is in use, the program might
change from a rendering program to a compute program in theory,
or vice versa.
BUG=angleproject:2266
Change-Id: I4726112af2bc74f5beef25e35d2fcaa9f31e0768
Reviewed-on: https://chromium-review.googlesource.com/784273
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
|