FBO spec posted

Well it will be shortly anyway. It’s been sent to the OpenGL webmaster for posting on the main page.

Argh! Just a teaser :frowning:

But thanks for the heads up. I’ll make sure to reload the front page and the registry every five seconds until it’s there :stuck_out_tongue:

They’re finally online! :wink:
Big thanks to the FBO team!!

Let’s hope that it will be available in drivers soon!

OMG they did it !
The new fbo interface seems to be quite intuitive !

Good Job guys !!! :smiley: :smiley: :smiley:

So Cass, I heard a rumour these would be available in 75 series Forcewares. Any timelines for us? Or even better, how about a registry key that enables the extension (which has been present in all drivers since 65.xx)?

Before it’s too late, let me please suggest something: It would be great if we refrained ourselves from posting three dozens messages saying nothing more than like “OMG!! I can’t believe this happened!!! I’ve been waiting for this for so long!! Thanks ARB, we love you!!! This is the happiest day of my life!! Good job ARB, God bless you!!”.

Thanks In Advance ™.

Amazing! (100+ revisions :eek: )

While I have no doubt NVIDIA and ATI will support this rather quickly, I hope Intel (and others who have a significant market share in the industry) will do the same.

edit:

Status

Ubercomplete
:smiley:

mmm beefy. :smiley:

-SirKnight

Originally posted by ffish:
So Cass, I heard a rumour these would be available in 75 series Forcewares. Any timelines for us? Or even better, how about a registry key that enables the extension (which has been present in all drivers since 65.xx)?
Hi ffish,

Obviously I can’t respond to rumors, but with 100+ revisions, you can imagine that we’ve been working on this for a while. We’ll expose the extension as soon as we’re confident it’s stable, fast, and correct.

Thanks -
Cass

(i) I like Issue 1 :smiley: .

(ii) I like the way issues were moved to the end of the spec. This makes sense to me since it’s the last information I read. I like to read the spec and how to use it then if I’m still unclear go through the issues which sometimes explain things in a little more depth (the reasons why, not just how). I hope this precedent is followed in future extensions.

(iii) There are a bunch of new procedures and functions that I didn’t expect. Some have been present for a long time in Forcewares, but some are completely new to me.

(iv) I like CheckFramebufferStatusEXT().

(v) Issues take up 2/3 of the spec :eek: . No wonder it took so long.

(vi) Any comments from vendors on issue 44? Will “undefined” mean “it works” on your hardware?

