Hacker News new | past | comments | ask | show | jobs | submit login

It is not the concurrency issues I meant. It's about accumulating commands in the userland and transferring them to the kernel mode driver. The concurrency that affects performance the most is inter-draw call concurrency, as I said above. Flush control is about GPU-CPU concurrency, which, btw, still has long ways to go to reach the level of the control available in native APIs on consoles.



Hopefully OpenGL-next won't be a minor modification of the current limited design but would create a new design from the ground up. So far they indicated that it's the goal.


Nobody can forbid you from hope, but JFYI there had been two major version of OpenGL (3 and 4) already in the age when all the GPUs available had been parallel. In fact, at the time of OpenGL 2 design there had already been parallel GPUs on the market and everybody involved knew it's the way of the future (companies on the ARB either design their own GPUs or have access to the pre-release designs).


I'm not really sure why previous major versions failed to redesign the API from the ground up to fix major deficiencies in it. Was it organizational flaw or lack of good proposals?

I guess now they came to a better realization of the situation or now there are more people who actually want to improve things significantly rather than avoid such issues.


It's not a mystery to me: OpenGL is a scene description API, not a real-time graphics API. It comes from the environment where frame times under 5 seconds (not milliseconds, 12 frames per minute) are considered real-time and the compatibility is much more important than performance. Apple was the only ARB member that had been pushing for the OpenGL to become game-grade real-time mainly due to lack of any other real-time 3d graphics API on their platforms (both Mac and iOS), which is not the case any more as Apple is pushing its own API now.


> It's not a mystery to me: OpenGL is a scene description API, not a real-time graphics API.

Rather it originally was such API. I'm saying, why couldn't they draft a new API from the ground up as one of the previous major versions? It looks like only now they are doing exactly that. So why wait so long? That's what I mean I'm unsure of. Probably some organizational problem or lack of some major pushers for such change in the past.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: