Entropy's picture

[SOLVED] FrameBufferObjects not supported by nVidia drivers?

I suspect this might be the case when I sent a release configuration of my project to a friend and he told me a it didn't render properly. I had a sneaking suspicion that the nVidia XP drivers woudn't support the same extensions as the ATi ones...

My XP installation (which, it seems is no longer available, but that's another story relating to a dodgy HD) didn't throw any unhandled debugging exceptions - it just went on and rendered a grey textbox I'd used as a floating debugging window over the entire game window. It does this even if I disable the command to draw this FBO as a texture. As the debug window is the last item to be rendered to a framebuffer before I draw to the visible one. This is exactly what my friend saw on his XP/nVidia system.

VS2008 in my XP Virtualbox on Ubuntu throws a NullReferenceException when I try to call the GL.Ext.GenRenderBuffers(...) method. I've no idea why it handles the problem differently, but it's actually more helpful to be told the extension is unsupported (if the exception means what I think it does).

So like I say, I suspect this new drivers are to blame.

I'm using FrameBuffers at the moment by closely following Inertia's very helpful tutorials in the Documentation section of this site. I notice, however, that a lot of similar methods seem to exist outside of GL.Ext. What's the difference with these, and how can I use framebuffers without calling the unsupported methods?


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
martinsm's picture

VS2008 in my XP Virtualbox on Ubuntu throws a NullReferenceException when I try to call the GL.Ext.GenRenderBuffers(...) method. I've no idea why it handles the problem differently, but it's actually more helpful to be told the extension is unsupported (if the exception means what I think it does).

You should check if EXT_framebuffer_object extension is supported manually if you need such extension support. Always. Don't assume that GenRenderBuffers (or different) FBO extension function will be always available. For example, if user will use very old drivers, it is completely normal that driver reports that FBO is not supported while video card supports it.

If extension is not supported you are not allowed to use any entrypoint of this extension. It will lead to undefined behavior (usually crash of program).

This also true for any extension.

Entropy's picture

Thanks for the tip. I'll make sure to add that check when using extension methods in future.

In this case, I'm using up-to-date drivers for a graphics card I jsut upgraded. The extension worked fine for the ATi drivers (as my card had just been relegated to ATi's legacy driver list, both the drivers and the card were considerably older than the ones I installed yesterday). The NEWER card and drivers don't seem to support the extension.

Are there any suggesti0ns for alternatives?


the Fiddler's picture

Regarding Ubuntu, if you have an Ati video card older than an R600 (2000-series), you will be using the open source drivers which only support OpenGL 1.3 at the moment (without FBOs...)

The driver is being rewritten at the moment and the new code contains support for FBOs (I think it will support OpenGL ~1.5). This will probably be included in Ubuntu 9.10. There is yet another rewrite underway (building on the previous one, fortunately) that will add support for OpenGL 2.0+ through Gallium3D, but I wouldn't expect this before 2010.

As martinsm said, you have to check with GL.SupportsExtension("extension_name") before using FBOs or any other extension. You can also opt to target a specific OpenGL version that guarantees your extension is supported (e.g. FBOs are always supported in OpenGL 3.0+, GLSL is always supported in OpenGL 2.0+). However, the latter approach will exclude users with older cards that support, for example, FBOs without supporting the whole OpenGL 3.0 spec (like ati R300-500 cards, or nvidia NV20-NV40).

Edit: Which models are the cards in question?

Entropy's picture

My old ATi card was a Radeon X1950. As ATi no longer proprietary driver support for the latest version of Ubuntu, I didn't have full 3d support for that anyway, so I had to do my coding in XP.

Yesterday, I removed the older ATi card and installed a newer nVidia GeForce GTX 260. I installed the latest proprietary drivers on both operating systems. My project wouldn't render properly on either. It's these drivers that don't seem to support the extensions in question (though I'll run the check when I get home from work to be sure that's the problem).

Aside: It was amusing to see XP/Ubuntu react differently to my new hardware config. XP effectively said "What the f*ck have you done to my computer!?" and needed three restarts before it was running smoothely. Ubuntu simply suggested I enable the proprietary drivers by checking a box in Jockey. I had to move an already-installed PCI card to another slot to fit the MONSTROUS new graphics card in. Ubuntu quietly compensated. Last night, after several reboots, my XP install still couldn't figure out the new configuration without my help. X-D

