Vulkan undergoing major API shift

dada_dave

Elite Member
Posts
2,134
Reaction score
2,123
I wouldn't in a million years start a project using a framework that is obviously being on its way out and has clear, mature alternatives. Like. The writing is on the wall. Apple stopped updating OpenGL after 2010. Metal was released in 2014. Vulkan was released in 2016. OpenGL's last version was 4.6, in 2017. And Apple officially deprecated OpenGL in 2019. How long until they remove it altogether? It would simplify both software and hardware development (I seem to recall people from the Asahi project saying that Apple Silicon GPUs still have hardware features to make OpenGL support easier/more performant, but don't quote me on this).

Obviously not everything revolves around Apple, and I'm less aware of what other hardware vendors are doing, but it's my understanding that, even while actively supported, OpenGL performance is less and less relevant, and most metrics use Vulkan benchmarks/games. In a world with high core count CPUs, OpenGL has poor multithreading support. And new features (i.e. NVIDIA's DLSS, raytracing...) aren't ever going to come to OpenGL, so... kind of a dead end IMHO. I wouldn't start a project with it, even if it's higher level and easier to write for. Specially not if (as it seems to be the case) I want to be able to run it on Apple platforms.
While I’m not in a position to dispute either you or the above article, I believe his position was that it will live on through three types of apps:

1) legacy code based which already run well in OpenGL and the cost of porting to Vulkan/Metal/DX12 wouldn’t be justifiable.

2) new applications where performance simply isn’t needed and the speed of development is much greater with OpenGL.

3) WebGL as @leman already mentioned.

I think the #2 is the point of most contention. But I think in all cases his argument is that even if Apple (and others) gets rid of official OpenGL support, it’s so easy to glue OpenGL onto Vulkan/Metal that it’s still worth it and again for many of these projects any performance hit from doing so would simply not be noticeable.

(I seem to recall people from the Asahi project saying that Apple Silicon GPUs still have hardware features to make OpenGL support easier/more performant, but don't quote me on this).

Yup. That’s true.
 

Andropov

Site Champ
Posts
615
Reaction score
773
Location
Spain
While I’m not in a position to dispute either you or the above article, I believe his position was that it will live on through three types of apps:

1) legacy code based which already run well in OpenGL and the cost of porting to Vulkan/Metal/DX12 wouldn’t be justifiable.

2) new applications where performance simply isn’t needed and the speed of development is much greater with OpenGL.

3) WebGL as @leman already mentioned.

I think the #2 is the point of most contention. But I think in all cases his argument is that even if Apple (and others) gets rid of official OpenGL support, it’s so easy to glue OpenGL onto Vulkan/Metal that it’s still worth it and again for many of these projects any performance hit from doing so would simply not be noticeable.
Oh yeah. He's not wrong we'll have OpenGL around for ages. In cases like 1), I can understand. Cases like 2) are the ones that bother me. I'm not saying it doesn't happen, quite the opposite, just that it bothers me that it does. I fear the OpenGL deprecation will be another several-decades-long transition, like the 32->64 bits one.
 

dada_dave

Elite Member
Posts
2,134
Reaction score
2,123
Oh yeah. He's not wrong we'll have OpenGL around for ages. In cases like 1), I can understand. Cases like 2) are the ones that bother me. I'm not saying it doesn't happen, quite the opposite, just that it bothers me that it does. I fear the OpenGL deprecation will be another several-decades-long transition, like the 32->64 bits one.
Aye I hear what you’re saying but surely not as bad? If it’s correct that OpenGL can simply be emulated in Vulkan and the remaining use cases are not performance limited then device makers will have little issue removing OpenGL cruft if it’s starting to get in the way of cleaner hardware since those applications will still just work. The 32-64 bit transition was more pernicious as plenty of 32-bit applications still required performance guarantees that for a long time CPUs simply couldn’t deliver without the necessary support in hardware itself.

Also, from what I gather reading reverse engineers (especially Alyssa from Asahi) talking about GPUs from Nvidia and AMD, they have way more legacy cruft and wonky design issues from their history to unwind than just OpenGL acceleration in hardware and Apple will undoubtedly be as ruthless as it feels it needs to be in terms of those legacy features.
 

leman

Site Champ
Posts
631
Reaction score
1,172
Aye I hear what you’re saying but surely not as bad? I

It's bad simply because it promotes bad code and bad coding practices. I mean, we still have people recommending to learn OpenGL first, cause it's "easier", never mind that it's building a bad conceptual model of GPU programming...

Personally, I blame Vulkan. It is just such a terrible API to use. If they would have made it adaptive, transition from OpenGL would be so much easier.
 
Top Bottom
1 2