It is recommended to continue to launch OPENGL 5.0 and make it fully support multi-core CPUs

It is recommended to continue to launch OPENGL 5.0 and make it fully support multi-core CPUs.
It is obviously unwise to give up updating OPENGL because many people are using it.
Please don’t recommend VULKAN to me. I don’t like it. It is not suitable for personal customization engine developers.
VULKAN is very powerful. It can do more things. It is very detailed and close to the bottom. It can improve the utilization of CPU multi-core. And it supports a lot of platforms. Unlike OPENGL, GL is rejected by MAC. STEAM is also optimistic about the future.
But it is more difficult to use (about ten times more difficult than OPENGL). It is more complicated than GL, just like using assembly code to develop drivers.
I need to write 1000 lines of code to display a triangle (I only need more than 100 lines of code for OPENGL). I need to spend several years more time learning and developing an engine than OPENGL. Every time I add a function, I have to add about 100 lines of code. Gosh!
This is a huge threshold for individual game developers. It is almost impossible.
Please don’t only care about company level programmers and ignore our personal needs.
We don’t need the powerful and detailed functions of VULKAN. We just need OPENGL that is easy to use, simple and supports multi-threading rendering (GL’s support for multi-threading is bad enough now).
So, just update 5.0. There is no need to create a context, more powerful functions (such as ray tracing), or compatibility with previous code. We (refer to game developers) can make local modifications.
You can learn the transformation from DX10 to DX12. DX12 can be incompatible with DX10, so OPENGL 5.0 can also be incompatible with 4.6.
The main task is to make it really support multi-core CPUs. You can’t let the CPU work with only two cores. OPENGL cannot be completely discarded because it has historical baggage,
Then he ran to VULKAN and announced OPENGL was dead and would not be updated. And forced us to use VULKAN (because only VK can support multi-threading and cross-platform, we have no choice)
I think VULKAN is absolutely impossible to replace OPENGL because it is difficult to learn and use. Some people (like me) will never accept it.
If what I said makes some people unhappy, I apologize, but this is where I am angry. I hope you can listen. thank you

Who is “he” in this context? Who “forced us to use VULKAN”? Up until this point, you didn’t see to be talking about a specific person or incident.

Vulkan and D3D12 are comparable in their complexity, for the most part. Vulkan is generally rather more wordy, but that’s a function of the way its API works.

At the end of the day, what you seem to want is not “OPENGL 5.0” (BTW, putting names in ALL CAPS makes it seem like you’re shouting. They’re properly written as “Vulkan” and “OpenGL”). If you’re fine with a complete API compatibility break, then what you seem to want is just a command-buffer-style rendering API that’s easier to use (in some respect) than Vulkan.

Well… can’t you write that yourself? Or get together with a group of people and write it? I mean, you yourself know what you feel the pain points of Vulkan usage are than we do. So you could build a higher level interface that translates down to Vulkan code.

Sorry, English is not my first language, so there are some mistakes in expression.

I mean that KHR focused on VULKAN without updating OPENGL, which caused us to be forced to turn to VULKAN, which is unacceptable. Do you understand this passage?

You don’t need to tell me the difference between VULKAN (and DX12) and the old API. I know this is how they work. But I still don’t want to choose this kind of low-level API. I like high-level APIs (such as GL or DX11).


You misunderstand me. I need OPENGL 5.0 more than anyone else. The current OPENGL cannot meet the needs of modern times, but KHR has not updated them or added patches to them.

Should old languages and APIs be abandoned? C++is also a very old language, and it has not been eliminated yet. It still continues to move forward. Why does KHR not learn from the father of C++? Make it more modern?

If I can write my own API, I don’t need to come here to feed back these problems and requirements.

I just need to shut up and write C’s graphic code base.

Just like some people insist on using only C # or Java to write programs, they will not return to C language and assembly language.
We are similar users, so Vulkan is not suitable for us.
We need high-level APIs (supporting multithreaded rendering), which need the standards formulated by KHR, and many hardware manufacturers to follow up and support.

Why do “hardware manufacturers” need to “support” this? Vulkan is perfectly serviceable as a back-end for building the kind of high-level API you want.

Also, who is “we” in this example? “We” seems to be a group of people who care enough about rendering performance to want “multithreaded rendering”, but do not care enough about rendering performance to want anything else that Vulkan provides (explicit memory management, so nobody is going behind your back to shuffle stuff around, etc).

Indeed, that is part of the problem with this suggestion: it simply is not clear which low-level parts of Vulkan you want and which parts you don’t. This dovetails with the fact that some of the things you want need things you probably don’t want.

