12 replies to this topic

[StasB]

I'm tired of my code being littered with verbose GL calls. I've been wondering if there's any way to wrap things up in small classes without a serious loss of performance and generality. For example, if I want to have a VBO class, every member function that does something with a VBO needs to make sure it is bound first. If I want to render it, I need to make sure all the client states (e.g. glEnableClientState(GL_VERTEX_ARRAY)) and pointers (e.g. glVertexPointer(...)) are set up correctly. The only robust way to do that is to set all relevant global state in every member function call, even when it's unnecessary. Wouldn't all this state-changing cause some serious performance issues?

[Murdocki]

Yes it's possible, it's called object orientation. You create classes with specific responsibilities. This will add a very tiny mini overhead but it's more than worth it. The trick is to pull your classes to an as high as possible level of abstraction without creating overly complex class responsibilities. For example, who sais you're using VBOs, maybe you've just got some vertex data that needs to be rendered however the implementation sees fit.

To counter the state changes you might end up with a state manager which only changes state if it is required.

[StasB]

Yes it's possible, it's called object orientation. You create classes with specific responsibilities. This will add a very tiny mini overhead but it's more than worth it. The trick is to pull your classes to an as high as possible level of abstraction without creating overly complex class responsibilities. For example, who sais you're using VBOs, maybe you've just got some vertex data that needs to be rendered however the implementation sees fit.

To counter the state changes you might end up with a state manager which only changes state if it is required.

I thought it was clear from my OP that object orientation is what I'm trying to achieve. I'm just worried about the performance penalties from redundant state changes.
I just want a thin and convenient layer on top of plain OpenGL to ease up the task of writing a higher-level graphics engine. I thought about making a state manager, but I'm not sure how to go about it. How would you go about wrapping "void glBindBuffer( GLenum target, GLuint buffer)", for example?

[Yours3!f]

well, while wrapping the whole api is possible, in my opinion its rather pointless. You might want to write a state manager as suggested, but I think that you shouldn't wrap everything, but rather certain functionality (mesh loading, texture loading, shader loading etc.) which enables you to use OGL without making a single error, because the wrapper class takes care of it.

for ex. you could say that the current buffer stored would be:
struct buffer_state
{
GLuint buffer;
GLenum target;
} current_buffer_state;

and you could implement a function that checks if the current buffer bound is the one you pass to it, and in that case it wouldn't call the OGL function:
void my_bind_buffer(GLenum target, GLuint buffer)
{
if(current_buffer_state.buffer != buffer || current_buffer_state.target != target) //check the current state
{
if(glIsBuffer(buffer)) //check if it is really a buffer
{
glBindBuffer(target, buffer);
}
}
}

or something like this...
you might want to check out pixellight for a whole api wrap example.

when your app starts up you could just simply query the current gl state with glGet* to initialize your states

[StasB]

well, while wrapping the whole api is possible, in my opinion its rather pointless. You might want to write a state manager as suggested, but I think that you shouldn't wrap everything, but rather certain functionality (mesh loading, texture loading, shader loading etc.) which enables you to use OGL without making a single error, because the wrapper class takes care of it.

for ex. you could say that the current buffer stored would be:
struct buffer_state
{
GLuint buffer;
GLenum target;
} current_buffer_state;

and you could implement a function that checks if the current buffer bound is the one you pass to it, and in that case it wouldn't call the OGL function:
void my_bind_buffer(GLenum target, GLuint buffer)
{
if(current_buffer_state.buffer != buffer || current_buffer_state.target != target) //check the current state
{
if(glIsBuffer(buffer)) //check if it is really a buffer
{
glBindBuffer(target, buffer);
}
}
}

or something like this...
you might want to check out pixellight for a whole api wrap example.

when your app starts up you could just simply query the current gl state with glGet* to initialize your states

