Make tile scheduling linear instead of quadratic - #247
Merged
Conversation
Signed-off-by: lordnn <lordnn@yahoo.com>
…invariants Signed-off-by: KP Choi <kp5.choi@samsung.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This adopts the tile scheduling change from #225 by @lordnn, with the original commit cherry-picked and authorship preserved.
Worker threads used to scan the tile status array from index 0 inside the critical section to find the next tile, making tile acquisition O(n) and a whole frame O(n^2). The scan is replaced with a shared next-tile counter, so acquisition is O(1). Since every tile is claimed exactly once in index order and the status array is initialized identically for full and partial decoding (every tile carries the DO flag, with DECODE or SKIP deciding the actual work), the processing semantics are unchanged.
Compared to #225 this adoption is conservative:
volatileon the tile status stays, the completion status updates stay inside the critical section, and the claim invariants are asserted.Verified against unpatched builds with identical outputs in all cases: the full test suite in Release and Debug, multithreaded encode bitstreams (plain and ABR rate control), full and cyclic tile-based partial decoding across 5 tile conformance streams and 1/2/4/8 threads, and partial decoding with tile index lists passed in non-ascending order. ThreadSanitizer reports no findings for multithreaded encode and decode. With a 3840x2160 stream at the RFC tile limits the scan cost is negligible, but combined with the small-tile extension in #236 (32,400 tiles of 16x16) the change reduces encode wall time from 1.3s to 0.11s and decode from 2.4s to 0.52s at 8 threads, with bit-identical results.