Apple GPUs speculation: TBDR, RT and the benefit of wide ALUs

[diamond.g]

@leman can you talk to why it is slower? Do you think it is an implementation issue?

 

[leman]

@leman can you talk to why it is slower? Do you think it is an implementation issue?

One can't really say much without looking at how it's implemented, especially what their "compute shader mode" really is. I can imagine that the RT API has a certain overhead as it has to take care of more potential cases which might not be relevant to this particular test. At any rate, the performance between Metal RT and the hand-coded compute shader is so small that it's almost negligible. I would imagine that once you add functionality (other intersection functions, custom shading etc. etc.), the difference will become even smaller. In the end, let's not forget that Metal RT on current hardware compiles down to using compute shaders, so a carefully hand written shader that optimizes for the specific use case should be faster.

 

[diamond.g]

One can't really say much without looking at how it's implemented, especially what their "compute shader mode" really is. I can imagine that the RT API has a certain overhead as it has to take care of more potential cases which might not be relevant to this particular test. At any rate, the performance between Metal RT and the hand-coded compute shader is so small that it's almost negligible. I would imagine that once you add functionality (other intersection functions, custom shading etc. etc.), the difference will become even smaller. In the end, let's not forget that Metal RT on current hardware compiles down to using compute shaders, so a carefully hand written shader that optimizes for the specific use case should be faster.

I realized that the dev for that site has an account here and have asked if they plan on adding RT to GravityMark making it the only tool to use available RT API cross platform.