.TH "MPSTemporaryImage" 3 "Mon Jul 9 2018" "Version MetalPerformanceShaders-119.3" "MetalPerformanceShaders.framework" \" -*- nroff -*- .ad l .nh .SH NAME MPSTemporaryImage .SH SYNOPSIS .br .PP .PP \fC#import \fP .PP Inherits \fBMPSImage\fP\&. .SS "Instance Methods" .in +1c .ti -1c .RI "(nonnull instancetype) \- \fBinitWithTexture:featureChannels:\fP" .br .ti -1c .RI "(nonnull instancetype) \- \fBinitWithDevice:imageDescriptor:\fP" .br .in -1c .SS "Class Methods" .in +1c .ti -1c .RI "(nonnull id< MPSImageAllocator >) + \fBdefaultAllocator\fP" .br .ti -1c .RI "(nonnull instancetype) + \fBtemporaryImageWithCommandBuffer:imageDescriptor:\fP" .br .ti -1c .RI "(nonnull instancetype) + \fBtemporaryImageWithCommandBuffer:textureDescriptor:\fP" .br .ti -1c .RI "(nonnull instancetype) + \fBtemporaryImageWithCommandBuffer:textureDescriptor:featureChannels:\fP" .br .ti -1c .RI "(void) + \fBprefetchStorageWithCommandBuffer:imageDescriptorList:\fP" .br .in -1c .SS "Properties" .in +1c .ti -1c .RI "NSUInteger \fBreadCount\fP" .br .in -1c .SH "Detailed Description" .PP \fBMPSImage\fP MPSTemporaryImages are for MPSImages with short lifetimes\&. .PP What is temporary memory? It is memory, plain and simple\&. Analogy: If we use an app as an analogy for a command buffer, then 'Regular memory' (such as what backs a \fBMPSImage\fP or the typical MTLTexture) would be memory that you allocate at launch and never free\&. Temporary memory would be memory that you free when you are done with it so it can be used for something else as needed later in your app\&. You /could/ write your app to allocate everything you will ever need up front, but this is very inefficient and quite frankly a pain to plan out in advance\&. You don't do it for your app, so why would you do it for your command buffers? .PP Welcome to the 1970's! We have added a heap\&. .PP Unsurprisingly, MPSTemporaryImages can provide for profound reduction in the the amount of memory used by your application\&. Like malloc, MPS maintains a heap of memory usable in a command buffer\&. Over the lifetime of a command buffer, the same piece of memory may be reused many times\&. This means that each time the same memory is reused, it aliases with previous uses\&. If we aren't careful, we might find that needed data is overwritten by successive allocations\&. However, this is no different than accessing freed memory only to discover it doesn't contain what you thought it did anymore, so you should be able to keep out of trouble by following a few simple rules, like with malloc\&. .PP To this end, we added some restrictions to help you out and get a bit more performance\&. Some comments are appended in parentheses below to extend the analogy of command buffer = program: .PP .IP "\(bu" 2 The textures are MTLStorageModePrivate\&. You can not, for example, use [MTLTexture getBytes\&.\&.\&.] or [MTLTexture replaceRegion\&.\&.\&.] with them\&. MPSTemporaryImages are strictly read and written by the GPU\&. (There is protected memory to prevent other processes from overwriting your heap\&.) .IP "\(bu" 2 The temporary image may be used only on a single MTLCommandBuffer\&. This limits the chronology to a single linear time stream\&. (The heap is specific to just one command buffer\&. There are no mutexes to coordinate timing of simultaneous access by multiple GPUs\&. Nor are we likely to like them if there were\&. So, we disallow it\&.) .IP "\(bu" 2 The readCount property must be managed correctly\&. Please see the description of the readCount property for full details\&. (The readCount is a reference count for the block of memory that holds your data\&. The usual undefined behaviors apply to reading data that has been released\&. We assert when we can to prevent that from happening accidentally, just as a program might segfault\&. The readCount counts procedural users of the object -- MPSKernel\&.encode\&.\&.\&. calls that read the \fBMPSTemporaryImage\fP\&. As each reads from it, the readCount is automatically decremented\&. The texture data will be freed in typical usage at the right time as the readCount reaches zero, typically with little user involvement other than to set the readCount up front\&. We did examine using the main \fBMPSTemporaryImage\fP reference count for this instead so that ARC would do work for you automatically\&. Alas, ARC destroys things at end of scope rather than promptly, sometimes resulting in greatly increased memory usage\&. These allocations are large! So, we use this method instead\&.) .PP .PP Since MPSTemporaryImages can only be used with a single MTLCommandBuffer, and can not be used off the GPU, they generally should not be kept around past the completion of the MTLCommandBuffer\&. The lifetime of MPSTemporaryImages is expected to be typically extremely short, perhaps only a few lines of code\&. Like malloc, it is intended to be fairly cheap to make MPSTemporaryImages and throw them away\&. Please do so\&. .PP To keep the lifetime of the underlying texture allocation as short as possible, the underlying texture is not allocated until the first time the \fBMPSTemporaryImage\fP is used by a \fBMPSCNNKernel\fP or the \&.texture property is read\&. The readCount property serves to limit the lifetime on the other end\&. .PP You may use the \fBMPSTemporaryImage\&.texture\fP with \fBMPSUnaryImageKernel\fP -encode\&.\&.\&. methods, iff featureChannels <= 4 and the MTLTexture conforms to requirements of that \fBMPSKernel\fP\&. There is no locking mechanism provided to prevent a MTLTexture returned from the \&.texture property from becoming invalid when the readCount reaches 0\&. .PP Finally, MPSTemporaryImages are complicated to use with blit encoders\&. Your application should assume that the \fBMPSTemporaryImage\fP is backed by a MTLHeap, and consequently needs a MTLFence to ensure that compute command encoders and other encoders do not trip over one another with heap based memory\&. MPS will almost never use a blit encoder for this reason\&. If you do need one, then you will need to make a new compute encoder to block on whatever previous compute encoder last used the heap block\&. (MPS will not tell you who previously used the heap block\&. That encoder is almost certainly long dead anyway\&.) If concurrent encoders are involved, then a barrier might be needed\&. Within that compute encoder, you will call -updateFence\&. End the compute encoder, make a blit encoder wait for the fence, do the blit, update a new fence, then make a new compute encoder, wait for the second fence, then you can continue\&. Possibly the second do-nothing compute encoder needs to be ended so MPS can be called\&. Frankly, we don't bother with blit encoders and just write a compute operation for copy / clear as needed, or better yet find a way to eliminate the clear / copy pass so we don't have to pay for it\&. Note: the most common use of a blit encoder, -synchronizeResource: can not encounter this problem because MPSTemporaryImages live in GPU private memory and can not be read by the CPU\&. .PP MPSTemporaryImages can otherwise be used wherever MPSImages are used\&. .SH "Method Documentation" .PP .SS "+ (nonnull id ) defaultAllocator " Get a well known MPSImageAllocator that makes MPSTemporaryImages .PP Reimplemented from \fBMPSImage\fP\&. .SS "\- (nonnull instancetype) initWithDevice: (nonnull id< MTLDevice >) device(const \fBMPSImageDescriptor\fP *__nonnull) imageDescriptor" Unavailable\&. Use itemporaryImageForCommandBuffer:textureDescriptor: instead\&. .PP Reimplemented from \fBMPSImage\fP\&. .SS "\- (nonnull instancetype) initWithTexture: (nonnull id< MTLTexture >) texture(NSUInteger) featureChannels" Unavailable\&. Use temporaryImageForCommandBuffer:textureDescriptor: or -temporaryImageForCommandBuffer:imageDescriptor: instead\&. .PP Reimplemented from \fBMPSImage\fP\&. .SS "+ (void) prefetchStorageWithCommandBuffer: (nonnull id< MTLCommandBuffer >) commandBuffer(NSArray< \fBMPSImageDescriptor\fP * > *__nonnull) descriptorList" Help MPS decide which allocations to make ahead of time The texture cache that underlies the \fBMPSTemporaryImage\fP can automatically allocate new storage as needed as you create new temporary images\&. However, sometimes a more global view of what you plan to make is useful for maximizing memory reuse to get the most efficient operation\&. This class method hints to the cache what the list of images will be\&. .PP It is never necessary to call this method\&. It is purely a performance and memory optimization\&. .PP This method makes a conservative estimate of memory required and may not fully cover temporary memory needs, resulting in additional allocations later that could encounter pathological behavior, if they are too small\&. If the full extent and timing of the workload is known in advance, it is recommended that \fBMPSHintTemporaryMemoryHighWaterMark()\fP be used instead\&. .PP \fBParameters:\fP .RS 4 \fIcommandBuffer\fP The command buffer on which the MPSTemporaryImages will be used .br \fIdescriptorList\fP \fBA\fP NSArray of MPSImageDescriptors, indicating images that will be created .RE .PP .SS "+ (nonnull instancetype) temporaryImageWithCommandBuffer: (nonnull id< MTLCommandBuffer >) commandBuffer(const \fBMPSImageDescriptor\fP *__nonnull) imageDescriptor" Initialize a \fBMPSTemporaryImage\fP for use on a MTLCommandBuffer .PP \fBParameters:\fP .RS 4 \fIcommandBuffer\fP The MTLCommandBuffer on which the \fBMPSTemporaryImage\fP will be exclusively used .br \fIimageDescriptor\fP \fBA\fP valid imageDescriptor describing the \fBMPSImage\fP format to create\&. .RE .PP \fBReturns:\fP .RS 4 \fBA\fP valid \fBMPSTemporaryImage\fP\&. The object will be released when the command buffer is committed\&. The underlying texture will become invalid before this time due to the action of the readCount property\&. .RE .PP .SS "+ (nonnull instancetype) temporaryImageWithCommandBuffer: (nonnull id< MTLCommandBuffer >) commandBuffer(const MTLTextureDescriptor *__nonnull) textureDescriptor" Low level interface for creating a \fBMPSTemporaryImage\fP using a MTLTextureDescriptor This function provides access to MTLPixelFormats not typically covered by -initForCommandBuffer:imageDescriptor: The feature channels will be inferred from the MTLPixelFormat without changing the width\&. The following restrictions apply: .PP .nf MTLTextureType must be MTLTextureType2D or MTLTextureType2DArray MTLTextureUsage must contain at least one of MTLTextureUsageShaderRead, MTLTextureUsageShaderWrite MTLStorageMode must be MTLStorageModePrivate depth must be 1 .fi .PP .PP \fBParameters:\fP .RS 4 \fIcommandBuffer\fP The command buffer on which the \fBMPSTemporaryImage\fP may be used .br \fItextureDescriptor\fP \fBA\fP texture descriptor describing the \fBMPSTemporaryImage\fP texture .RE .PP \fBReturns:\fP .RS 4 \fBA\fP valid \fBMPSTemporaryImage\fP\&. The object will be released when the command buffer is committed\&. The underlying texture will become invalid before this time due to the action of the readCount property\&. .RE .PP .SS "+ (nonnull instancetype) temporaryImageWithCommandBuffer: (nonnull id< MTLCommandBuffer >) commandBuffer(const MTLTextureDescriptor *__nonnull) textureDescriptor(NSUInteger) featureChannels" Low level interface for creating a \fBMPSTemporaryImage\fP using a MTLTextureDescriptor This function provides access to MTLPixelFormats not typically covered by -initForCommandBuffer:imageDescriptor: The number of images will be inferred from number of slices in the descriptor\&.arrayLength and the number of feature channels\&. .PP The following restrictions apply: .PP .nf MTLTextureType must be MTLTextureType2D or MTLTextureType2DArray MTLTextureUsage must contain at least one of MTLTextureUsageShaderRead, MTLTextureUsageShaderWrite MTLStorageMode must be MTLStorageModePrivate .fi .PP .PP \fBParameters:\fP .RS 4 \fIcommandBuffer\fP The command buffer on which the \fBMPSTemporaryImage\fP may be used .br \fItextureDescriptor\fP \fBA\fP texture descriptor describing the \fBMPSTemporaryImage\fP texture .RE .PP \fBReturns:\fP .RS 4 \fBA\fP valid \fBMPSTemporaryImage\fP\&. The object will be released when the command buffer is committed\&. The underlying texture will become invalid before this time due to the action of the readCount property\&. .RE .PP .SH "Property Documentation" .PP .SS "\- (NSUInteger) readCount\fC [read]\fP, \fC [write]\fP, \fC [nonatomic]\fP, \fC [assign]\fP" .SH "Author" .PP Generated automatically by Doxygen for MetalPerformanceShaders\&.framework from the source code\&.