Simple Metal apps without buffers and semaphore?

OK, I thought that when we have 3 buffers and semaphore with value: 3, we are doing triple buffering. With 2, we have double buffering. But now you are explaining that the GPU has a "hidden" double buffering as well? Or it is just a framebuffer for v-sync?

Anyway, the practical part which I'm interested in, is what strategy would provide the best input-to-photon latency. Say you make the screen white if the user presses a button or touches the screen. What kind of Metal application would give the lowest latency here?

"Since the render loop is limited to 60 FPS and the frame time is about 1.5 ms for the CPU (in case of a simple example), some command has to take the place of the blocking semaphore, right?"

That's right. It is when your code try to get the next drawable the call will block to prevent you from reaching beyond the FPS limit. However, this type of blocking is unpredictable and your code won't have a reliable way to determin how many buffers to circle among. Your code will occasionly run into buffer corruption.

Why would it be unpredictable? Just some data is added to the encoder. There are no buffers, just copying small amounts of data from CPU -> GPU memory.

But I'm only been playing with apps like this, so I have no idea how will it work in production.

Your shader and your encoding code are running asynchrously on GPU and on CPU respectively. You need to use different buffer to encoding for different frames or the encoding code will corrupt what your shader will be reading. Since your buffer can not be inifite, you have to circle through a finite number of buffers. Without proper semaphore, you have no way to decide how you circel through.

If you're using set[Vertex|Fragment]Bytes to send data to you shaders (and thus the GPU) it won't be unpredictable. But if you're using a single buffer with set[Vertex|Fragment]Buffer to send data, when you write to the buffer with your application (i.e. with the CPU) and your shader (i.e. the GPU) reads from that same buffer, if there's no synchronization, that write could occur before or after the GPU has read the data. So there's no telling whether the GPU will read the value that was there before the write or what was after the write.

The CPU and GPU Synchronization Metal sample dicusses this topic.

Just found that if I do not add the last line of the following code, the app may crash, so for a simple usage of Metalkit, blocking until command buffer complete is a good idea.

[renderEncoder endEncoding];

// Schedule a present once the framebuffer is complete using the current drawable

[commandBuffer presentDrawable:self.view.currentDrawable];

[commandBuffer commit];

// block until command buffer complete.

[commandBuffer waitUntilCompleted];