Hacker News Reader

Comment by verall | Hacker News Reader

> I really hope we'll soon move to a compute-only way of handling graphics

Not happening anytime soon. The industry has lined up pretty solidly behind Khronos/Vulkan.

I know it won't happen overnight, but since it's already possible to do software rasterization for small triangles faster than hardware, having a graphics API framework starts losing its purpose. After all, we want to have the detail of small triangles anyway. Just let us draw to the screen in CUDA without the need for OpenGL/Vulkan interop, and I believe we'll soon see a shift to serious compute-based real-time rendering.

Basically, instead of graphics being a framework, I want graphics to be a straightforward library you include and use in your CUDA/HIP/SYCL/OpenCL code.

> let us draw to the screen in CUDA without the need for OpenGL/Vulkan interop

how would that work? like GPU frameworks would just be compute (like cuda) and some small component of it would just allow to write the end result to a buffer which would be displayed or smth?

Exactly. Things like that already work with a workaround: You can use Cuda-OpenGL interop to expose an OpenGL framebuffer in CUDA, then you can simply write into that framebuffer from your CUDA kernel, and afterwards you get back to OpenGL to display it on screen. Just directly integrate that functionality in CUDA by providing a CUDA native framebuffer and a present(buffer) or buffer swap functionality.

>. The industry has lined up pretty solidly behind Khronos/Vulkan.

What industry? Gaming industry is mostly using DirectX or Gnm/PSSL.

Only if you take a very narrow view of the gaming industry that only includes high end consoles and PCs.

The Nintendo Switch and PCs support OpenGL and Vulkan. But those are both dwarfed by mobile gaming which I think makes up more than half of the entire gaming market, and both iPhone and Android support OpenGL. Although I don't know if the majority of mobile games use it or not.

While switch supports OpenGL and Vulkan, in practice very little games use it. The native API on Switch is a proprietary API called NVN.

OpenGL on Apple is on life support to support existing software, Apple platforms are all in on Metal now.

The only platforms where OpenGL and Vulkan are first class citizens is Linux, Android and Windows (barely). And Vulkan is still second fiddle to DirectX on Windows.

All fair points. However, I was taking issue specifically with the claim that the "Gaming industry is mostly using DirectX or Gnm/PSSL".

It would be hard to quantify exactly how much of it is using OpenGL, as a percentage.

However, for a very rough upper bound I quickly looked up these:

* Mobile gaming apparently makes 52% of the entire gaming market in 2023

* Android is 78% of mobile gaming

That could mean OpenGL makes up to 40% of the entire gaming market just from Android.

Although I have no idea what percentage of Android games use OpenGL and wouldn't know how to look that up. I also don't know how accurate those percentages are. I got them from brief Google queries and got both the 52% and 78% figures from the featured snippet.

But even if that 40% is much too high, we still need to add switch and PC games and I would find a figure of 30% of the gaming industry using openGL to be believable. That would put OpenGL as the largest API which I didn't expect, even as a possibility.

Just to reiterate on this point: Pretty much every Vulkan game on Windows forgoes using Vulkan Swapchains in favor of presenting from compute and using native DXGI Swapchains. If you are shipping a production quality game or application, you really want to use the platforms native APIs to get the full capabilities.

Interesting, like which games? I know RDR2 uses normal Vulkan swapchains.

What percentage of applications *natively* target Vulkan?

Imho Vulkan is the least used of all the APIs if you disregard it as a compatibility layer

The industry targeting Android and GNU/Linux devices, that is.

Reply on news.ycombinator.com