Warren Moore

Cool! So the chief thing to understand is that you can encode as much work as you want into a single command buffer; dependencies (between kernels) will be resolved automatically.

The practical upshot of this is that you can try to encode kernels in-place, while providing a backup copy allocator to minimize allocations, but chaining from the output of one kernel to the input of another—even within one command buffer—should “just work.”

All of this goes out the window if you’re using MTLHeap, where accesses are noted less granularly, but I suspect that for now you’re not using heaps?

Nope, not using heaps. The part where I'm kind of stranded is the source and destination textures when I encode the filters, how to make sure these are the right size and set up in the correct way in general.

to explain the situation. Im getting some source image at a 320 x 480 resolution and apply the sobel filter for now. But the result in my mtk view is a tiny rectangle at the top right because of this resolution and so I want to resize the texture before applying the sober filter.

Oh, you want to upsample from the source first? In that case, MPSImageScale up to the desired size (yes, you have to compute the dest size manually); at worst use Lanczos (you probably don’t need it); then feed that to your Sobel.

Sorry if this is obtuse; I really should write a new article about all of this

Ah I didn't even know sobel is only applied to 1:1 aspect images, I'm using it on something 320 x 240. But yes that's exactly what I'm trying to do. So the thing to do is have one intermediate texture of the same size as my drawable?