You cite “multithreaded rendering”, but what about explicit synchronization? That kind of goes hand-in-hand with command buffers; it’s hard to have one without the other (this is why both DX11’s deferred context idea and NVIDIA’s command list extension failed).

You want to do ray tracing. OK fine, but… that’s a thing that requires explicit memory management (among other things). You need to lock memory down to specific address ranges; you can’t have a system going behind your back and moving data around the way OpenGL implementations are allowed to.

My point here is that many of the features you’re asking for are inherently dependent upon the complexities that Vulkan introduces. You can’t have one without the other.

The market essentially bifurcated. On the one hand, hardware-implemented graphics APIs got lower-level. But on the other hand, graphical engines got higher-level. These are the real “high-level APIs”. So what exactly is the use-case for something in-between?

If I want to make a game, I should use a game engine. That will take care of all of the little details I don’t care about and allow me to focus on the game development, not poking around with the details of issuing graphics calls. If I want to make a game engine, then I want the lowest-level tools available so that I can craft that engine to the needs of those using said engine.

So who exactly is it that will use this hypothesized “high-level API”? The only use case I can come up with is being a platform for hobbiests to play around with. And that’s fine, but… why should “hardware manufacturers” spend precious time creating and maintaining that, when someone could just build such a library atop Vulkan?

I’m not saying that such a tool should not exist. I’m asking why it is specifically Khronos’s responsibility to build it.

1 Like

I think I made it clear.
You mean that I just need to use Vulkan to build everything I need.
But what I want is ready-made out-of-the-box APIs, rather than rebuilding any backend with VK.
You don’t understand my needs at all, but you want me to change everything by using VK, which is impossible.
I have said that I don’t want to use VK, including using it to build a backend. thank you

Do you mean that people who use Java and C # are amateurs? They don’t deserve to create games? That’s just your subjective idea. I think your words are a bit offensive. Please have a friendly discussion. If you don’t agree, you should not continue to follow my topic. Thank you.

That’s where we come to a bit of a problem. I don’t agree that you have expressed any “needs” here. It seems to me that what you have expressed is a series of wants.

A “want” only becomes a “need” if what you want is a thing you have to do and there is no other way to get what you want. Vulkan was needed by game developers because the existing graphics APIs were such a poor fit to the structure of modern GPUs that they were getting in the way of performance. The fact that there was no alternative way to access modern GPUs made command buffer APIs a “need”.

And fulfilling that “need” could only be done through explicit IHV intervention. That’s why it was necessary for a consortium like Khronos to get involved.

You prefer to work with a higher-level API. That’s not a necessity by what you’re doing; you could take the time to learn a lower-level API. But you choose not to. And that’s fine.

You could work with a rendering engine. But you choose not to. And that’s fine.

What isn’t fine is claiming that these personal choices now constitute a “need”. Because it isn’t; it’s simply the consequences of your choices.

This is particularly interesting in light of the following:

I really don’t understand this. Why does it matter if the API you use itself uses Vulkan as a backend? As long as the API doesn’t surface anything related to Vulkan, you would be unable to even tell that it’s using Vulkan. If you never have to see the Vulkan code, could you even tell the difference?

To use your analogy, if someone wrote a C# implementation that converted C# into C and then used a C compiler to do JIT compilation… would you care? Outside of the possibility that it might be slower at JIT than a native C# JIT system, what does it matter? Your C# code will work just fine either way, right?

My issue with you calling this a “need” comes to a head here. Because you’re effectively dismissing every alternative possibility, everything that could solve your problem other than the specific solution you desire.

That doesn’t really indicate to me that you have a problem and want a solution. It’s more that you have a solution that you want implemented, and are justifying that solution by pointing to a problem. And when other people suggest solutions other than the one you want, you dismiss these as “you don’t understand my needs at all”.

And your chosen solution is explicitly one that involves a lot of other people doing a lot of work on the assumption that there is a huge unserved audience out there.

Note also that there has been no attempt to write such a mid-level graphics API built off of Vulkan or D3D12. If so many people really needed this, then someone would probably be working on it. The fact that nobody is trying to build it suggests (but does not prove) that this isn’t really a “need”, just something that some people would like to have.

You can apply your analogy as you choose to. But if I were to apply it, Java and C# users are equivalent to people using game engines. C and C++ programmers are equivalent to people using Vulkan.

Equally importantly, despite quoting me, you ignored where I explicitly said:

So trying to frame that as me saying that such programmers “don’t deserve to create games” is… incorrect at best.

Please explain why it is Khronos’s responsibility (and the IHVs) to empower these people.

One more point about this analogy. C and C++ are ISO standards governed by specific ISO standardization bodies. Jave was not a product of those bodies. Nor was C#. Nor were Rust, Python, Go, Swift, etc. All of those languages were created independently of the C and C++ standards committees.

If you want to use C# and Java as analogies here, you are effectively asking the C++ committee to maintain C#. It’s not that your desire is illegitimate; it’s that you’re asking the wrong people to fulfill that desire.

Yes, it is. Your “recommendation” is similarly “your subjective idea”. That’s what we’re doing: having a discussion about subjective ideas.

That’s how forums work.

That’s not how forums work. You don’t get to say that someone can’t speak in your thread unless they agree with you.

I mean, you can say that, but don’t expect anyone to take you seriously.

[UE5, Unity and Godot are very convenient. Why bother with Vulkan and opengl? Just use these engines]
Don’t try to lure me to the game engines of Unity and UE5. Even though they are really convenient and can create games in a week, they are garbage to me because they can easily be extracted from all the resources in the game by others. Include source code (even if you encrypt it). They are very unsafe, so I need to build my own engine instead of using ready-made rendering engine, which is the point that you don’t understand my requirements.
You have gone to the extreme, which means that you think the current situation is unchangeable and force me to compromise and use other ways, but these are impossible.
As for the status of those languages, I’m not interested, even if you deify Rust and GO. Because I don’t have time to learn a new language.
They are not important (including vulkan).
I don’t need anyone to agree, so I have understood that arguing with you is a waste of time

I don’t feel my position is particularly extreme. But since we don’t seem to be communicating very effectively, allow me to summarize my position as follows:

  1. It is valid for you to desire the existence of a graphics API of the kind that you want.
  2. You, and developers like you, have 100% of the tools needed to build an API that fits your needs, using low-level graphics APIs like Vulkan as the foundation of such APIs.
  3. Since this is a problem that you could solve yourself, asking the Khronos Group and IHVs to supply the API you want is not reasonable. It forces them to do a lot of work for little gain compared to something you could have built.

This is not about something being “unchangeable”. It’s about how you want to use the time and expertise of other people.

… what? I’m not sure we’re even communicating at this point. At no point did I make any claims about the quality of Rust or Go. They were just two languages (of several) I thought of off the top of my head to use as examples of languages that weren’t developed by the C++ standards committee. It could just as easily have been Cobol and Fortran.

Why would you take me listing these languages as equivalent to "deify"ing them? Acknowledging that something exists is not “deification”.

I never suggested that you should learn a new programming language. Who are you even talking to?

Also, you were the one who brought up the analogy with programming languages.

Um… you do need people to agree. Specifically, you need Khronos to agree, as well as the IHVs. Otherwise, you get nothing. And if you want to get them to agree, you have to make a decent argument. You need to explain why it is that they specifically have to do this instead of you.

And you’re going to need something more than just saying that Vulkan is dirty and you don’t want to use it or link to anything that use it.

Interestingly, first of all, I didn’t ask KHR to do a lot of work. I just need to add better multithreading features on the basis of OPENGL4.6. Just like some extensions of NV, I never said that I wanted to completely overthrow OPENGL and redesign it. I just don’t think it is necessary to require 100% compatibility with the old API.
And they haven’t been updated for about 6 years. How sad can they be?
Secondly, I don’t think that using Vulkan to encapsulate an opengl library will require less work than using Vulkan directly.
I apply to update opengl,The purpose is to avoid using VK.

Well, there may be some misunderstanding. Please don’t mind.
I don’t need the consent of others because I understand that they will not agree. It is meaningless to continue the discussion.
Just like you don’t think other hardware manufacturers need to support the new features of opengl,
Similarly, I don’t think it is particularly necessary for them to support Vulkan’s features, because compared with native APIs, they generally treat Vulkan as someone else’s daughter (or stepmother’s daughter), and they certainly won’t let it be optimized to 100%.
It’s just like the result of OPENGL . If I were Microsoft, I would do the same and support DX12 as much as possible. Apple doesn’t support VULKAN, so MoltenVK is needed. But I don’t believe it can run VULKAN well.
Finally, I do use opengl and use it to build the engine, but I am not satisfied with its multi-core CPU support. This is not the way to be responsible for the game players, because they will encounter the situation of being stuck, but because Vulkan is not suitable for me, I can only go on.
That’s all.

With the four new features of module, concept, scope and process introduced by C++20, C++has eliminated the old way of writing large programs, realized flexible template specialization, and completely changed the way of data processing. C++20 also adds automatic merging of terminable threads, semaphores, latches, barriers, atomic types that can wait for notification, atomic references, and thread-safe atomic smart pointers. It can be said that the support for concurrency is the most complete and efficient of all languages. Look at opengl and laugh loudly.

