|
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>
|
|
|
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>
|
|
|
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>
|
|
|
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>
|
|
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>
|
|
|
91976352
|
2022-06-21T15:41:02
|
|
Use C++17 attributes instead of custom macros
Bug: angleproject:6747
Change-Id: Iad6c7cd8a18d028e01da49b647c5d01af11e0522
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3718999
Reviewed-by: Cody Northrop <cnorthrop@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
b55f0f78
|
2020-06-02T18:01:24
|
|
Compress Program binaries saved in blob cache
The Android blob cache has a limit of 2MB, so ANGLE should compress the
Program binaries that are saved into it to maximize its effectiveness.
ANGLE will gzip the program binaries before being stored in the blob
cache and then uncompress them when retrieved. Using gzip, the binaries
are compressed to ~25% of their size when running the T-Rex benchmark.
Some examples (in bytes):
Uncompressed: 20193, Compressed: 4455
Uncompressed: 8767, Compressed: 2369
Uncompressed: 11144, Compressed: 2927
This doesn't appear to affect the T-Rex benchmark since all of the
programs are loaded/decompressed as part of the benchmark
initialization, and the programs are small enough to all fit in the
blob cache without compression.
Bug: b/155184635
Test: T-Rex, CQ
Change-Id: Ie6a101c32ab5fd49baae1cb7aecdd26a934e15af
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2227529
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Tim Van Patten <timvp@google.com>
|
|
a36f8bd4
|
2020-01-29T12:10:17
|
|
Mark MemoryBuffer allocation functions as NO_DISCARD
Not all call sites were checking the return value of
MemoryBuffer::resize, mark the return value as NO_DISCARD and fix all
the warnings.
BUG=chromium:1030835
Change-Id: I762796e3d11efc131a814069d78a195b0d4c9f8f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2028151
Commit-Queue: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
9d737966
|
2019-08-14T12:25:12
|
|
Standardize copyright notices to project style
For all "ANGLE Project" copyrights, standardize to the format specified
by the style guide. Changes:
- "Copyright (c)" and "Copyright(c)" changed to just "Copyright".
- Removed the second half of date ranges ("Y1Y1-Y2Y2"->"Y1Y1").
- Fixed a small number of files that had no copyright date using the
initial commit year from the version control history.
- Fixed one instance of copyright being "The ANGLE Project" rather than
"The ANGLE Project Authors"
These changes are applied both to the copyright of source file, and
where applicable to copyright statements that are generated by
templates.
BUG=angleproject:3811
Change-Id: I973dd65e4ef9deeba232d5be74c768256a0eb2e5
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1754397
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
|
c3abb7f1
|
2019-01-17T11:26:48
|
|
Fix MultiDraw shaders when loaded from cache
State updates that need to be done after linking vs. deserializing can
get out of sync, as was the case for mDrawIDLocation (introduced in
1bf18ce9e2caca7067b4439373f4fb04a5cd7d21). This commit introduces a
common function that's called from both paths to hopefully avoid such
issues in the future.
The serialize/deserialize functions are moved from MemoryProgramCache
to the Program itself.
Bug: 890539,angleproject:2516
Change-Id: Idc5b87de53298aacbb1884e79e721b876281fb13
Reviewed-on: https://chromium-review.googlesource.com/c/1417970
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
785e8a0b
|
2018-10-04T17:42:00
|
|
Remove gl::LinkResult.
Instead of returning a small struct from LinkProgram calls we use
angle::Result. Linking can have 3 cases:
- the link was successful -> angle::Result::Continue
- the link failed -> angle::Result::Incomplete
- there was an internal error -> angle::Result::Stop
Note that any unexpected Incomplete is still an error. Each function
that accepts Incomplete must check explicitly.
This is the last user of ErrorOrResult.
Bug: angleproject:2491
Change-Id: Idba23be27efe4b561720a4bdd8fe486b40779497
Reviewed-on: https://chromium-review.googlesource.com/c/1255645
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Yuly Novikov <ynovikov@google.com>
|
|
9137adea
|
2018-08-27T14:22:37
|
|
Add support for EGL_ANDROID_blob_cache
The functionality of MemoryProgramCache is divided up in two. BlobCache
is now a generic binary cache, which interfaces with the callbacks from
EGL_ANDROID_blob_cache. MemoryProgramCache handles program
[de]serialization and interacts with BlobCache.
Bug: angleproject:2516
Change-Id: Ie4328a2e56a26338e033d84f4e53a1103411937d
Reviewed-on: https://chromium-review.googlesource.com/1194285
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
|
|
|
6c58b062
|
2017-08-01T13:44:25
|
|
Add histograms for the program cache.
Also includes some tracking of if a cache hit comes from a binary
inserted after a Link call, or sourced from the external disk cache.
Chromium-side CL: https://chromium-review.googlesource.com/c/592151/
BUG=angleproject:2118
Change-Id: I80eefd203d8ce31d1ac03dd1a36459d3581128f5
Reviewed-on: https://chromium-review.googlesource.com/590689
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
|
|
|
4c19a8a8
|
2017-07-24T11:46:06
|
|
D3D11: Update cached dynamically recompiled programs.
This change makes it so that when we need to recompile a program on a
draw call, we also update the cache. It also streamlines the internal
queries of the dynamic vertex and fragment shaders such that we only
update the input and output signatures a single time per draw. This
should also facilitate dirty bit implementations for the D3D11 back-
end.
BUG=angleproject:2116
Change-Id: Iccb0501b700bc894f40a8c68d7f297ff0c8f46bd
Reviewed-on: https://chromium-review.googlesource.com/531798
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
|
|
|
c43be720
|
2017-07-13T16:22:14
|
|
Implement ANGLE_program_cache_control extensions.
This will give the browsers the ability to control the cache size,
query and populate the contents, and trim cache contents on memory
pressure.
BUG=angleproject:1897
Change-Id: I6edaa7d307b890223db98792d5b074e4a7fdfaa4
Reviewed-on: https://chromium-review.googlesource.com/563606
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
|
|
|
360daeef
|
2017-06-29T10:36:19
|
|
Add platform hook for program cache updates.
This will need to be matched with a corresponding browser-side CL.
It will enable writing out binary shaders to disk.
BUG=angleproject:1897
Change-Id: I443281086050b9711b92a034cf37f808dd919007
Reviewed-on: https://chromium-review.googlesource.com/542963
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
|
|
|
3244736a
|
2017-06-28T14:53:52
|
|
Use MemoryProgramCache.
Add the member functions for saving and loading from the binary cache,
and hook them into the Program class. Requires that the Renderer
supports the program binary extension.
BUG=angleproject:1897
Change-Id: I2dc8d21b02da705ded58c5cd1943562c9c97c49b
Reviewed-on: https://chromium-review.googlesource.com/522874
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
|
|
|
4f86d053
|
2017-06-05T12:59:26
|
|
Introduce MemoryProgramCache.
This class will manage GPU binary programs in memory. It will be
owned by the Display, and shared between Contexts. Currently this
CL just refactors the Program binary saving and loading into static
members of this new class.
BUG=angleproject:1897
Change-Id: I34f5afb2c02416f6fd80dd65ba3827a8637ce190
Reviewed-on: https://chromium-review.googlesource.com/522873
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
|