Hacker News Reader

Comment by foxhill | Hacker News Reader

OpenGL done us good for a long time. Khronos (the standards maintainer) refused to advance the standard in any meaningful way since the API was based around a stateful glBegin/glEnd model.

modern graphics hardware does not work well in this model. they’re really much closer to whole other systems. you want to push the triangle data into the card in a single (or few) API calls, then submit as few draw calls as you can manage.

fun fact, OpenGL 3, originally code named “longs peak”, was supposed to upend the stateful model, and advance the API ahead of its proprietary counter part(s) - DirectX. for what ever reason this completely fell apart, and OpenGL just sort of.. stopped improving :/

we have Vulkan now basically thanks to AMD opening their more modern GPU oriented Mantle API, and valve for running with it.

View on HN

Vertex arrays have been part of OpenGL since 1.1, released in 1995. VBOs since 2.1 (with extensions available earlier). glBegin/glEnd aka "immediate mode" has been "legacy" for a LONG time and were even removed in the core profiles with OpenGL 3.2.

The biggest problem with OpenGL for is/was the context model that made multi-threading almost impossible. And yes, it being stateful is a big part of it. Plenty advances and low level functionality was available in OpenGL before vulkan was released.

Vulkan also reduces overhead since its abstractions better match today's hardware and it allows excplicitly moving more calculations up front that had to be done just in time with OpenGL.

Also, it's not like Khronos (a standards body made up of industry participants) "refused to advance" but rather that different interests had different ideas - e.g. some care more about backwards compat - so that they can tell their clients that their legacy software runs on the latest OpenGL - than getting the last edge on performance so having a separate 100% performance-oriented API was probably an eventuality anyway.

Also, remember that Microsoft and Apple are/were part of Khronos too and giving these two comanies' incentives and past behaviors it would not be entirely surprising if they did their part to hold back the standard.

OpenGL direct state access (DSA) is actually part of OpenGL 4.5! You still need to set up a lot of state for draw calls, but changing little pieces of state has changed from (pseudocode, and I'm showing a worst case for pre-DSA here):

    const int oldTexture = currentTexture();
    switchToTexture(myTexture)
    setTextureData(myRgbImage);
    switchToTexture(oldTexture);

to:

    setTextureDataDSA(myTexture, myRgbImage);

>you want to push the triangle data into the card in a single (or few) API calls

glBufferSubData?

>then submit as few draw calls as you can manage

glDrawElements?

Nobody used glBegin/glEnd in the past 20 years...

i was paraphrasing for someone who might not be familiar with graphics basics, let alone architectures of bindless/GPU-driven rendering pipelines :)

OpenGL 3 deprecated glBegin/glEnd, but there is still state, and a lot of it. none of the OpenGL API is re-entrant, for instance..

At the same time Khronos did the same mistake with extension spaghetti in Vulkan.

However this time they seem to have learned profiles like in proprietary APIs actually make sense.

eh honestly i don't think extensions are really all that bad. it's a standard and extensible way for third parties to advance the API, and - presuming the extension is rationalized into the API appropriately - allows for clean evolution & progression.

on the other hand, i'm not so sure that i agree with the approach of advertising even basic functionality (e.g. swapchain) through extensions. i understand vulkan has uses outside of graphics. i think that could have been better exposed with hard profile boundaries or something..

Most people that talk about how portable Khronos APIs are, versus the proprietary alternatives, never really used them in anger across multiple systems and graphics cards.

You end up with several code paths, where you have an architecture similar to multiple APIs middleware, but actually it is only using OpenGL, or Vulkan, and jungling among all possible cases.

At least now they got why proprietary APIs use profiles.

Reply on news.ycombinator.com