The problem is that you don’t seem to understand that what you’re asking for is “a lot of work”. You seem to assume that they can just slap “multithreading” onto OpenGL. Maybe it’ll take them a week or two to work out the details.

It just doesn’t work that way. To give you the slightest idea of how complex the thing you’re asking about is, let’s do a thought experiment.

You have your multithreaded OpenGL API. That means that you can have CPU threads X and Y, both of which are generating work for the GPU. OK, fine.

So, what happens if the work generated by thread X needs to synchronize with some of the work generated by thread Y? Well, you’d use a fence sync object and submit Y’s work before X’s, right?

Except that you can’t. The reason being that thread Y may not have even generated the commands that thread X needs to wait on yet. That is, it hasn’t gotten to the point where it would call glFenceSync yet; that’s what “asynchronous” means. You don’t want X to have to wait until Y gets there, because you may as well not have threading at that point.

So now we need a new synchronization model, one where you can generate a synchronization object without having used it in a command yet. We don’t want to waste a bunch of GPU performance, so we need this to be a fine-grained synchronization model, right? So we need a way for thread X to say exactly what it is waiting on, and for thread Y to declare that it has finished that particular work.

Oh look, we just re-invented the entire Vulkan synchronization system, one of the most complicated aspects of Vulkan.

Speaking of synchronization, what if thread Y is writing to an image that thread X wants to read. Maybe thread Y is writing through a compute shader. Well, some hardware can’t easily handle that; it needs to modify the image’s data so that it is more optimal to write to via a compute shader, and then modify the data arrangement so that it can be read optimally from a rendering operation. It’s the same data, but there are ways to arrange it to more optimally work for different operations.

So thread Y needs to tell the system to adjust the texture to be used for a CS, and thread X needs to not only adjust the image for shader reading, but also that the image used to be used for CS writing so that the transformation of the data will be complete.

Oh look, we just reinvented Vulkan image layouts, probably the second most complex aspect of Vulkan.

The thing you don’t understand about Vulkan is this: it isn’t complicated by accident. The developers were not throwing complexity in for no reason. If you start trying to bring “better multithreading features” to OpenGL, you will inevitably transform it into something that looks an awful lot like Vulkan.

Just look at the API similarities between Vulkan, D3D12, and Metal. While they differ a lot in details, they have a lot in common. Explicit synchronization. Command buffers and queues. Big pipeline state objects that are immutable. Complex resource systems like descriptor sets. Most of these are inextricably linked to being an asynchronous rendering API.

So what exactly do you think this new “better multithreading features” version of OpenGL would look like?

That’s generally what happens when you’re done with something: you don’t update it anymore.

“Less work” from whom? It will certainly require less work for Khronos, since it requires no actual effort from them. It will require a bunch of work from whomever does implement it, but it’s not on Khronos or IHVs to develop or support it.

Second, there are already OpenGL wrappers around Vulkan, though they’re probably far from production ready at this point.

Do you have any actual evidence for that statement?

Again, is that a statement based on actual evidence or just your obvious disapprobation towards Vulkan?

You keep saying “Vulkan is not suitable to me”, but you’re wrong. It is suitable to you.

You just don’t like it. You don’t want to deal with the added complexity of it. And you believe that there is a free lunch, that it’s possible to have an API that does what Vulkan does but without the complexity.

You are incorrect about that. You have two choices: accept that your code will have worse performance, or deal with the complexity of an API that can give you the performance you want.

If game developers don’t like the multithreading feature of 5.0, they can switch back to 4.6. This is not mandatory. They can still use the old API,
5.0 is for those who need performance. It just has one more switch.

What you said seems reasonable, but I won’t be cheated. I think it’s a trap.
I will not throw myself into VULKAN’s terrible code ocean, which will drive me crazy.
Because I don’t want to be tortured by VK’s troubles for a long time. It’s bad, although many advertisements advertise it’s great. Again, it doesn’t suit me and I won’t like it. I will continue to bear players’ complaints about OPENGL performance.
OPENGL is great, but its parents don’t love it. OVER

As for the problem that IOS does not support GLES, I also have a solution, which is to use OPENGL on WIN10, LINUX and Android platforms. IOS uses METAL, because MoltenGL needs to purchase a license.
If I study METAL, I will not need to purchase its license, and bypass MoltenGL directly and MoltenVK. I can delete them.
Cross-platform can still be achieved.

