Jump to content
  • Advertisement
Sign in to follow this  
IncidentRay

OpenGL Dealing with bind-to-edit in OpenGL

This topic is 2027 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi all,

 

I'm looking for an elegant way to design a rendering API abstraction layer, but I keeping running into problems because of OpenGL's bind-to-edit model.  For example, one thing I want to do is cache/shadow the current render state to avoid redundant state changes, but bind-to-edit makes this especially difficult.

 

Here's some pseudocode (I'm pretending there is only one texture unit, for the sake of simplicity):

class Texture {
public:
    void Create()
    {
        glBindTexture(GL_TEXTURE_2D, m_name); // the wrong texture is now bound
        ... // code to create texture
    }
    GLuint GetGLName() const { return m_name; }
private:
    GLuint m_name;
};

class GraphicsDevice {
public:
    void SetTexture(Texture* texture)
    {
        if (texture != m_texture) {
            glBindTexture(GL_TEXTURE_2D, texture->GetGLName());
            m_texture = texture;
        }
    }
private:
    Texture* m_texture;
};

 

As you can see, the texture class needs to bind itself in order to create the OpenGL texture object, and so the the GraphicsDevice class now thinks a different texture is bound than the one that actually is.

 

The obvious way to fix this problem is to add a glGet(GL_TEXTURE_BINDING_2D) call in Texture::Create so that the previous texture can be bound afterwards, but glGet() calls are supposed to be avoided, right?

 

The only other solutions I can think of involve various ugly techniques such as circular dependencies, global variables, etc.

 

Is there a better way of solving this problem?

 

 

Share this post


Link to post
Share on other sites
Advertisement

It's probable that the value for this particular glGet will be cached by the driver and so won't need a round-trip to the GPU - as a general rule, if it doesn't rely on a previous draw call having completed in order to fetch the result, then you can assume that the driver may be able to do something intelligent with it (but do back up this assumption with some benchmarking first!)

 

On the other hand, you're still left with the annoyance of bind-to-modify.  One possible solution, if you're prepared to bump your hardware requirements appropriately, is to have a look at GL_EXT_direct_state_access - it may be just what you need.

Share this post


Link to post
Share on other sites
As mhagain pointed out, direct state access is a great solution to your problem.

However, you have alternatives. It really depends on the GL version you're aiming to support. Suppose it's 4, then you can force your textures to be created only once (let's say in the constructor), and from there on they can only be modified by ARB_copy_image, or casted by ARB_texture_view. Also, the only entity that can create textures is the device. With this design you'll have less problems, and it also resembles the D3D design.

Also, what mhagain said about the state being cached in the driver is true. Generally the driver stores the current state in a local copy. It's just less pretty to have all those glGet in your code. A rule of thumb is that if you have to resort to glGet to query the state, then your design has flaws. Edited by max343

Share this post


Link to post
Share on other sites

Direct state access does indeed look like a great solution, but I think the hardware requirements might be a bit high.  Interesting point about whether glGet values will be cached -- I'll remember that.

 

 

It really depends on the GL version you're aiming to support. Suppose it's 4...

 

 

That technique looks excellent, but unfortunately I need to support Mac OS X versions earlier than Lion, so I only have OpenGL 2.1 available.  If you have any suggestions that could work for OpenGL 2.1, that would be great.  I'm interested in your idea about having the device create the textures.  How would you implement this?  Would you just create the OpenGL texture object in a function in the GraphicsDevice class and then pass the GLuint into the Texture constructor? Or something else?

 

 

if you have to resort to glGet to query the state, then your design has flaws

 

 

Yeah, that's what I thought.  Do you have any pointers on how I could approach re-designing this so that I wouldn't need to use glGet?

 

Thanks!

Edited by IncidentRay

Share this post


Link to post
Share on other sites
It seems that in your case there are no shortcuts available, so you'll just have to do it the hard way.

You can do exactly what D3D11 does. This is pretty much like you suggested. Instead of having the method "Create" in the "Texture" class, move it to the "GraphicsDevice" class and rename it to something like "CreateTexture2D". This method will create the GL texture, create an object of "Texture", initialize its name (possibly through the constructor), restore the previously bounded texture correctly, and finally return the texture object. You'll have to do the same for copying (and probably a few more things). Your "Texture" class will essentially become a resource interface which will be able to do only simple things (like return its name, and delete itself).
Just keep in mind that if you're going to follow D3D11 on this, don't copy it exactly as it also supports views. This is way beyond the scope of 2.1 context. Not that it's impossible to emulate it (pretty much what FL9 does), but you'll just have to write a lot more code. Edited by max343

Share this post


Link to post
Share on other sites

Ok, that solution sounds good.

 

However, one thing I just thought of that could be a problem with both these designs is texture deletion.  Once the Texture instance is destroyed (either with the delete keyword or when it goes out of scope) won't the GraphicsDevice class have a dangling pointer? For example, if you called CreateTexture2D() and the object pointed to by m_texture had been deleted, when the GraphicsDevice instances tries to restore the previously bound texture, it will be calling a member function of a deleted object, causing a crash.

 

Do you have any ideas on how to fix this issue?

 

Also, what's FL9?  I googled it but I can't seem to find anything.

Edited by IncidentRay

Share this post


Link to post
Share on other sites

I have most of my resources pointed to as shared_ptr's. I know it is not the best solution but it works for now.

Also why do you need to cache the rendering state? In my code, a list is prepared containing all things to be rendered this frame. Then it is sorted to reduce state changes

and then rendered in a single function removing the need to store a global cache.

Share this post


Link to post
Share on other sites
Ok, that solution sounds good.

 

However, one thing I just thought of that could be a problem with both these designs is texture deletion.  Once the Texture instance is destroyed (either with the delete keyword or when it goes out of scope) won't the GraphicsDevice class have a dangling pointer? For example, if you called CreateTexture2D() and the object pointed to by m_texture had been deleted, when the GraphicsDevice instances tries to restore the previously bound texture, it will be calling a member function of a deleted object, causing a crash.

 

Do you have any ideas on how to fix this issue?

 

As a general rule, anything responsible for allocating memory should be responsible for deleting it: void GraphicsDevice::DestroyTexture(Texture t) { ... }

Share this post


Link to post
Share on other sites
Ok, that solution sounds good.
 
However, one thing I just thought of that could be a problem with both these designs is texture deletion.  Once the Texture instance is destroyed (either with the delete keyword or when it goes out of scope) won't the GraphicsDevice class have a dangling pointer? For example, if you called CreateTexture2D() and the object pointed to by m_texture had been deleted, when the GraphicsDevice instances tries to restore the previously bound texture, it will be calling a member function of a deleted object, causing a crash.
 
Do you have any ideas on how to fix this issue?
 
Also, what's FL9?  I googled it but I can't seem to find anything.

FL9 is feature level 9 mode of D3D11.

As for your first question, then yes it could potentially cause a problem, though this problem is much easier to identify with a simple assert during bind, just check whether the texture name seems valid (for instance, you can keep track on how many textures you've allocated).
This way of deletion is just how D3D does things, you don't have to do the same. As Aldacron already said, your GraphicsDevice can handle the deletion (and check if what you're deleting is currently bound). However, as far as the state goes textures can delete themselves because for that you don't need to bind them (you don't alter the state).

Share this post


Link to post
Share on other sites

Thanks for the replies!

 

I have most of my resources pointed to as shared_ptr's. I know it is not the best solution but it works for now.

Also why do you need to cache the rendering state? In my code, a list is prepared containing all things to be rendered this frame. Then it is sorted to reduce state changes

and then rendered in a single function removing the need to store a global cache.

 

This would definitely work, but I just prefer it if the caching is implemented in the graphics API layer, so that the user doesn't have to worry about it.  It seems to me that you might end up implementing render state caching multiple times, for each type of graphics you need to draw; e.g., the actual game world, the UI, etc.  I also think this could pose a problem if you are dynamically generating geometry -- i.e., filling a vertex buffer with data, then drawing it, filling it with new data, and so on.  How would you have a list of objects in this case?

 

 

Ok, that solution sounds good.

 

However, one thing I just thought of that could be a problem with both these designs is texture deletion.  Once the Texture instance is destroyed (either with the delete keyword or when it goes out of scope) won't the GraphicsDevice class have a dangling pointer? For example, if you called CreateTexture2D() and the object pointed to by m_texture had been deleted, when the GraphicsDevice instances tries to restore the previously bound texture, it will be calling a member function of a deleted object, causing a crash.

 

Do you have any ideas on how to fix this issue?

 

As a general rule, anything responsible for allocating memory should be responsible for deleting it: void GraphicsDevice::DestroyTexture(Texture t) { ... }

 

This is a good idea.  What's interesting though, is the texture class doesn't really do anything in this case -- it just stores a texture name and returns it.  Also, if you need an instance of GraphicsDevice to destroy a texture, it would then be necessary to pass a pointer/reference to it around more.  For example, if an object creates a texture in its constructor, and destroys it in its destructor, it would need to maintain either a pointer or a reference to the GraphicsDevice, so that it could call DestroyTexture.  This wouldn't be needed if you could delete a texture without needing the device, but I'm not quite sure how to get around this.

 

 

[quote name='max343' timestamp='1356428689' post='5014135']
FL9 is feature level 9 mode of D3D11.
[/quote]

 

Ah ok, I'm not too familiar with D3D terminology.

 

[quote name='max343' timestamp='1356428689' post='5014135']
As for your first question, then yes it could potentially cause a problem, though this problem is much easier to identify with a simple assert during bind, just check whether the texture name seems valid (for instance, you can keep track on how many textures you've allocated).
This way of deletion is just how D3D does things, you don't have to do the same. As Aldacron already said, your GraphicsDevice can handle the deletion (and check if what you're deleting is currently bound). However, as far as the state goes textures can delete themselves because for that you don't need to bind them (you don't alter the state).
[/quote]

 

I'm having trouble understanding how this would be implemented.  How would you get the texture name without calling a function of the Texture object (which might have been deleted)?  I'm also not sure how keeping a count of the number of textures allocated would help you determine whether a texture name is valid.  I thought OpenGL wasn't required to return a contiguous range of texture names.  I do like the idea of being able to model D3D on this -- could you maybe give a simple example of some code for this?  Many thanks.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!