GL_vs_VK: A Micro-Benchmark Looking At The Overhead Of OpenGL vs. Vulkan APIs

[phoronix]

Phoronix: GL_vs_VK: A Micro-Benchmark Looking At The Overhead Of OpenGL vs. Vulkan APIs

GL_vs_VK is self-described as a "comparison of OpenGL and Vulkan API in terms of performance" and offers multiple test-cases for directly comparing OpenGL and Vulkan in different environments. Here are some benchmarks on several different drivers and GPUs.

http://www.phoronix.com/vr.php?view=24755

[Danny3]

Very interesting!
Congrats to Damian Dyńdo for making this benchmark and for being open to make it automated.

[bug77]

It doesn't look right. Vulkan was supposed to be a thin layer that would put the full power of the hardware in the hands of the application. Yet AMD still trails, even it has the horse power. Intel also seems to punch way above their weight. So maybe these benchmarks need a few more iterations?
Still, thanks for adding them Michael.

[schmidtbag]

I think this is a great idea for a set of tests, but I'm a little suspicious about the credibility of the tests. The results are all a little too consistent considering the numbers, and Vulkan's performance usually doesn't vary that drastically from OpenGL (especially at such low framerates).

I think perhaps there may be a CPU overhead issue.

[Herem]

The maximum frame rates for the Vulkan tests might be a problem. Even a single data point measured at several million fps might be enough to lift the overall average notably.

[bug77]

The maximum frame rates for the Vulkan tests might be a problem. Even a single data point measured at several million fps might be enough to lift the overall average notably.

Usually that's not how you compute an average, but yes, if it's just a plain averaging of all values, it could skew the results.

[bakgwailo]

It doesn't look right. Vulkan was supposed to be a thin layer that would put the full power of the hardware in the hands of the application. Yet AMD still trails, even it has the horse power. Intel also seems to punch way above their weight. So maybe these benchmarks need a few more iterations?
Still, thanks for adding them Michael.

Eh, I would guess it is AMD's Vulkan driver. The closed one seems to have its own set of issues, and the (3rd party) open source radv driver isn't even certified yet (and has lots to still progress on).

[marek]

I think this is a great idea for a set of tests, but I'm a little suspicious about the credibility of the tests. The results are all a little too consistent considering the numbers, and Vulkan's performance usually doesn't vary that drastically from OpenGL (especially at such low framerates).

I think perhaps there may be a CPU overhead issue.

What? The tests were designed to be limited by the CPU. That was the whole point.

[karolherbst]

What? The tests were designed to be limited by the CPU. That was the whole point.

I am sure he meant inside the vulkan driver

[Herem]

Usually that's not how you compute an average, but yes, if it's just a plain averaging of all values, it could skew the results.

The Vulkan averages in these tests are typically 6+ times higher than the OGL results. Judging by this abnormally high difference compared to other benchmarks contrasting both APIs, I think it is reasonable to at least look into the way the results are being calculated to ensure these spurious values are not skewing the overall results.