|
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>
|
|
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>
|
|
df4d9667
|
2023-12-13T18:28:53
|
|
Revert "Optimize HandleAllocator for fast ID churning."
This reverts commit b25ffe5a9775cc912a304c8552dd9c097a93420a.
Reason for revert: b/316162914
Original change's description:
> Optimize HandleAllocator for fast ID churning.
>
> Instead of calculating ranges of IDs and the overhead with updating
> them every allocation/release, store a released ID list in a small
> FastVector.
>
> Optimize the allocate path for the "good case" of no reserved IDs so
> that it either pops the last released ID or incriments a next value and
> returns it. Release has a similar cost of just a push_back when there
> are no reserved IDs.
>
> This adds a small fixed memory cost due to the FastVector and a dynamic
> memory cost of mReleasedList having up to N elements where N is the
> maxmimum total handles allocated at one time.
>
> Bug: angleproject:8434
> Change-Id: I7c5aa126b5303c105cd2464d0d0933b922cc2b8f
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5101509
> Reviewed-by: Charlie Lao <cclao@google.com>
> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Bug: angleproject:8434
Change-Id: Ide43d787b6942cc6b622e3b5d938bfbbbf3b3ebb
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5120277
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
|
|
b25ffe5a
|
2023-12-07T16:36:29
|
|
Optimize HandleAllocator for fast ID churning.
Instead of calculating ranges of IDs and the overhead with updating
them every allocation/release, store a released ID list in a small
FastVector.
Optimize the allocate path for the "good case" of no reserved IDs so
that it either pops the last released ID or incriments a next value and
returns it. Release has a similar cost of just a push_back when there
are no reserved IDs.
This adds a small fixed memory cost due to the FastVector and a dynamic
memory cost of mReleasedList having up to N elements where N is the
maxmimum total handles allocated at one time.
Bug: angleproject:8434
Change-Id: I7c5aa126b5303c105cd2464d0d0933b922cc2b8f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5101509
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
6399f8d3
|
2023-09-24T05:01:22
|
|
Bugfix in HandleAllocator::reset(...)
Cache "maximumHandleValue" passed in via constructor
and use this value in reset(...)
Bug: angleproject:8354
Test: HandleAllocatorTest.ResetAndReallocate
Change-Id: I63bb953186a07d32582a0276af3ac8cb26a007a5
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4888690
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: mohan maiya <m.maiya@samsung.com>
|
|
|
a7238b52
|
2022-04-28T12:04:51
|
|
Consolidate handle list before pushing to mReleasedList
Walk mUnallocatedList and try consolidating the range before pushing
the to-be-released handle onto mReleasedList. This avoids a buggy
behavior with dEQP which can be reproduced by running the following
tests in this order -
dEQP.GLES3/functional_samplers_single_cubemap_diff_wrap_t
dEQP.GLES3/functional_negative_api_buffer_framebuffer_texture_layer
Test: HandleAllocatorTest.ConsolidateRangeDuringRelease
Bug: angleproject:7248
Change-Id: I8d2701f193fc6a2f36151c09719284a7832ab2d4
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3617198
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Commit-Queue: mohan maiya <m.maiya@samsung.com>
|
|
338abb46
|
2018-01-30T18:16:30
|
|
Fix invalid heap exception in angle
Running angle deqp test case, an invalid heap exception is thrown in
angle on both linux and windows platforms.
If build a nonsequential heap, and then erase any node of the heap,
the heap is no longer valid. If using std::push_heap or std::pop_heap
method next, this exception will be thrown out. So we should use
std::make_heap after modifying the heap.
TEST=angle_deqp_gles2_tests
TEST=angle_deqp_gles3_tests
TEST=HandleAllocatorTest.ReserveAfterReleaseBug
BUG=angleproject:2326
Change-Id: I123fc81b3365c93081d0042c69b4e5114956fe0d
Reviewed-on: https://chromium-review.googlesource.com/892961
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
|
|
fc3463da
|
2018-01-03T13:46:21
|
|
HandleAllocator: Fix heap ordering using std::greater.
The default heap ordering is to return the greatest element in the
heap. Since the handle allocator expects a minimal return value on
a new allocation, this caused a bug. The bug is triggered by reserving
handles, allocating new handles, then freeing the handles and
allocating again with the same allocator. Fix the bug by using
std::greater instead of std::less, which will make the heap
return the smallest value instead of largest.
Also adds some logging debugging code for the handle allocators.
Bug: angleproject:1458
Change-Id: Ibef5dcbed0a664ccad0e0335f081e2355162584b
Reviewed-on: https://chromium-review.googlesource.com/848644
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Frank Henigman <fjhenigman@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>
|
|
c0281d46
|
2016-10-17T15:19:01
|
|
HandleAllocator: make HandleRange inclusive.
Previously part of the code saw it as [begin, end) while others saw it
as [begin, end].
BUG=angleproject:1052
BUG=chromium:656485
Change-Id: Id8e9e26b167e02a07dfc5341569df53a14d0623d
Reviewed-on: https://chromium-review.googlesource.com/399565
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
|
|
03786d77
|
2015-05-27T11:22:30
|
|
After a create-on-bind, the subsequent glGen* should not waste handle space.
Consider this calling sequence:
glBindTexture(GL_TEXTURE_2D, 3); // create-on-bind
glGenTextures(1, tex);
Before this fix, mUnallocatedList in HandleAllocator is in reverse sorted
order. It's split into (4, MAX_UINT) and (1, 3). The glGen gets tex = 4,
and handles 1 and 2 will not be allocated until it reaches MAX_UINT.
With this fix, the elements in mUnallocatedList is in sorted order
(1, 3) and (4, MAX_UINT). So tex is 1, and we can have all rest handles.
Change-Id: If408ea92f7c243791119fe386e3e0ea27954e55c
Reviewed-on: https://chromium-review.googlesource.com/273886
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Tested-by: Minmin Gong <mgong@microsoft.com>
|
|
|
d3e7aa33
|
2015-06-29T12:25:24
|
|
Allow calling HandleAllocator::reserve with MAX_UINT.
BUG=angleproject:1052
Change-Id: I03883799ef334f39c9e855a0a4b7af1ab02d5da9
Reviewed-on: https://chromium-review.googlesource.com/282414
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Tested-by: Minmin Gong <mgong@microsoft.com>
|
|
|
bdd419f9
|
2015-03-20T15:29:42
|
|
Fix ResourceManager create-on-bind reallocations.
*re-land with build fix for Clang*
We had a funny bug where the Handle Allocator would re-allocate
reserved handles after the app layer creates one with Bind rather
than using Gen. This affects Textures, Buffers and Renderbuffers.
Fix this by using a different allocation scheme. It should still
be fast on the "good" case (using Gen) and use tree lookups on the
bind case. Also add some unit tests.
BUG=angleproject:942
Change-Id: I63ce608fcd6a11f92e2b5421f090551934e729ed
Reviewed-on: https://chromium-review.googlesource.com/261591
Tested-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
|
|
|
21045f5a
|
2015-03-20T19:28:45
|
|
Revert "Fix ResourceManager create-on-bind reallocations."
Build break on GPU FYI Bots on Linux/Mac:
http://build.chromium.org/p/chromium.gpu.fyi/builders/GPU%20Mac%20Builder/builds/28092
This reverts commit 61ce1a414e74f6a72a520d6adf59bff13aff03a0.
Change-Id: If2e7fb35c769708a783a32932b777dc97eaba8a4
Reviewed-on: https://chromium-review.googlesource.com/261590
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Tested-by: Jamie Madill <jmadill@chromium.org>
|
|
|
61ce1a41
|
2015-03-20T13:13:04
|
|
Fix ResourceManager create-on-bind reallocations.
We had a funny bug where the Handle Allocator would re-allocate
reserved handles after the app layer creates one with Bind rather
than using Gen. This affects Textures, Buffers and Renderbuffers.
Fix this by using a different allocation scheme. It should still
be fast on the "good" case (using Gen) and use tree lookups on the
bind case. Also add some unit tests.
BUG=angleproject:942
Change-Id: I2e3f4c31b28cb86bd3699035f5d55568a2a1d7d5
Reviewed-on: https://chromium-review.googlesource.com/258904
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Tested-by: Jamie Madill <jmadill@chromium.org>
|