Jump to content
  • Advertisement
bartman3000

OpenGL: Reading and writing and to different FBO attachments in the same draw call

Recommended Posts

Consider the following situation:

-          We have an FBO with two identical color attachments

-          Bind shader program 1 and render an object to FBO attachment 0

-          Bind the texture on attachment 0 for sampling

-          Bind shader program 2 and draw a full screen quad. In the fragment shader we sample from the texture on attachment 0 and write it’s value to the texture on attachment 1.

Can framebuffer objects be used in this way? The reason why I’m considering this is to reduce the number of FBOs I create. I’m experimenting to see if I can perform all of my rendering passes with a single FBO equipped with multiple attachments. In my current implementation this setup does not seem to work as expected, I'm trying to determine if there's a problem with my implementation or if this is even possible.

Any insight would be appreciated!

Share this post


Link to post
Share on other sites
Advertisement

What are you trying to optimise for here? Switching between 2 fully-configured FBOs shouldn't be very expensive, so long as you don't change the attachments on either one.

Share this post


Link to post
Share on other sites

Yup, that's exactly what I was trying to optimize, reducing the switches between bound FBOs. I wasn't sure how much overhead was associated with the bind call and figured I'd just throw together a quick test to benchmark and see if there's any difference.

But of course my "quick test" ends up taking way longer than expected and now I'm curious as to whether or not this is even possible. I tried looking at the spec and couldn't find anything on the subject.

Edited by bartman3000

Share this post


Link to post
Share on other sites
1 minute ago, bartman3000 said:

I tried looking at the spec and couldn't find anything on the subject

Aye, that's a pretty hazy portion of the spec. I couldn't tell you whether the behaviour you are looking for is standard conforming.

I have found in the past that vendors tend to play pretty fast and loose in this area. For example, on a lot of AMD hardware you can read and write the same FBO attachment in a single pass, whereas that doesn't work at all on many other vendor's hardware.

Share this post


Link to post
Share on other sites

FBO are basically free as it just a 'name' OpenGL object. FBO attachments are not as textures or render buffer requires memory as well as a name. So you are not really saving anything using just a single FBO. With that said, did you profile the code to see if there is even a need for this 'optimization' ?  Although I don't recall the specs going over the solution you propose, the attachments are a part of the FBO state so I'm going to say this is undefined behavior aka it does not work consistently aka don't do it. The specs explicitly call out reading and writing to the same attachment as not allowed as it creates a feeback loop.

Share this post


Link to post
Share on other sites

I did not profile the code first, that would have been a smart idea. 

Having said that, this situation has become a curiosity experiment more than anything. I'm familiar with the feedback loop causes by reading and writing to the same attachment, but I figured if I read from one and wrote to another it would be okay... guess not. 

I suppose the real lesson here is don't do anything that isn't explicitly specified in the spec.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • 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!