GL_EXT_framebuffer_object support?

I’m doing some OpenGL programming and looking for support for GL_EXT_framebuffer_object. One (of several) test machines I have contains a GeForce 440MX PCI video card with Windows 2000.

I thought GL_EXT_framebuffer_object was supposed to be available with the latest drivers. I’ve tried both the 78.01 and 81.84 beta drivers on this system, using driver cleaner before each install. Each time, the GLView program from the book “OpenGL SuperBible” doesn’t show GL_EXT_framebuffer_object in the list.

On my home machine, running WinXP 64-bit edition, an NVidia 6800nu, and the 77 drivers, GL_EXT_framebuffer is present and shown in GLView.

Can any one help me determine why why I can’t get framebuffer support on the 440MX card?

thanks,

Jeff McWilliams

Hi Jeff,

Support for FBO is currently focused on more recent architectures (GeForce FX and beyond). Some support for less capable hardware may eventually show up, however, as FBO becomes more standard.

Thanks -
Cass

Cass, while I appreciate you at least saying something (which an ATI representative hasn’t even bothered to do), your answer raised a few questions (more like warning flags) here.

“may eventually” is to me marketing speak for “dream on”. Do you mean “we are seriously considering it”, or is it more like “Oh, shut up you whiners - buy 7800 and a small nuclear power plant to drive it and be silent”?

The continuation “as FBO becomes more standard”, does that mean “when it’s promoted to ARB”, at which time I predict you will no longer sell any AGP hardware to support why all nvidia ‘offerings’ will have this, or does it only mean “when competing companies supports FBO for their previous generation of cards, then we’ll add it too. If you want FBO, buy new h/w from us”?

I might be cynical, but your companies are after all in this bussiness to rip us off as hard as you can. Assuming the worst of you is then quite logical.

That both of you large behave like this when it comes to the ONLY cross-platform/portable RTT extension is making me sick. If anything, you should both scramble to add it to the lowest-end hardware you both have/sell/support to display “We really, REALLY care about our customers”. Instead nvidia seemingly tries to string their customers with older cards along for a ride, and ATI just flips their customers the birdy (silence, and more silence).

I don’t think I have to explain how badly such public support of the very extensions you as ARB members have promoted reflects on the ARB, when you as companies don’t even try to support it for hardware capable of it. I think you look even worse when you don’t even say why you don’t, and not even if there are hardware limitations or that you don’t just give a fsck.

End of rant.

don’t sugar coat it, tamlin, tell us what you really think.

im pretty sure nvidia will add it eventually at the moment its still immature, its EXT_fbo, ie not even ARB. also i believe at the moment they changing a few things

if memory serves correctly nvidia have done this before ( released support for something with the newer cards first + later adding support for older ones, which is fair enuf, its better some ppl are able to play with it than delaying it until its ready on all cards, esp with FBO the natives were restless )

Hi tamlin,

I’m sorry I cannot say exactly when we will support FBO on older hardware. It’s a non-trivial amount of work to implement it. Eventually I would expect support on all the hardware we support pbuffers on, but I hope you can appreciate that newer architectures must have priority.

Thanks -
Cass

That both of you large behave like this when it comes to the ONLY cross-platform/portable RTT extension is making me sick. If anything, you should both scramble to add it to the lowest-end hardware you both have/sell/support to display “We really, REALLY care about our customers”. Instead nvidia seemingly tries to string their customers with older cards along for a ride, and ATI just flips their customers the birdy (silence, and more silence).
Huh?

Let’s be honest: programs that will be developed expecting FBO support will not be made for older cards. Games will be made for newer generations of cards, and other applications will be made for professional cards. The specific need for FBO on older hardware is weak at best.

So it would actually serve few of their customers to bother extending FBO support to older hardware.

Let’s be honest: programs that will be developed expecting FBO support will not be made for older cards. Games will be made for newer generations of cards, and other applications will be made for professional cards. The specific need for FBO on older hardware is weak at best.
My development is for a professional finite element analysis post processing program. It’s mainly professional cards that we target. It just happens that we have some cheap consumer grade cards, as well as Quadros and FireGLs, and they’re all used for testing.

While I agree that games purchasers may be more willing to purchase a newer card, my perception is that users of engineering software are a lot more conservative. We still have a significant customer base doing work on HP Workstations, which have relatively ancient OpenGL support compared to the featureset available on a current QuadroFX or FireGL.

With such a diverse set of users, we’re always closely evaluating the cost/benefit of using a new OpenGL feature. For FBO in particular, making it available on older Quadro cards would make the justification easier.

As it stands for my particular case, I’ve given up on FBO for now and resorted to pbuffer for what I needed to do. Being able to avoid the API differences of pbuffer between wgl__() and glX__() would have been nice, but at least pbuffer is available on older hardware.

First of all, let me apologise.

Reading what I wrote, it looks more than very critical and cynical. I can only explain it by: the post was written under the influence of much frustration.