Basically, here's my problem:
I need to write my own versions of the OGL state-setter functions I care for that check for redundant state changes. Some of those functions take a parameter that specifies which state to change, like glBindBuffer. Ideally, if I write a glBindBuffer wrapper, it better act like the original, accept a target parameter and handle it correctly. How do I do that without manually writing special code for every type of target?

[Murdocki]

If you're going for a higher level graphics engine you should not think about how to wrap OpenGL. Instead you should think about how you'd like to make the calls to render something and then fill that in by using OpenGL. You might need a few iterations of adjusting requirements due to api specific limitations but you'll end up with a system that's easy to use, which is one of the most important things for anything high level.

To answer your question, my glBindBuffer calls are checked in the implementation of the Renderer class just by comparing ints like suggested by the poster above. I'm not doing this in the state manager because i've defined that to be managing render states like cullmode, blend mode, alpha testing etc etc. I gues you could do that in the state manager aswell, it doesnt really matter.

On a side note, maybe managing glBindBuffer calls isn't your biggest problem if you're worried about redundant state changes performance loss. Other state changes like shader and texture binds will probably be a lot more expensive and your buffer count will be very low when you've implemented batching.

[Murdocki]

oh woot simultaneous post. I dont think you want to go about wrapping single methods. At least take it higher and use a VBO. Then when making a render call to it, check if it's allready bound and rebind if needed.

[StasB]

If you're going for a higher level graphics engine you should not think about how to wrap OpenGL. Instead you should think about how you'd like to make the calls to render something and then fill that in by using OpenGL. You might need a few iterations of adjusting requirements due to api specific limitations but you'll end up with a system that's easy to use, which is one of the most important things for anything high level.

To answer your question, my glBindBuffer calls are checked in the implementation of the Renderer class just by comparing ints like suggested by the poster above. I'm not doing this in the state manager because i've defined that to be managing render states like cullmode, blend mode, alpha testing etc etc. I gues you could do that in the state manager aswell, it doesnt really matter.

On a side note, maybe managing glBindBuffer calls isn't your biggest problem if you're worried about redundant state changes performance loss. Other state changes like shader and texture binds will probably be a lot more expensive and your buffer count will be very low when you've implemented batching.

What's wrong with an intermediate layer to ease up the task of writing a higher-level engine? I have no intentions of writing a big general-purpose graphics engine. If I wanted one, there are many available. I write small apps with widely varying requirements that don't usually fit a standard engine architecture and I find myself writing over and over again heaps of OGL code to handle low-level tasks like setting up and rendering FBOs, VBOs etc.

[kunos]

only you can know how much abstraction you need or want. just make sure there is some. Wrapping glEnable(Gluint) into myEnable(unsigned int) or into myEnableDepthTest() / myDisableDepthTest() doesn't strike me as an effective way to make the program any more manageable.

[RobinsonUK]

The way I did this was to create a set of classes to totally hide the gl calls and provide additional boiler plate functionality. Basically I've got the following classes:

ArrayBufferGL

IndexBufferGL

VertexBufferGL

GeometryShaderGL

VertexShaderGL

PixelShaderGL

ShaderProgramGL

ShaderVariablesGL

StateGL

FrameBufferGL

RenderBufferGL

SamplerGL

TextureMapGL

TextureArrayGL

After writing these classes, I then implemented a factory template to create instances of them:

template< class GraphicsDevice,
	 class VertexBuffer,
	 class IndexBuffer,
	 class ArrayBuffer,
	 class TextureMap,
	 class TextureArray,
	 class FrameBuffer,
	 class RenderBuffer,
	 class PixelShader,
	 class VertexShader,
	 class GeometryShader,
	 class ShaderProgram,
	 class ShaderVariables,
	 class Sampler,       
	 class GraphicsState>     
  class GraphicsFacade
  {
    ...
  };

The facade just contains a set of Createxxxxx methods that return shared_ptr to one of the items. I can instantiate the template with D3D versions if I want to at compile time. As kunos says, simply wrapping things like glEnable(x) with your own method is a bit pointless. But hiding the gl- nature of the functionality in an OO way can be really useful.

