So ... maybe I'm not fully understanding, but what you're suggesting is that there's a bug for MacOS that produces scores that are not truly representative of the real relative power of the gpu? If so, then the Mac version of your program is effectively worthless, correct?We released a new version with leaderboard support.
The performance of Metal API is more than twice lower than Direct3D12/Vulkan running exactly the same HW:
Metal 34 FPS:
D3D12 80 FPS:
Maybe the same issue makes Apple M1 performance is lower than AMD APU:
Apple M1 13 FPS:
AMD APU 16 FPS:
We are trying to resolve this situation with Apple. But we cannot do it alone.
The problem is that there is no effective way to draw thousands of objects by using Metal API.
Mesh shaders require the latest (RTX / RX 6XXX) GPU. Metal API and all mobile devices don't support Mesh shaders now.
Yes, instanced rendering can draw a huge number of objects. The problem is that the CPU cannot prepare data for GPU with a reasonable FPS, especially when the number of more than 100k and the scene is fully dynamic. GPU can be used for scene processing and draw commands generation with unbeatable performance.
Metal API allows using only single draw command for indirect rendering. It means that there is no way to draw different geometry in a single command. And each geometry variation should use separate draw command:
drawIndexedPrimitives:indexType:indexBuffer:indexBufferOffset:indirectBuffer:indirectBufferOffset: | Apple Developer Documentation
Encodes a draw command that renders multiple instances of a geometric primitive with indexed vertices and indirect arguments.developer.apple.com
Other API except D3D11 and OpenGLES have multi-draw-indirect-count functionality where it's possible to combine multiple draw-indirect commands in a single API call. And no CPU-GPU synchronization is required for that:
We are emulating multi-draw-indirect-count functionality as a loop of draw indirect commands for D3D11, OpenGLES, and Metal. This emulation is working even faster for the previous Nvidia GPU generation because of the driver issue:
D3D11 71 FPS (GTX 1060):
Vulkan 58 FPS (GTX 1060):
But unfortunately, not in the case of Metal API, where the same HW is three times slower.
Metal API supports indirect command buffers. Our test demonstrates that they are slower than the loop of simple indirect draw commands. That makes them practically useless. Or maybe only the next Apple HW will have benefits from them.
View attachment 1810390
View attachment 1810391
Yep, that issue is on the Metal support forum without any progress.
which is great, except for the totally unconfigurable API.
Ok, the technical details are over my head, but what I am hearing is that your test is indeed worthless for MacOS.
The purpose of this benchmark is to showcase the problem of macOS with heavy applications. I don't think that it's normal to have access only to 30% of possible hardware capabilities. But it's definitely good to demonstrate M1 performance.Ok, the technical details are over my head, but what I am hearing is that your test is indeed worthless for MacOS.
There are many other graphics tests that don't expose the 'bug' (or whatever the problem is between your program and Metal) so the take-away here is that we might as well use any number of the graphics tests for Macs that actually do produce correct and comparable scores.
The purpose of this benchmark is to showcase the problem of macOS with heavy applications. I don't think that it's normal to have access only to 30% of possible hardware capabilities. But it's definitely good to demonstrate M1 performance.
Having its own proprietary graphics API is great for Apple. But it should be at least not worse than analogs.
// macOS Metal rendering loop code:
for(uint32_t i = 0; i < num_draws; i++) {
[encoder drawIndexedPrimitives:primitive_type indexType:index_type indexBuffer:index_buffer indexBufferOffset:index_offset indirectBuffer:indirect_buffer indirectBufferOffset:offset];
offset += stride;
}
// Vulkan rendering code:
vkCmdDrawIndexedIndirectCount(command, indirect_buffer, indirect_offset, buffer, offset, num_draws, stride);
// Direct3D11 AMD rendering code:
agsDriverExtensionsDX11_MultiDrawIndexedInstancedIndirect(context->content, command, num_draws, indirect_buffer, indirect_offset, stride);
// Direct3D11 Nvidia and Intel rendering loop code:
for(uint32_t i = 0; i < num_draws; i++) {
command->DrawIndexedInstancedIndirect(indirect_buffer, offset);
offset += stride;
}
// Direct3D12 rendering code:
command->ExecuteIndirect(signature, num_draws, indirect_buffer, indirect_offset, buffer, offset);
// OpenGL rendering code:
glMultiDrawElementsIndirectCount(draw_mode, index_type, indirect_offset, offset, num_draws, stride);
// OpenGLES rendering loop code:
for(uint32_t i = 0; i < num_draws; i++) {
glDrawElementsIndirect(draw_mode, index_type, offset);
offset += stride;
}Yes, the RT version of GravityMark will be released this year.
Yes, there is good progress with the driver. The same code is started to work with the new OS version.
Is there a way to re-run the benchmark without having to quit the app?iOS version is available in the App Store:
GravityMark GPU Benchmark
GravityMark GPU Benchmark demonstrates the capabilities of modern GPUs by rendering an enormous quantity of objects in real-time, utilizing GPU acceleration. We avoid typical CPU-based performance bottlenecks by delegating the entirety of scene management and rendering steps exclusively to the...apps.apple.com
Demo mode is infinity loop mode without calculating the score. Devices are getting hot after a single benchmark loop, and results are dropping dramatically due to thermal throttling. We can add multiple benchmark iterations, but it will have no sense in terms of benchmark results.