cass,
Thank you (very much). I (really) expected nothing less from nvidia, but your initial words got me worried. While I feel I shoudn’t have had to apply this pressure, at least your comment put my worries to rest about nvidia’s committment to OpenGL, why it at least served its purpose.

Should other vendors (e.g ATI, Intel or 3DLabs) care to also state “we also expect to add FBO support for all cards supporting pbuffers” I’m sure many exisiting and potential future customers would appreciate your committment to OpenGL.

Korval,
your opinion makes me think of a gfx manufacturing company’s perfect customer - not caring the least for the millions upon millions of customers of already installed hardware systems where FBO could really, seriously, and to no little extent increase the speed, reduce delays or even allow interoperability, but instead only say “buy new, new, new”.

You might also not think of game producers still caring about customers, that might add FBO as a “patch” to their games currently forced to exclusivley use pbuffer. If such a “patch” made them graphics compatible between Win32, Xwindows and Mac OS X, they might even consider porting input and sound to SDL and OpenAL, and get into previously not experienced markets.

If one is only thinking of only the most 3D graphic intensive games, only people having the latest-and-greatest hardware would benefit from FBO. But then, why would ARB even have mentioned pbuffers in the spec?

I wrote something to the effect “I’d expect FBO to be supported on anything from TNT and ATI 7000”.

To again quote cass:
“I would expect support on all the hardware we support pbuffers on”.

I’d say cass isn’t “expecting” this on a whim, but on actual knowledge of what is required and supported by the hardware. If “chip 1.0 anno 1998” supports pbuffers, it can also support (a subset of) FBO.

Korval then wrote:
The specific need for FBO on older hardware is weak at best.

Then, at best, specific need for pbuffer has also always been weak. After all, FBO is among other things the replacement for pbuffer.

If pbuffer has been enough, then surely the same (limited) FBO support can’t be a step in the wrong direction.

I think Jeff McWilliams post explains the rest.

tamlin, are you serious? you expect ihv’s to drop what they’re doing and concentrate on retro-fitting all the old, dusty cards on the planet with the latest features? i think most developers would rather see them apply their energies here in the fore, such as they are. technology is changing too quickly for this backwards compatibility nonsense, though it is an admirable goal if you’re so dispositioned. this isn’t a matter of “care” for customers, it’s good business sense on their part. software is time and money just like hardware is. it’s the economic boom that’s driving the rapid advancement of these chips in the first place. you can’t very well have all this without someone footing the bill. if john q. public wants the latest features, he’ll pay for it; people don’t expect the latest bells and whistels for free, nor should they.

in no other industry on the planet would you see this sort of thing, where technology continually gets better, faster, and cheaper, and yet people still find something to complain about…

your opinion makes me think of a gfx manufacturing company’s perfect customer - not caring the least for the millions upon millions of customers of already installed hardware systems where FBO could really, seriously, and to no little extent increase the speed, reduce delays or even allow interoperability, but instead only say “buy new, new, new”.
No, I’m being a realist in this context. Would I like to see FBO support magically appear on older hardware? Sure. However, I am neither surprised by the lack of it nor am I concerned by it. I recognize that IHV developer time is a precious resource, and that resource must be spent wisely, not just for completeness’s sake. There needs to be a significant justification for implementing such a complex extension on older hardware in order to make such implementations reasonable.

Idealism that asks every IHV to implement FBO in every graphics card that supports pbuffers is the same idealism that is responsbile for asking every IHV to support a C compiler in their driver. Because of that decision, we have glslang implementations that are quite fragile/buggy, fail for reasons that are often difficult to nail down, and various other glslang-related problems. This all makes glslang rather less than desirable from a practical standpoint.

You might also not think of game producers still caring about customers, that might add FBO as a “patch” to their games currently forced to exclusivley use pbuffer. If such a “patch” made them graphics compatible between Win32, Xwindows and Mac OS X, they might even consider porting input and sound to SDL and OpenAL, and get into previously not experienced markets.
Um, that makes no sense.

First, any game currently relying on pbuffers works, and it works fast enough for the game. If it didn’t, then they wouldn’t have been able to use whatever effect that they needed pbuffers for. So there is no impetus to provide FBO patches.

Second, you seem to think that the only thing game developers can do with their time is to create patches for old hardware. Developers create patches when they have to, not when they want to. And they don’t do it when its not going to improve user experience. Pbuffer may be a poor solution, but it is a functioning one where used. Creating a patch that takes a functioning game and slaves it to a new extension is dodgy at best. The only reational for doing that would be improving user experience. You don’t see a Q3 VBO patch somewhere providing VBO support for Quake3. There’s a reason for that.

Third, FBO has nothing to do with cross-platform support. Whether a game goes cross-platform isn’t going to be stopped by the lack of the pbuffer extension on that platform. That decision is made by people who don’t even know what FBO means, let alone the concept of OpenGL extensions. If the higher-ups say to make a Linux or MaxOS port, then the port gets made. The only thing that is up to the programmers is how to make that port.