[Yours3!f]

If you're going for a higher level graphics engine you should not think about how to wrap OpenGL. Instead you should think about how you'd like to make the calls to render something and then fill that in by using OpenGL. You might need a few iterations of adjusting requirements due to api specific limitations but you'll end up with a system that's easy to use, which is one of the most important things for anything high level.

thats exactly what I said. In my implementation I dont have glBindBuffer and stuff like that used directly, I rather have mesh.load(), mesh.render() etc. so that when I try to write a small application I dont need to remember how to use OGL stuff, I just have to supply the function with some general stuff like filename, identifier that will hold the access to the loaded asset. later I can use the identifier to render it or use it.
Of course when I need it I can create a texture manually, so instead having an identifier I just have the texture directly, fill it with stuff and use it again with texture.bind() etc. so after loading again I can forget about using OGL.
When I have to do some more special stuff like deferred rendering I just use the wrapped fbo class that I wrote, and again I dont have to know OGL, but feed the fbo. This kind of stuff is similar to what RobinsonUK described.

[Ubik]

I personally have chosen a two-layered abstraction. The lower level simply wraps the OpenGL objects, VBOs, IBOs, textures and so on to the language's way of handling objects. The higher level uses those and is supposed to have things like a mesh class. Currently I handle the binding so that all the methods that require the GL object to be bound, check if it is so in the start of the method. The "trick" is that this check is only done in debug mode, the release builds don't contain any checks. It also means that to use the objects, I need to explicitly bind them whenever I'm doing anything to them - I'm not interested in abstracting all of the OpenGL away so this has been okay for me so far. First call bind and then call the actual method to do stuff with the object.

However, I've grown bit tired of the idea of doing such low level managing, what with having to have bind calls everywhere where the low level objects are used, so I'm planning to start using a state manager. The plan also includes dividing the bind operations into two categories: bind for editing and bind for drawing. The bind for editing is done implicitly in the wrapper objects' methods, for example when passing vertex data to vertex buffer. The binding for drawing is still done with an explicit bind call. The reason for the explicit binds is mostly that the alternative would be to pass all the relevant objects to some rendering method which would then bind them - but that would mean lots of stuff to pass, at least all the buffers, textures, shader... doesn't feel right, as the method would keep bloating when new stuff gets added. Anyway the state manager would have to keep track of what is bound for drawing and what is actually bound at the moment, be it for either drawing or editing, but that doesn't seem bad.

Another complication comes up at least with vertex array objects. If I first bind a VAO and then an index buffer, the index buffer will be attached to the VAO. The way I'm going to get around that is to add an AddIndexBuffer method to the VAO class which uses the implicit bind for editing method, and whenever I explicitly bind an index buffer for drawing the VAO will be automatically unbound. Same goes for vertex buffers even though they don't have the same problem. I feel it makes sense to unbind any VAOs when vertex and index buffers are bound, because those don't really mix well anyway, with VAOs essentially being a shortcut to VBO and IBO binding.

[RobinsonUK]

The bind for editing is done implicitly in the wrapper objects' methods, for example when passing vertex data to vertex buffer. The binding for drawing is still done with an explicit bind call.

In fact this is exactly what I did. I also made some little classes to unbind objects using RAII principles. I think the compiler should optimise away most of it leaving me with similar performance to explicit calls to bind and unbind the object, i.e. :

class Using
   {
   public:
    Using(std::shared_ptr<ArrayBufferGL> buffer) : MyUsing(buffer)
    {
	 MyUsing->Use();
    }
    ~Using()
    {
	 MyUsing->Unuse();
    }
   private:
    std::shared_ptr<ArrayBufferGL> MyUsing;
   };

, where I can Use/Unuse the object with a stack frame:

{
    ArrayBufferType::Using useArrayBuffer(mesh->ArrayBuffer());
    ...
}

By doing this I never "forget" to unbind an object after use.