Native R32F and G32R32F support in OpenGL

Nadro · Post by **Nadro** » Sun May 31, 2009 10:17 pm

Hi, This is patch for native support R32F and G32R32F in OpenGL:
http://nadro.net46.net/Patches/irrlicht ... _ogl.patch
In first version OpenGL FP RTTs has got always GL_RGBA32F_ARB or GL_RGBA16F_ARB, so performance drop if You need only R32F or G32R32F channels...

sio2 · Post by **sio2** » Mon Jun 01, 2009 6:38 pm

Excellent.

Couple of questions:
1. Is there FP texture support for DX9?
2. It would be nice to be able to query the driver as to what filtering is supported FP textures.

Nadro · Post by **Nadro** » Tue Jun 02, 2009 1:04 pm

sio2 wrote:Excellent.

Couple of questions:
1. Is there FP texture support for DX9?
2. It would be nice to be able to query the driver as to what filtering is supported FP textures.

1. Yes

It's avaiable in Irrlicht rev 2398.
2. This is very good idea, it will be very usefull for switching between hardware filtering and emulate filtering in shader.

BlindSide · Post by **BlindSide** » Fri Jun 05, 2009 7:05 am

Ah thanks Nadro nearly missed this. Will look into it soon.

2. It would be nice to be able to query the driver as to what filtering is supported FP textures.

Yes filtering, and blending support is now a concern that we have floating point render targets. We're going to need some robust way of handling these capabilities.

In first version OpenGL FP RTTs has got always GL_RGBA32F_ARB or GL_RGBA16F_ARB, so performance drop if You need only R32F or G32R32F channels...

Actually they are using GL_RGB32F_ARB and GL_RGB16F_ARB, but still bad...

EDIT:

A closer looks seems that you are not using the ARB versions anymore. Will this cause any compatibility problems?

Nadro · Post by **Nadro** » Fri Jun 05, 2009 8:55 pm

I tested it on Radeon 4850 and Radeon 9550, with the latest version of catalyst and all works properly on both cards.

BlindSide · Post by **BlindSide** » Sun Aug 02, 2009 4:46 am

Patch applied.

NOTE: Irrlicht currently checks that "GL_ARB_texture_float" is defined before using floating point texture types. It works fine on my machine but I'm curious if people using OGL extensions only will have problems with this, should I check for ARB vs OGL 2.0 support and pick between the two types?

hybrid · Post by **hybrid** » Sun Aug 02, 2009 12:38 pm

Yes, unfortunately, we need to check for all possible extensions and use the proper define for each of them. There is usually no problem with default OGL usage, because we have our own glext.h and thus all symbols are dfined. But once someone uses a specific glext version (or none at all, e.g. by compiling without extension pointers) there are not all symbols defined anymore. I do check such things on Solaris machines usually, where I have a very restricted OpenGL version installed. But using old drivers without extension pointers will do the same job usually.