Then, at best, specific need for pbuffer has also always been weak. After all, FBO is among other things the replacement for pbuffer.
FBO may be a replacement for pbuffers, but understand that FBO implementations do not magically materialize out of thin air. Someone has to write them. Whereas the work for pbuffer implementations has already been done.

You missed an important part of my commentary. Namely, “programs that will be developed expecting FBO support will not be made for older cards. Games will be made for newer generations of cards, and other applications will be made for professional cards.” Jeff makes a pretty reasonable argument against this, but that is only from his perspective, which is likely to be in the minority among OpenGL developers. Since only new applications will support FBO (you can’t support an extension that didn’t exist back when you wrote the code), and since most new applications are not written around ancient hardware, the need for ancient hardware to support FBO is limitted.

I don’t know but it’s not so hard for using PBuffer. There is plenty of high level libraries, even some that internally uses PBuffer or FBO. Why not using them ?

PBuffer is true and tried interfaces, there a lot of documentation, examples and wide support across vendors.

FBO came too late (I means DirectX 9 has a better interface for render into buffer, without switching contexts).

On Windows platforms, only ATI and nVidia supports them (Radeon 9500+ and Geforce FX).

Supporting on other platforms is possible, but a lot of pain for little gain IMHO.

Also new drivers tend to break on old hardware : Vendor implements new features (optimisation that breaks on old motherboards) or updated / bloated control panel that are too heavy for the guy who still got it Radeon 8500 on a his Pentium III 500 Mhz, and preferes to stick with its Catalyst 4.12 instead of upgrading. Would you want to support them as well ?

Just an interesting sidenote: I’m using FBO in my application. I do NOT use PBuffers, heck, I don’t even know how to use PBuffers!! Still, I’ve had some weird crashes (rarely, could never reproduce…), when the nVidia driver would say something bad happened with PBuffers! Huh?? Is it possible that FBO is still emulated internally using PBuffers?

Originally posted by andras:
Just an interesting sidenote: I’m using FBO in my application. I do NOT use PBuffers, heck, I don’t even know how to use PBuffers!! Still, I’ve had some weird crashes (rarely, could never reproduce…), when the nVidia driver would say something bad happened with PBuffers! Huh?? Is it possible that FBO is still emulated internally using PBuffers?
Pbuffers are done in the windowing-system (ie. Windows, glx and so) whereas FBOs use buffers as GL knows them. And as everyone knows, GL has nothing to do with the windowing-system.
So I guess the answer to your question is: no.

Is it possible that FBO is still emulated internally using PBuffers?
Code reuse being what it is these days, I wouldn’t be surprised if FBO implementations borrowed from existing Pbuffer infrastructure to some extent (with the exception of the window-system-specific stuff, of course). That might explain an error message emanating from some place dark and scary.

Is this for a particular NVIDIA card and driver?

All this is only a problem if people are using OpenGL calls directly, which suggests they don’t have the basic services of a renderer. They’re not professional users, they’re hobbiests…why should vendors go out of their way to support hobbiests? Where’s the money in that?
In order to do things like resource management, state caching, redundancy checking, renderer abstraction, sorting, optimisation etc.etc. you need to have a layer on top of opengl. So, with that mechanism in place, why is it such a big deal to use different render-to-texture mechanisms? You should be able to drop in new mechanisms by using polymorphism or templates…a no brainer. Or am I the only one who does things properly around here?

typedef OpenGLRenderer Renderer;
typedef OpenGLTexture Texture;

Renderer renderer;
Texture texture;

renderer.BeginRenderToTexture(texture);
renderer.EndRenderToTexture(texture);

You get the idea?

To add to all the above stuff said, weren’t we just asked for input for the ARB version of FBO.

FBO is beeing improved, which means more work for driver developers, so they will be busy coding for new hw.

All this is only a problem if people are using OpenGL calls directly, which suggests they don’t have the basic services of a renderer. They’re not professional users, they’re hobbiests…
That’s a fairly rediculous assumption. Somebody’s got to be in charge of writing/upgrading the renderer, after all. Unless you’re suggesting that hobbiests are the ones responsible for maintaining all renderers…

Plus, some people’s abstractions aren’t as deep as others’. If you know 100% that you’re OpenGL only (for whatever reason), it wouldn’t be unreasonable at all for an effects programmer to use direct FBO calls and such, rather than using some abstraction layer. Now, if the AI programmer is doing it, then we have a problem.

So you also use win32 specific functions in your application code, do you?
Technology changes at a tremendous pace, it wouldn’t be wise to use third party API services directly in your application code. If you don’t abstract completely there’s no point in abstracting at all.
Using templates, there needn’t be any cost at all in abstracting.
As for “somebody’s got to upgrade the renderer”, well that’s usually their job…what else are they going to do? I suppose they could stretch out writing a fbo implementation of the render-to-texture interface to 1 day tops.

If you know 100% that you’re OpenGL only (for whatever reason), it wouldn’t be unreasonable at all for an effects programmer to use direct FBO calls and such, rather than using some abstraction layer.
You see, to me, that’s like someone saying “what’s the point in GLint when it’s just an int”.