Ork: a new object-oriented API on top of OpenGL

[Eric Bruneton]

Ork, for OpenGL Rendering Kernel, provides an object-oriented C++ API on top of OpenGL. Using Ork can greatly simplify the implementation of OpenGL applications. For instance, suppose that you want to draw a mesh in an offscreen framebuffer, with a program that uses a texture. Assuming that these objects are already created, with the OpenGL API you need something like this:

glUseProgram(myProgram);
glActiveTexture(GL_TEXTURE0 + myUnit); 
glBindTexture(GL_TEXTURE_2D, myTexture);
glUniform1i(glGetUniformLocation(myProgram, "mySampler"), myUnit);
glBindBuffer(GL_ARRAY_BUFFER, myVBO);
glVertexAttribPointer(0, 4, GL_FLOAT, false, 16, 0);
glEnableVertexAttribArray(0);
glBindFramebuffer(GL_FRAMEBUFFER, myFramebuffer);
glDrawArrays(GL_TRIANGLE_STRIP, 0, 4);

With the Ork API you simply need two steps (and the first one does not need to be repeated before each draw, unless you want a different texture for each draw):

myProgram->getUniformSampler("mySampler")->set(myTexture);
myFramebuffer->draw(myProgram, *myMesh);

The Ork API fully covers the OpenGL 3.3 core profile, and partially covers the OpenGL 4.0 and 4.1 core profile APIs (tesselation shaders are supported, but uniform subroutines, binary shaders and programs, pipeline objects, separable shaders, and multiple viewports are currently not supported). Ork has just been released as an Open Source project, under the LGPL license.

[Groovounet]

It looks interesting, pretty code and everything.

There is just again something I can't understand: Why so many people use a string name to set uniform? Even using uniform locations, setting the uniform is the most expensive operation in a real scale software just because there is so many of them.
Adding a string search per glUniform* call is an even stronger penalty.

[Eric Bruneton]

It looks interesting, pretty code and everything.

There is just again something I can't understand: Why so many people use a string name to set uniform? Even using uniform locations, setting the uniform is the most expensive operation in a real scale software just because there is so many of them.
Adding a string search per glUniform* call is an even stronger penalty.

uniforms are represented with Uniform objects (which encapsulate the uniform location). And it is explicitly recommended to store the reference to the Uniform instead of computing it each time you want to use it (see the "Important note" in 3.2.1 here)

[pjcozzi]

There is just again something I can't understand: Why so many people use a string name to set uniform?

By so many people I bet you are including me .

Eric hit the nail on the head; just find the uniform by name once after program compiling and linking, and cache it. The search isn't going to cost anything compared to the compile/link. Of course, immediately querying a program for its uniforms after linking is going to prohibit driver optimizations that try to compile/link on another thread but I don't know what Ork is doing behind the scenes. I personally just query uniforms, etc. right after linking.

Eric, very nice job with this project. The documentation is great!

Regards,
Patrick

[Groovounet]

Of course, immediately querying a program for its uniforms after linking is going to prohibit driver optimizations that try to compile/link on another thread but I don't know what Ork is doing behind the scenes.

Really, you think that it could prevent some optimizations? I don't see how but maybe. The ARB_get_program_binary extension goes this way at least.

Chances are that most developers do so why showing otherwise? Why showing something that the documentation says not to do?

[pjcozzi]

Really, you think that it could prevent some optimizations?

I don't want to take this thread off the topic of Ork but I am referring to Pierre Boudier's post here.

Regards,
Patrick

[Alfonse Reinheart]

With the Ork API you simply need two steps (and the first one does not need to be repeated before each draw, unless you want a different texture for each draw):

I'm not sure this is a good idea in terms of performance. Essentially, you have abstracted away the notion of texture image units. That is, the fact that programs don't have textures bound to them; they instead refer to texture image units.

Consider the possibility of creating certain conventions for texture image units. For example, one could always bind the shadow map to texture unit number 12. That way, every program that uses a shadow map just uses image unit 12, and you never have to set the uniform state again.

The way you're doing it, every program that uses a shadow map may be using entirely different texture image units for it. So on every program state change, you have to rebind both the uniform and the texture object.

Consider the case of differred rendering, where the lighting passes all use the same texture sets. There may be dozens of different lighting and material shaders, but they all use the exact same texture objects. Why have all of those state changes when the underlying API needs precisely none of them?

At the very least, there should be some way to have these kinds of conventions associated with programs.

Similarly, having the draw function as part of the framebuffer gives the wrong idea about the performance characteristics of drawing to different framebuffers. It may be object oriented, but it suggests that changing which framebuffer you're drawing to is a trivial change with no performance implications. If instead you make the current framebuffer some kind of state, then you more strongly suggest that changing the state incurs a performance penalty.

[Eric Bruneton]

I'm not sure this is a good idea in terms of performance. Essentially, you have abstracted away the notion of texture image units.

right, one of the main goal was to abstract image units away

Consider the possibility of creating certain conventions for texture image units. For example, one could always bind the shadow map to texture unit number 12. That way, every program that uses a shadow map just uses image unit 12, and you never have to set the uniform state again.

At the very least, there should be some way to have these kinds of conventions associated with programs.

I think this could be easily done with a "setPreferredUnit" or "setUnit" method in the Texture class.

Similarly, having the draw function as part of the framebuffer gives the wrong idea about the performance characteristics of drawing to different framebuffers. It may be object oriented, but it suggests that changing which framebuffer you're drawing to is a trivial change with no performance implications. If instead you make the current framebuffer some kind of state, then you more strongly suggest that changing the state incurs a performance penalty.

of course the users should have some knowledge about OpenGL to use Ork in an efficient way. But users always have to know the "internals" of any library to use it in the most efficient way (this is even true for C++ itself, or for the STL)

[Alfonse Reinheart]

I think this could be easily done with a "setPreferredUnit" or "setUnit" method in the Texture class.

Why would it be in the texture class? It would make more sense to put this in the shader(s), since they're the ones who need to decide where these things go.

of course the users should have some knowledge about OpenGL to use Ork in an efficient way.

You're making an API who's primary design is to abstract away OpenGL. Why would you expect users of it to have detailed knowledge of how OpenGL works to be able to use it? If they had detailed knowledge of OpenGL, they wouldn't need Ork.

But users always have to know the "internals" of any library to use it in the most efficient way (this is even true for C++ itself, or for the STL)

True, but STL doesn't make it easier to do things the wrong way than to do them the right way. std::list does not have operator[] because it would be prohibitively expensive to implement. It would give the user the illusion that it is OK to access elements by index. Similarly, std::list::iterator's are not random access iterators, again suggesting that directly adding numbers to them isn't the most effective way to use them.

The point is that the API should encourage correct use and discourage incorrect use.

[Groovounet]

Ouhhhhhh as harsh as usual Alfonse

OpenGL is quite crazy hard to abstract especially compare to Direct3D. I think this is due to the serious lack of consistency of OpenGL. Damn, why everything as to invent new rules for every feature when already exciting conventions are already present in the OpenGL specification.

My last example on this regard: the subroutine API... WHAT THE [censored]. Why does it have a shader type parameter? Why does it have such strange rules on where it belongs (half context half program in a summary) Actually I would say... why not using these conventions, if so why uniform blocks and uniform variable doesn't follows the same rules?

Sometime (and actually quite often!) when I start to think about OpenGL, my brain just end up in a dead lock.

I dare anyone to tell me they are using all the strenght of the VAO in a decent size project! It has barely any XD