Why not OpenGL 5.0?

OpenGL
1

GL 5.0：

GLuint dev = glGetDevice(...);
GLuint surface = glCreateSurface(...);
GLuint pipeline = glCreatePipeline(dev, ...);
GLuint program = glCreateProgram(.....);
glSetProgram(pipeline, program);
glSetViewport(pipeline, viewport);
glSetBuffer(pipeline, bindingID, bufID);
glSetVertexAttribute(pipeline, ...);
glDraw...
glPersisent(surface, pipeline);

Vulkan is structurally too inflexible. Program, vertex attributes, rendering state and so on are all in one bucket, so it’s inconvenient to change them. So how do the APIs after Vulkan 2.0, Vulkan 3.0… Develop?
C style object-based graphics API, clear structure and easy to use.

2

texture:

GLuint id = glCreateTexture(...);
glSetTextureParam(id, GL_TEXTURE_XXX_FILTER, ...);
glSetTexture(pipeline, slot, id);

framebuffer:
GLuint framebuffer = glCreateFrameBuffer(...);
glSetFrameBuffer(pipeline, framebuffer);//0 is default back buffer
...
3 
GLuint cmdbuf = glCreateCommandBuffer(...);
glCmdClear(cmdbuf, r, g, b, a, boolDepthBuf, bool stencil);
glCmdBindTexture(cmdbuf, slot, textureID);
glCmdDraw...(cmdbuf, ...);

//render to framebuffer
glSetFrameBuffer(pipeline, framebuffer);
glPersisentCommand(pipeline, cmdbuf);
glBlitBuffer(GL_BACK, framebuffer, rect);

// copy buffer
glCopyBuffer(GL_BACK, framebuffer, start, size);
4

Certainly not like that.

It’s not like the Vulkan developers were unaware of the “inflexible” aspects of the API. These elements exist for a reason, and they’re not about to undo them. Nor are they about to not have command buffers, explicit synchronization, and the like.

If you want an API of the form you’re describing, then you’re going to have to write it yourself, likely on top of Vulkan or something similar.

There almost certainly won’t be an “OpenGL 5”. There hasn’t been a new version of GL 4 in years, and newer features of GPUs like ray tracing basically require a command-buffer-style API. Which OpenGL isn’t.

5

Vulkan encapsulated the whole pipeline into one object at the beginning, and did not provide flexible state switching and modification methods, which has great limitations. I want to encapsulate a set of APIs with Vulkan, and find it very difficult to implement. One of the questions is, how many pipelines do I want to create?
What will the next Vulkan version look like? Will an extension of “vk_dynamic_pipeline” be provided?

6

Flexible state switching can be a performance trap. Even so, 1.3 provides a lot of dynamic state at this point. Indeed, I’m unsure as to which parts of the pipeline aren’t able to be dynamic state.

The only thing that isn’t dynamic state in 1.3 that you might want to be is the vertex format. And that’s because in many implementations, the vertex format is part of the vertex shader. Making them dynamic would mean rewriting vertex shader code on every bind. Which would be difficult.

7

program is part of pipeline…

vk(Cmd)SetImageView(pipeline, slot, imageview);
vk(Cmd)SetBuffer(pipeline, slot, buffer);

more struct, more desc…

8

Yeah, I don’t know what that’s supposed to mean. Are you talking about descriptor sets now? Is descriptor indexing not good enough for you for some reason?

Overall, I get the impression that your position is that Vulkan should just be OpenGL but with command buffers. Which… no, it won’t.

9

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.