OGRE-Next  4.0.0unstable
Object-Oriented Graphics Rendering Engine
Ogre::CopyEncTransitionMode Namespace Reference

Enumerations

enum  CopyEncTransitionMode { Auto , AlreadyInLayoutThenAuto , AlreadyInLayoutThenManual }
 Copy Encoder Transition modes to be used by TextureGpu::copyTo and TextureGpu::_autogenerateMipmaps. More...
 

Enumeration Type Documentation

◆ CopyEncTransitionMode

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,
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
@ Read
Definition: OgreResourceTransition.h:77
@ CopySrc
Definition: OgreResourceTransition.h:58
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,
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