I don’t know what that is supposed to mean in the context of this discussion. My most recent post was not about the relationship between “game developers” and your hypothetical 5.0. It was about the nature of such an API. That is, whatever “terrible code ocean” that Vulkan has, your hypothetical GL 5.0 will also have that “terrible code ocean”. Because that’s the price of having a multithreaded rendering API.

I find that interesting, as Metal (again, NOT ALL CAPS) is really not that much different from Vulkan in terms of complexity. Its memory management is a bit higher level, and there’s less variation in implementations due to only having to support a very specific set of GPUs (and therefore less querying), but it has all of the explicit stuff that makes Vulkan difficult to deal with.

At this point, it seems to me that your problem with Vulkan is not that it’s a bad API or that it involves a number of complex subjects. Your problem is that it’s verbose. As if you can’t hide any unwanted verbosity behind a few function calls.

Vulkan cannot replace opengl. I have never heard that a low-level language can replace a high-level language, just as you cannot replace C # with C language.
Because the high development efficiency of C # cannot be replaced by C language, it is also difficult to achieve. Moreover, its complexity and inefficient development efficiency are not suitable for personal development. Because my engine is not developed by countless people.
It is only suitable for engine companies (currently known as UNITY and UE5), because their pursuit of performance is much stronger than mine. I think you should have heard that the development of Godot 4.0 started in 2019. They thought they should rewrite the rendering engine, so they chose Vulkan. However, the effect is not ideal. Vulkan has caused a lot of errors. I saw a lot of error reports in their Github feedback community. The terrible instability and complicated code writing have led to their inability to launch their new version of the engine.
This is terrible for individuals. Because time is precious.
It has also been compared that opengl is not much slower than metal, and the difference is only about 7 frames.
It is not convincing to think that opengl is out of date by relying on this gap alone.

Any API can write hundreds of thousands of lines of code, but it is obviously less code to use OpenGL than Vulkan.

Don’t worry about the case of names. This is a personal habit. I don’t like to switch the Caps lock key frequently.

Similarly, I think Metal is simpler than Vulkan and requires less code to implement. Because they do not need to expose the bottom layer in too detail.

Vulkan is a bit extreme (too revealing details). It does not take into account the difficulty of use. Unless VK official (KHR) can encapsulate the commonly used parts into high-level APIs, so that we can call them as easily as OpenGL, I will never consider using Vulkan.

Can you provide links to some of these issues?

I don’t buy that. If for no other reason than this “about 7 frames” is an entirely relative measurement. The difference between 200fps and 193fps is 7 frames, but in terms of actual time, it is the difference between 5ms and 5.18ms, a mere 0.18ms. Whereas the difference between 30fps and 23fps is between 33.3ms and 43.5ms, over 10ms.

“7 frames” doesn’t mean anything without context. Furthermore, measuring performance differences in frames per second is what you see on various profiling websites. It’s not how serious programmers measure performance. We do it in actual time per frame.

I’m not saying you’re lying. I’m sure there is some program out there where switching from OpenGL ES to Metal only improved things by 7 fps. But that is utterly meaningless in comparing actual performance differences between the two APIs. Especially considering that it would be easy to use Metal badly (ie: not threading your rendering code effectively), especially if one were just starting out switching their application to it. Or if their program was not amenable to threading.

It also doesn’t have to run on a wide variety of hardware. Again, Vulkan’s complexity didn’t come from nowhere.

You can’t use Metal “as easily as OpenGL,” yet you seem willing to use Metal.

Also, why does “VK official (KHR)” have to come up with this “encapsulation”? Or more to the point, why do you care? If your problem with Vulkan is that it’s not as easy to use as you would like, why do you care if an easier-to-use Vulkan wrapper API came from Khronos or from someone else?

This is the part you seem decidedly unwilling to engage with: why resolving your particular problem Khronos’s responsibility? Why does it matter so much to you that Khronos specifically are the ones to resolve this problem for you?

You can go to the github forum of GODOT to search by yourself. I don’t need to provide it. Thank you.
Now there are many conversion layers that can support GLES to METAL, and I don’t need to write more code. I don’t need to learn VK.
Don’t recommend VK to me.
In addition, you repeatedly ask questions I don’t want to answer
[Why do other hardware manufacturers need to support 5.0?]
[Why is KHR obliged to do so]
Then I want to ask:
Then why do they exist? Isn’t this their job? If they choose not to do so, I will give up using it.
It’s that simple.
But your question is very strange and irresponsible. It’s like you invented a product, but you refused to make it better, and said that it’s not your obligation.
Please stop asking such questions. I won’t answer again.