|
ab7457db
|
2025-01-14T11:55:06
|
|
Move ResourceMap mHashedResources access to functions
Follow up to https://crrev.com/c/6169263
https://chromium-review.googlesource.com/c/angle/angle/+/6169263/comment/43a79fa6_2a24673c/
Moves mHashedResources access out to function calls as this is a
fallback that is supposed to be hit very rarely. This makes the likely
branch (flat map accessors/modifiers) smaller so they can be easily
inlined without adding much bloat. I also moved flat map resize to a
function call as it is fairly rare and makes calls and malloc.
This further reduces aarch64 .so size by ~12KB (0.2%) and hopefully
improves locality a bit (perf tests inconclusive)
Also inline Sampler access in ResourceManager which now uses these
small inline accessors.
Bug: b/383305597
Change-Id: I013eeb27bf619cc9549a977ab92173e799a1466a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6174944
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
b5b2612e
|
2025-01-13T12:36:39
|
|
Tune branching in getProgramResolveLink()
Hinting the likely/unlikely branches in related calls. Notably,
mShaderProgramManager->getProgram() has a flat resource array and a
fallback to a absl::flat_hash_map. As observed in driver_overhead_2
trace based PGO builds, the fallback gets un-inlined by PGO (presumably
due to being hit rarely) and becomes a function call. Regular builds
without the tuning in this CL inline flat_hash_map implementation,
increasing the code size / worsening locality for a fallback case.
This change makes the Context::useProgram() aarch64 assembly
in regular builds very close to the driver_overhead_2 based PGO,
and the code size goes down from 576 to 256 bytes.
The total reduction of the .so size is 36KB (0.6%), likely due to
all the cases where the inlining is avoided by hinting.
There appears to be a ~1% perf improvement in driver_overhead_2
trace wall_time in my tests on a couple of Android devices. Hard to tell
if this is due to the improved code locality or some other aspect of
the change in assembly.
Bug: b/383305597
Change-Id: I85c02cc74a56e7074086965e8d31018bd9ee0040
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6169263
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Roman Lavrov <romanl@google.com>
|
|
|
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>
|
|
b257da86
|
2024-05-21T12:04:21
|
|
Fix build on compilers that get confused with templates
Bug: angleproject:8667
Change-Id: Ie3d35b617ceb5bb6c0e13e0dfda370bbe18d888a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5554982
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Geoff Lang <geofflang@chromium.org>
|
|
|
f4140c76
|
2024-05-10T16:56:13
|
|
Remove share group lock from glBindBuffer
This is a very hot function. Removing the share group lock from this
function improves the driver_overhead_2 execution time by ~1ms on Pixel
6.
Bug: angleproject:8667
Change-Id: I9ea04f48aa1d2d0efec21407374393e88a1316e3
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5533081
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
49317d73
|
2024-05-10T16:11:59
|
|
Prepare resource map for being potentially thread-safe
Resource maps are used for both shared and context-private resources.
Context-private resource maps do not need any locking. Once glBind* and
similar commands are made free of the share group lock, the resource map
of the corresponding type must be made thread safe, especially for look
up.
This change adds the ability to the resource map to be either thread
safe or not, based on the type of the resource it contains. Currently,
only a test type (unsigned int) is thread safe (used in unit tests).
This is achieved by a combination of the following:
- For resource maps that need a lock, the flat part of the map has an
initially reasonable size, but is _never_ reallocated. This makes
access to that part of the map lockfree.
- The hash-map that contains large ids is always protected by a mutex.
Follow up changes will start enabling thread-safety for resources as
their corresponding glBind command is made lockless.
Bug: angleproject:8667
Change-Id: Ia4ffffee41f021d833d31f296bc883bf12f1135f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5527771
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
a1665d2f
|
2024-05-10T00:15:31
|
|
Reland "Document thread-unsafe iterator access to resource maps"
This is a reland of commit d1bb6ed8399dd12e79484f30f9e9ded95c25625a
The crash was due to another issue (disabling EGL validation in
Chrome)
Original change's description:
> Document thread-unsafe iterator access to resource maps
>
> By using a proxy type, everywhere resource maps are iterated are clearly
> marked as not being thread safe. In most cases, only destruction and
> capture/replay iterate over these maps, which means thread safety is not
> an issue (or is externally enforced).
>
> The only case where iterators are used in the presence of other contexts
> is with ANGLE_request_extension, which is changed to explicitly require
> the application to ensure thread safety. In practice, the user is
> Chrome which already guarantees this.
>
> Bug: angleproject:8667
> Change-Id: I7af13c6433b6955d9c36f9088b3aa4c065e1cfc1
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5526428
> Reviewed-by: Charlie Lao <cclao@google.com>
> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
> Reviewed-by: Geoff Lang <geofflang@chromium.org>
Bug: angleproject:8667
Change-Id: Id539cabac01df5f242150f6684222577003eef3f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5531278
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
|
|
|
4e887491
|
2024-05-11T18:08:03
|
|
Revert "Document thread-unsafe iterator access to resource maps"
This reverts commit d1bb6ed8399dd12e79484f30f9e9ded95c25625a.
Reason for revert: Checking to see if it's the reason
for crbug.com/339948886
Original change's description:
> Document thread-unsafe iterator access to resource maps
>
> By using a proxy type, everywhere resource maps are iterated are clearly
> marked as not being thread safe. In most cases, only destruction and
> capture/replay iterate over these maps, which means thread safety is not
> an issue (or is externally enforced).
>
> The only case where iterators are used in the presence of other contexts
> is with ANGLE_request_extension, which is changed to explicitly require
> the application to ensure thread safety. In practice, the user is
> Chrome which already guarantees this.
>
> Bug: angleproject:8667
> Change-Id: I7af13c6433b6955d9c36f9088b3aa4c065e1cfc1
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5526428
> Reviewed-by: Charlie Lao <cclao@google.com>
> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
> Reviewed-by: Geoff Lang <geofflang@chromium.org>
Bug: angleproject:8667
Change-Id: I1245c9e57dfeb27a7f0e5718b1455614c70bc0dc
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5532187
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
d1bb6ed8
|
2024-05-10T00:15:31
|
|
Document thread-unsafe iterator access to resource maps
By using a proxy type, everywhere resource maps are iterated are clearly
marked as not being thread safe. In most cases, only destruction and
capture/replay iterate over these maps, which means thread safety is not
an issue (or is externally enforced).
The only case where iterators are used in the presence of other contexts
is with ANGLE_request_extension, which is changed to explicitly require
the application to ensure thread safety. In practice, the user is
Chrome which already guarantees this.
Bug: angleproject:8667
Change-Id: I7af13c6433b6955d9c36f9088b3aa4c065e1cfc1
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5526428
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
|
|
|
4cacc66e
|
2024-05-09T16:08:58
|
|
Remove unused ResourceMap::find
Bug: angleproject:8667
Change-Id: I0d0c00337895b247a1f0536f5072fdcf12b7de1e
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5527560
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
|
|
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>
|
|
23d63fc3
|
2020-03-17T20:34:50
|
|
Capture/Replay: Fix MEC Query capture.
In Manhattan the test generates a bunch of queries that it doesn't
start until later frames. In ANGLE these queries will be stored as
nullptr entries in the QueryMap. By default the QueryMap Iterator skips
over nullptr entries. This manifested later as GL errors during replay.
Fix this by adding a new Iterator type to ResourceMap that does not
skip over nullptr values.
Bug: angleproject:4489
Change-Id: If56b908fb233de0df0445f9ea19fc322f2c42976
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2107762
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Cody Northrop <cnorthrop@google.com>
Reviewed-by: Courtney Goeltzenleuchter <courtneygo@google.com>
|
|
|
66e0feec
|
2019-09-03T18:45:43
|
|
Remove default template args in ResourceMap.
Only need GLuints now for GLsyncs.
Bug: angleproject:3611
Change-Id: Id8b11851d8d5d30e6743433c772b9fa85eb875f5
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1783406
Reviewed-by: Jonah Ryan-Davis <jonahr@google.com>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
|
|
|
7c7dec01
|
2019-08-06T17:44:11
|
|
Use RenderbufferID in place of GLuint handles.
This will allow frame capture/replay to more easily emulate object
handle manipulation. It also provides a bit of type safety. Also
generalizes ResourceMap to handle non-GLuint IDs.
Bug: angleproject:3611
Change-Id: I174fd260f326e0dbe2aca3f818215c91d82cf48c
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1706559
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
|
|
|
31116738
|
2018-10-09T18:30:01
|
|
Inline many more hotspots for the Texture draw test.
Bug: angleproject:2763
Change-Id: Ib8193e7ff5ee7763b92f4775fb7e9adaa51c9305
Reviewed-on: https://chromium-review.googlesource.com/c/1262738
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Yuly Novikov <ynovikov@google.com>
|
|
|
0fdb956d
|
2018-09-17T17:18:43
|
|
Re-land "Inline and micro-optimize more for perf tests.""
Re-land fixes memory leaks.
Using a custom array instead of std::vector speeds up the resource
manager. One reason is because calls to size() are implemented in many
implementations as a difference between two pointers. This sub size
implementations are slower than storing a simple size variable in a
custom class.
Also includes more inlining of hot spots functions.
Also includes a small unit test class for ResourceMap. And an unrelated
but small test fix for TextureLimisTest. Also a small unrelated fix for
a Transform Feedback test.
Increase the scores of the draw call perf test with texture and buffer
bindings and the buffer binding perf test.
Bug: angleproject:2763
Change-Id: Ic2f0f689107b2bf05c63da2ed6bbc9f0feea63f7
Reviewed-on: https://chromium-review.googlesource.com/1229033
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
|
|
98a3e078
|
2018-09-17T19:40:04
|
|
Revert "Inline and micro-optimize more for perf tests."
This reverts commit 57ff6f95f143bd65a0c3d12d64773f274b9935f4.
Reason for revert: Memory leaks detected during roll in https://ci.chromium.org/p/chromium/builders/luci.chromium.try/linux_chromium_asan_rel_ng/100284
Original change's description:
> Inline and micro-optimize more for perf tests.
>
> Using a custom array instead of std::vector speeds up the resource
> manager. One reason is because calls to size() are implemented in many
> implementations as a difference between two pointers. This sub size
> implementations are slower than storing a simple size variable in a
> custom class.
>
> Also includes more inlining of hot spots functions.
>
> Also includes a small unit test class for ResourceMap. And an unrelated
> but small test fix for TextureLimisTest. Also a small unrelated fix for
> a Transform Feedback test.
>
> Increase the scores of the draw call perf test with texture and buffer
> bindings and the buffer binding perf test.
>
> Bug: angleproject:2763
> Change-Id: I41c327987db27ac45e6a62579f01e1cdc22e396c
> Reviewed-on: https://chromium-review.googlesource.com/1171510
> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
> Reviewed-by: Jamie Madill <jmadill@chromium.org>
> Commit-Queue: Jamie Madill <jmadill@chromium.org>
TBR=fjhenigman@chromium.org,ynovikov@chromium.org,jmadill@chromium.org,syoussefi@chromium.org
Change-Id: Ie047289c9bf23a842c3cbb9692c811da0534991c
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: angleproject:2763
Reviewed-on: https://chromium-review.googlesource.com/1228893
Reviewed-by: Yuly Novikov <ynovikov@chromium.org>
Commit-Queue: Yuly Novikov <ynovikov@chromium.org>
|
|
|
57ff6f95
|
2018-09-14T12:44:52
|
|
Inline and micro-optimize more for perf tests.
Using a custom array instead of std::vector speeds up the resource
manager. One reason is because calls to size() are implemented in many
implementations as a difference between two pointers. This sub size
implementations are slower than storing a simple size variable in a
custom class.
Also includes more inlining of hot spots functions.
Also includes a small unit test class for ResourceMap. And an unrelated
but small test fix for TextureLimisTest. Also a small unrelated fix for
a Transform Feedback test.
Increase the scores of the draw call perf test with texture and buffer
bindings and the buffer binding perf test.
Bug: angleproject:2763
Change-Id: I41c327987db27ac45e6a62579f01e1cdc22e396c
Reviewed-on: https://chromium-review.googlesource.com/1171510
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
|
|
|
96a483bc
|
2017-06-27T16:49:21
|
|
Add a ResourceMap class for faster GL resource maps.
This gives a very fast query time for handles that are within a fixed
range. For WebGL, where we don't allow create-on-bind, this will be
100% of the time, unless we create a very large number of resources.
It is implemented as a two-tier map - the first uses a flat array to
index into a handle buffer. The second tier uses a map for out-of-
range values.
BUG=angleproject:1458
Change-Id: I421bb3725cf523918cdfdbfaab035ad0dd3bf82d
Reviewed-on: https://chromium-review.googlesource.com/544684
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
|