(vii) Issue 58 “(besides attempt …” :smiley: . I can see how this would suck for spec-writers.

(viii) I can’t think that Issue 76 would be a major concern. Off the top of my head, I can’t see why you’d need multiple RCs with this extension (at least I can see why I’d need them).

(ix) I can see that Issue 79 would be a bit hairy - different texture and framebuffer <internal formats>.

(x) I hope Issue 84 gets cleared up. I personally prefer “lower-left” over “semi-undefined”.

(xi) Revision #1: it actually was called “EXT_compromise_buffers” as per Issue 1 :eek: .

All in all, I’m happy. Just not with how long it took.

Originally posted by cass:
We’ll expose the extension as soon as we’re confident it’s stable, fast, and correct.
Thanks cass. I guess I’m sticking with D3D and SetRenderTarget for a little while then :frowning: . BTW, I posted pretty much the same question on your dev rel forum if you want to let any more information slip there :wink: .

Oh boy :slight_smile:

We obviously won’t call this “ARB_compromise_buffers”, so what name should we use?

The workgroup also seems to be happy about it :slight_smile:

I didn’t quite got the renderbuffers idea. They are there simply to provide some intermediate buffer like depth/stencil? What about performance? I mean, will renderbuffers be faster in render ( :rolleyes: sry for style) then textures? If so, some copy command would be nice to have(if we do layered multipass for example) to move the contents of the renderbuffer to a texture.

Nice work guys. :smiley:
Althought it would never take SO long if the workgroup would be reduced to 2-3 persons. Well, politics is hard stuff(diplomacy also)

P.S. The issues list…
:eek:

Off the top of my head, I can’t see why you’d need multiple RCs with this extension (at least I can see why I’d need them).
Multiple windows. Some people do use them. Now that pbuffers are officially dead (and good riddance), the only real reason to open up an entirely new context is to deal with rendering to multiple actual windows.

We’ll expose the extension as soon as we’re confident it’s stable, fast, and correct.
So this isn’t going to be one of those magic nVidia launches where you deploy a fully functional, reasonably bug-free implementation of a spec on the day it releases?

You guys are slacking off. And I was that close to buying a 6600GT… :wink:

I didn’t quite got the renderbuffers idea. They are there simply to provide some intermediate buffer like depth/stencil?
Textures are still restricted to powers of two (unless you have NPOT to relieve this). Renderbuffers are not. So, if memory is of a great concern, and performance is of lesser concern, you can still render to an off-screen renderbuffer and read it back with a CopyTexSubImage or a ReadPixels.

Also, if you are doing RTT, and you need depth tests, but you don’t want to keep the depth data around, it’s probably best to use a Renderbuffer for the depth buffer.

If so, some copy command would be nice to have(if we do layered multipass for example) to move the contents of the renderbuffer to a texture.
We have one. glCopyTexSubImage. When you bind a framebuffer, all operations, to or from, the framebuffer go to the bound buffer.

BTW, I found the logic for issue #79 to be dubious at best. What, specifically, would be “too problematic to introduce this type of invariance?” It seems pretty simple to specify: when a texture is bound to a framebuffer, the implementation is allowed to screw with the internal format as it wishes. These changes should be persistent after the texture is unbound. And it makes it much more difficult to build a framebuffer that comes up “FRAMEBUFFER_UNSUPPORTED_EXT”, as unsupported formats can be converted into supported ones.

At the very least, we should have hints that allow us to say, “framebuffer-compatible RGBA texture”, as our internal format.

I’ve notice that a whole lot of stuff is being left to layers. Not truly external (and large) functionality like RTVA, but fairly important stuff like enumerating formats/selecting formats and binding buffers of different sizes. Is there any real ETA on these guys? Are they in active discussion?

Originally posted by Korval:
Multiple windows. Some people do use them. Now that pbuffers are officially dead (and good riddance), the only real reason to open up an entirely new context is to deal with rendering to multiple actual windows.
Fair enough. I’ve just never come across a situation where I might need separate RCs and shared fbos, apart from the whole current pbuffer mess where sharing resources is totally necessary. But I can see where people might use them.

Originally posted by Korval:
I’ve notice that a whole lot of stuff is being left to layers. Not truly external (and large) functionality like RTVA, but fairly important stuff like enumerating formats/selecting formats and binding buffers of different sizes. Is there any real ETA on these guys? Are they in active discussion?
I can’t see how binding buffers of different sizes would work. How do you simultaneously write to pixel (x,y) when the buffer sizes are different? Or do you mean bind 2 buffers A & B and write to A then write to B in separate passes? I guess on this (and the multiple RCs issue) I’m hoping that fbos are lightweight enough that creating multiple fbos won’t impact that heavily on performance over one main fbo. Multiples don’t seem to be so bad with D3D RenderTargets and I’m using about 12 RTs or so per frame.

On the formats issue, I guess that’s up to the programmer. I have a pretty good idea of what’s happening in my work so this wouldn’t be an issue for me. I can see how a really big shared project might have to worry about it a bit more, but IMHO it’s not a major concern. Just requires a consistent framework in the project for texture management.

Off the top of my head, I can’t see why you’d need multiple RCs with this extension (at least I can see why I’d need them).
Multiple rendering contexts are used in multithreaded and / or multiwindowed code.

I can’t see how binding buffers of different sizes would work.
It doesn’t. Everything bound to a framebuffer object must have the same dimensions.

I’ve notice that a whole lot of stuff is being left to layers.
You noticed. :slight_smile: Basically, everyone involved in the working group is exhausted. Some of us have been on this for two years. The “107 revisions” happened in the last 6 months. We’re going to take a break, make some language tweaks to the spec, then launch into layered functionality. Wish us luck. :slight_smile:

any ballpark figures on what speedup we will expect to see with this vs copytexsubimage. 10% 100% 1000%.
my app (near alpha release btw) does a large (1-100) number of texture updates per frame

I can’t see how binding buffers of different sizes would work. How do you simultaneously write to pixel (x,y) when the buffer sizes are different?
The same way you do in D3D: the smallest buffer defines the largest defined rendering region.

On the formats issue, I guess that’s up to the programmer.
No, it isn’t. Which formats are available (in which combinations) is implementation defined. While you can assume that 32bit color and depth buffers will work (to some degree), what about combinations of 16-bit color and 32-bit depth? On some hardware, it works, and on some hardware it doesn’t. FBO gives us no way to know what bound buffer (or combination thereof) caused the system to reject the framebuffer. The proposed extension would give us that ability.

It doesn’t. Everything bound to a framebuffer object must have the same dimensions.
No, EXT_FBO requires this. That doesn’t mean that you can’t define such behavior; only that the spec doesn’t allow for it.

I hope this runs on older hardware, too. would be nice to have an “easy” way for rtt on non-state-of-the-art engines.

Korval, from the “Multiple Render Targets” help page from the December 2004 DX SDK update:

“All surfaces of a multiple render target should have the same width and height.”

I can’t see how anything else would make sense.

Re the formats, I don’t need portability and I have a 6800GT so the issue wouldn’t come up for me. Plus I never use depth buffers. But yeah, in hindsight I see how it might get tricky managing things. I guess you could conceivably come up with a wrapper to create framebuffers effectively, but that might get a bit complex.

It is like the second coming of Christ! :smiley:
Is there any Forceware leaked driver with an implementation? Please… :slight_smile: