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!

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.

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.

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.

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.

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.