in-place processing of a texture

Is it possible to process an MTLTexture in-place without osx_ReadWriteTextureTier2?


It seems like I can set two texture arguments to be the same texture. Is this supported behavior?


Specifically, I don't mind not having texture caching update after a write. I just want to in-place (and sparsely) modify a 3d texture. It's memory prohibitive to have two textures. And it's computationally expensive to copy the entire texture, especially when I might only be updating a small portion of it.


thanks!

Replies

That question really interested me and I just ran self-written gaussian blur kernel on same bound read/write texture on iPhone 6 plus and iPhone 5s... it worked just fine. Actually, I expected it to crash with some internal Metal assertion error. It's not sparse case and not 3d though, but I guess the only way you can figure that out - is to try by yourself.

I believe that every single graphic API I saw had "undefined behavior" in the specs with regard to reading/writing same texture. So, unless it is specifically allowed (just like with osx_ReadWriteTextureTier2) it should be considered dangerous. You may get away with it on some hardware/texture format/cases, but do not assume it will work on other hardware/in other situations.


What I did several times, when I could not allocate second copy of whole texture is allocate only small "worker area", copy relevant pictures out there in stage 1 and come back writing to original texture in state 2. I am not aware of any other way, sorry.


Micha

It is undefined behavior. Getting away with it now doesn't mean you'll continue to do so as the system evolves, or in all situations and timing behaviors. Unfortuantely you'll have to use two textures here.