the Fiddler's picture

The GTX 260 supports everything between OpenGL 1.1 - 3.1, assuming the driver installation works. OpenTK comes with an "OpenGL Extensions" sample, that reports which functions are supported - everything FBO-related should be green. If it is not, this could indicate a driver problem: is the renderer "nvidia corporation" and OpenGL version "3.0" or higher?

The sad truth is that seemingly fine code that works on one vendor may break on another. This is especially true for GLSL programs, but also affects FBOs - a specific FBO configuration may be renderable in one card but unsupported in another.

Suggestion: try updating to the latest OpenTK version from SVN and run with the debug version of the dll. It will break as soon as it hits an OpenGL error, which makes problems like this much easier to debug.

Entropy's picture


Thanks, Fiddler.

I'll upgrade my project to the latest OpenTK release. I'm using a slightly modified version (tweaked the GameWindow class slightly as a temporary measure until I get my second-thread timing working properly in my MusicManager bufering class), but I'll run the new source with my tweaks in debug config to see what it throws up, and try to get the FBO rendering from there.

Good side to this is that I've learnt a) always to check for extensions support and b) it's worth double checking cross-vendor functionality (as opposed to just assuming your code will work).

Edit: for projects that DO currently run in my virtual XP install, 3D support in the seems to be slow. Not sure if that's a symptom of a a virtualbox environment, or lacking/poor openGL "passthrough" between the virtualbox environment and the native drivers. Perhaps this is a silly question, but should I be installing drivers for my virtual XP installation?

the Fiddler's picture

You only need to install the VirtualBox drivers (there is a menu item that reads "Install Guest Additions"). Also don't forget to upgrade these every time you upgrade VirtualBox.

Unfortunately, 3d in VirtualBox is rather slow at this time - usable, but slow.

Edit: the suggestion to use OpenTK SVN was to just help debugging - it shouldn't actually affect anything else. However, debugging becomes *much* simpler this way - you get an exception with the OpenGL error and a stacktrace pointing to the exact location of the error. It becomes virtually impossible for an error to slip through, which might have led to strange behaviour later on.

Entropy's picture

Yeah, the "Guest additions" are installed and up-to-date. Just slow, I guess.

the Fiddler wrote:

Edit: the suggestion to use OpenTK SVN was to just help debugging.

Yeah, I know. I'll play around tonight to see if I can figure out where the problem lies. Not sure why I should get a NullReferenceException for the GL.Ext.GenRenderbuffer() in any case, but I'll investigate GL extension support in both vb-XP and Ubuntu direct to see if there's a difference.

Unfortunately, I don't have access to native XP install any more as my SATA HD copped it without warning this morning, with my entire mp3 collection and XP install on it. :-(

Luckily, I'd backed up everything that REALLY mattered (and I've been emailing regular svn dumps of my LinkSphere solution to myself), but I'm not as confident yet in a Linux environment, so I've also got to contend with the knowledge that I might not have everything set up correctly.

Entropy's picture

Quick update:

Spent a lot of time faffing around last night setting up a svn repository in Ubuntu (I'm missing TortoisSVN's Windows Explorer integration - RapidSVN really doesn't compete).

Checked the Extensions OpenTK Example, and my card DOES have the extensions supported. I did finally RTFM for Virtualbox and realised I hadn't enabled 3d support (D'oh). General 3d performace did improve (slightly) from Microsoft's default implementation, but LinkSphere crashed the VM when I tried to run it. I didn't have the patience at that point to try rebooting it and fiddling around with the FBO stuff by that time (assuming that what crashed it), so I settled for updating my OpenTK version instead and left it at that.

With 3D support as slow as that in Virtualbox, I'll probably be developing MonoDevelop instead, anyway - which is why I loaded my svn dump in a Ubuntu repository.

the Fiddler's picture

FYI, MonoDevelop has excellent SVN integration, similar to VisualSVN. You have to install the subversion add-on - I think the package is called something like "monodevelop-versioncontrol-svn", but check through synaptic.