This reverts commit 423dd689df.
Reason for revert: had missed corner case when tail block was empty
Original change's description:
> Revert "Support moving blocks from one allocator to another"
>
> This reverts commit 0f064041bf.
>
> Reason for revert: unit test failures on some windows bots
>
> Original change's description:
> > Support moving blocks from one allocator to another
> >
> > Uses this new capability and the previously implemented reserve()
> > feature to implement efficient concatenation of GrTAllocators.
> >
> > Change-Id: I2aff42eaf75e74e3b595d3069b6a271fa7329465
> > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/303665
> > Commit-Queue: Michael Ludwig <michaelludwig@google.com>
> > Reviewed-by: Robert Phillips <robertphillips@google.com>
>
> TBR=robertphillips@google.com,csmartdalton@google.com,michaelludwig@google.com
>
> Change-Id: I931f2462ecf6e04d40a671336d0de7d80efd313d
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/304604
> Reviewed-by: Michael Ludwig <michaelludwig@google.com>
> Commit-Queue: Michael Ludwig <michaelludwig@google.com>
TBR=robertphillips@google.com,csmartdalton@google.com,michaelludwig@google.com
# Not skipping CQ checks because this is a reland.
Change-Id: Ia793c2f0e7ab2f3fd437871fa7fb4f56979f9ceb
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/304739
Auto-Submit: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
This reverts commit 0f064041bf.
Reason for revert: unit test failures on some windows bots
Original change's description:
> Support moving blocks from one allocator to another
>
> Uses this new capability and the previously implemented reserve()
> feature to implement efficient concatenation of GrTAllocators.
>
> Change-Id: I2aff42eaf75e74e3b595d3069b6a271fa7329465
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/303665
> Commit-Queue: Michael Ludwig <michaelludwig@google.com>
> Reviewed-by: Robert Phillips <robertphillips@google.com>
TBR=robertphillips@google.com,csmartdalton@google.com,michaelludwig@google.com
Change-Id: I931f2462ecf6e04d40a671336d0de7d80efd313d
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/304604
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Uses this new capability and the previously implemented reserve()
feature to implement efficient concatenation of GrTAllocators.
Change-Id: I2aff42eaf75e74e3b595d3069b6a271fa7329465
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/303665
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
This can optimize cases in a allocate-release loop that moves back
and forth across the end of one block and the start of another. Before
this would malloc a new block and then delete it.
It also enables reserve() in higher-level data collections w/o blocking
bytes left in the current tail block.
Change-Id: Ide16e9038384fcb188164fc9620a8295f6880b9f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/303268
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Previously, the blocks owned by a GrBlockAllocator provided block-level
metadata that users could control to track within a block. For types
like GrTAllocator (and a collection coming down the pipe), they need
to store a total count of allocations.
Since GrBlockAllocator is max-aligned, having them hold on to a single
extra int adds 4 to 12 bytes of padding for 8 and 16byte aligned
platforms. But, the old Block size already has 4 bytes of extra padding
since it was 28 bytes packed. This had been allowed to be allocation
data, for requests that were 4-byte aligned or less.
In practice, I think it's better to use that space for allocator-level
metadata so that a total count, or other high-level data, can be
packed into the data already held by GrBlockAllocator. Now GrTAllocator
instances should be 8-16 bytes smaller on those same platforms. Also
no longer writing into the struct-padded nether-realm, which is probably
just a good thing on principle.
Also cleans up how GrTAllocator's push_back() and emplace_back() are
tested to make sure all options are clearly covered.
Change-Id: If1da29132f3ec8df7a4056fcd834f760eb4693f5
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/303267
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
This makes reset() a little easier to follow, and enables more complex
use cases on top of GrBlockAllocator down the road.
Change-Id: Id79d20e2b394248c997259d6d5b5494fc1456acc
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/302678
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
This moves the byte block linked list structure outside of GrMemoryPool
into a new type, GrBlockAllocator. This new type is solely responsible
for managing the byte blocks, tracking where the next allocation
occurs, and creating/destroying the byte blocks. It also tries to
encapsulate all of/most alignment related math, while making it
convenient for clients to add per-allocation padding/metadata.
It has added functionality compared to the original block linked list
that was embedded in GrMemoryPool:
- Supports resetting the entire allocator
- Supports resizing the last allocation
- Is able to rewind an entire stack of allocations, instead of just the
last allocation.
- Supports multiple block growth policies instead of just a fixed size.
- Supports templated alignment, and variable alignment within a single
GrBlockAllocator
- Query the amount of available memory
- Performs as much math as possible in 32-bit ints with static asserts
that ensure overflow won't happen.
Some of this flexibility was added so that the GrBlockAllocator can be
used to implement an arena allocator similar to SkArenaAlloc, or to
replace the use of SkTArray in GrQuadBuffer. It is also likely possible
that GrAllocator can be written on top of GrBlockAllocator. I will try
to perform these consolidations in later CLs.
Change-Id: Ia6c8709642369b66b88eb1bc46264fb2aa9b62ab
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/262216
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>