Shared image #56
Merged
Shared image #56
Conversation
This file contains 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
Those abstract the two main shared access memory slices: unsynchronous and synchronous access to memory. The goal here is to find out which actual operations will be possible under these two models. One main limit has already been observed where atomic reads can not be trivially broken up for the slice. Due to this reason we stabilize the Cell types first, and deal with synchronization at a later point.
This experiment wasn't public, and adds some complexity. Remove it until request. We should balance the need for its implementation with the abilities of concurrent buffers.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Implementing two new buffers in
texelwhich interact through the existingTexeltype:CellBuffer, keeping its data in a sharedRcand supporting concurrent modification.AtomicBuffer, keeping its data in a sharedArcand supporting parallel modification in a manner that is potentially wait-free if the underlying platform primitives allow it. The effect of modifications is only specified if the user avoids aliasing but it is always sound.Unfortunately the
Imageand derived layout-imbued buffers heavily depend onas_slice() -> &[P]which neither of these new types can provide. EvenRawImage, the underlying private primitive, depends on traits that offer these methods as all byte-access is done through a direct byte slice for efficiency. Since I don't have a concrete idea on how to best approach this conflict, let's just put that for another time. This also includes lifting the types incanvaswhere it could be used for the shader / conversion code.