One part of the reason for this, is that using Swift is ironically slow and inefficient compared to C, and not appropriate if your real goal is performance and maximizing the capability of the hardware. In most all serious scientific applications, games, art tools, etc. where the Metal is to be used, there is a large amount of memory and data that is to be managed, transformed, and passed around to and from the cpu and gpu. Using Metal itself might imply the developer is trying to get the full performance or stability possible at the sacrifice of ease of use or any other benefit the Swift coder might believe they are gaining. So to combine something inefficient like Swift with Metal is a bit of strange practice for a use case where we sincerely are maximizing the potential of the hardware. What exactly is the developer trying to achieve by going only part way? Perhaps they are just following the cultural fads or caught up in novelty, and not measuring, or perhaps they are doing something where they just do not care about the performance consequences. Most of the Swift architecture and syntax choices over the years have reflected strange preferences of the community, that don't align with clear rationality, so I don't think it's something the community can readily engage a logical dialog about, without also confronting the irrationality of many ideas that were already adopted. In any case, the typical lesson here, is to avoid the tendency to try to learn by example - not to learn by reading other people's code, but to come to understand the fundamentals. Then you will understand how to build anything, and clearly see the limits, problems, and incorrect practices of publicly published examples.

It might be the distinction between linear/sRGB/gamma. If it is, you could just change your pixel formats, or perform the appropriate equations in the shader.

Simple answer: You pass your buffer to your kernel, write to your texture, and then render the texture on screen as appropriate for your specific circumstance. If you are performing intensive calculations, then the answer to 'what is the boilerplate for me', would be decided based on the specifics of your situation. You mention that you don't need vertex shaders and primitives, but those are in fact, how you would get the texture onto the screen. And depending on your specific use case, will change how you architect the pipeline in your cpu code - and that part may be large for intense and complex calculations. Aside: I find, the metal developer community feels small, with a minority who are familiar with the entirety of it, and even Apple employees can be found to be unknowledgeable about simple things. (I had to find out the hard way - by building endless tests to measure and assess each thing myself.) Because of this, you are unlikely to find quality sample code anywhere online. Even if you do, the specifics of that sample may be incorrect for you. Frequently, when you want to do one thing in combination with other things, you have to change how you do both. Because of this, when asking for a boilerplate for one thing, it is likely not what you will truly need for the real use case - causing you to either ask a second time for something else, or settle for something significantly inefficient just because that's what you got working. That isn't a great approach. And there are enough options in the possibility space, that I wouldn't be able to predict exactly what applies to you without a very thorough description of everything. The more specific and clear you are about the entirety of your application use case, the more likely you will be to get not just an answer, but one that is the most correct answer for you in that specific circumstance. However, an even better position for you to take, would be to less be concerned with trying to achieve your goal, and more concerned about trying to understand the fundamentals of the system more thoroughly, so that you could design architectures on your own, and know why things need to be a certain way. Then, when you came to ask for help, your questions would be less related to a lack of understanding basic things, and more related to Apple's bugs or the cutting edge algorithm you're trying to implement. If we can foster that level of thoroughness in the developer culture outside Apple, then we might see Apple follow along and adopt a culture of higher standards in their foundation software and hardware.

I just checked the project files... It is as I stated in my first reply, you need to ensure the texture settings match, and then you will not get the error regarding the textures. After you change to rgba16 in both places (such as kCVPixelFormatType_64RGBAHalf), you will then be confronted by another texture setting match problem for the texture in the second attachment. Since you are overriding the render pass descriptor for SceneKit, it would be logically assumed that you then have to create and setup that texture on your own. If you spend more time with Metal, these things will be more obvious as they are very normal things. I will leave that to you to complete, but I will say that the entire thing is clunky, extremely inefficient, and I would not personally recommended following this sample code's strategy or even using SceneKit or Swift. The use of AVAssetWriter is also not recommended. These, in their current form today and in the past, are Apple's half-baked attempts at providing convenience with a heavy price. There is little expectation based on Apple's prior results, that the standards of quality will change anytime soon. (Even though I hope for that every day) I would instead recommend avoiding as many Apple frameworks as you can, and becoming more familiar with Metal and C, and get to your goals that way.

I missed your link earlier... I'll take a look tonight, did you first double check that isJitteringEnabled is in fact working as of today in a scenekit project without the rest of that sample project? SceneKit is notorious for having bugs. So you should confirm that first. Then you should try changing Scenekit to rgba16 without the rest of that sample project. If you run into the same error, you'll know that you still need to change the texture settings.

It's telling you that your texture descriptor settings are incorrect relative to your other settings. Notice how the number is exactly 1/2. Based on the limited information you wrote, it is expected because you went from BGRA8 to RGBA16, which is twice the size.