OGRE-Next
4.0.0unstable
Object-Oriented Graphics Rendering Engine
|
Enumerations | |
enum | CopyEncTransitionMode { Auto , AlreadyInLayoutThenAuto , AlreadyInLayoutThenManual } |
Copy Encoder Transition modes to be used by TextureGpu::copyTo and TextureGpu::_autogenerateMipmaps. More... | |
Copy Encoder Transition modes to be used by TextureGpu::copyTo and TextureGpu::_autogenerateMipmaps.
Enumerator | |
---|---|
Auto | The texture layout transitions are left to the copy encoder. Texture must NOT be in CopySrc or CopyDst. Texture will be marked as being in ResourceLayout::CopyEncoderManaged in the BarrierSolver Once the copy encoder is closed (e.g. implicitly or calling RenderSystem::endCopyEncoder) all auto managed textures will be transitioned to a default layout and BarrierSolver will be informed |
AlreadyInLayoutThenAuto | Texture is already transitioned directly via BarrierSolver to the expected CopySrc/CopyDst/MipmapGen. Main reason to do this because you were able to group many texture transitions together. Afterwards management is handed off to the Copy encoder: texture is tagged in BarrierSolver as CopyEncoderManaged and behaves like CopyEncTransitionMode::Auto. e.g. solver.resolveTransition( resourceTransitions, src, ResourceLayout::CopySrc,
ResourceAccess::Read, 0u );
renderSystem->executeResourceTransition( resourceTransitions );
src->copyTo( dst, dstBox, 0u, src->getEmptyBox( 0u ), 0u, keepResolvedTexSynced,
@ AlreadyInLayoutThenAuto Texture is already transitioned directly via BarrierSolver to the expected CopySrc/CopyDst/MipmapGen. Definition: OgreTextureGpu.h:240 @ Auto The texture layout transitions are left to the copy encoder. Definition: OgreTextureGpu.h:218 |
AlreadyInLayoutThenManual | Texture is already transitioned directly via BarrierSolver to the expected CopySrc/CopyDst/MipmapGen. After the copyTo/_autogenerateMipmaps calls, caller is responsible for using BarrierSolver again. Note that this can be very dangerous and not recommended! The following code is for example a race condition: solver.resolveTransition( rt, a, ResourceLayout::CopySrc,
ResourceAccess::Read, 0u );
renderSystem->executeResourceTransition( rt );
B->copyTo( A, ... );
C->copyTo( A, ... );
The reason is that there should be a barrier between the 1st and 2nd copy; otherwise C copy into A may start before the copy from B into A finishes; thus A may not fully end up with C's contents. But if you're wary of placing the barriers correctly, you have full control and group as many layout transitions as possible |