GL_EXT_blend_func_separate on NVIDIA hardware

“Separate blend functions was promoted from the GL EXT blend func separate extension.” (OpenGL 1.4 specifications). NVidia OpenGL version on 4x drivers is 1.4 and still the extension is not listed in the extension string.

Nevertheless, you can call wglGetProcAddress (“glBlendFuncSeparateEXT”) and obtain a pointer to the function. I did this (because I need this extension to spare another rendering pass on nv2x rc bump) but the program locks when using different blend factors for rgb and alpha (works fine when using the same). Is this a software (driver) bug (and for this reason the extension was removed from the string) or the hw is not capable (which I doubt) to do it ???

I’ve tried this on detonators 29.42, 40.72, 40.09 on win2k, GeForce 4 Ti4200.

The only hardware that supports seperate blendfuncs in hardware are the Radeons ( 8500 and above ) and the GeForceFX when available ( possible some other vendors too but I’m not very familiar with those ). The reason you won’t find it in the extension string for the GF4, is because NVIDIA doesn’t expose extensions that won’t “run well” on their hardware. I’ll bet it will appear in the string for the GeForceFX.

Here’s a thread where I asked a similar question,
http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/004312.html

Thanks for the info

So after all none of nvidia hardware is OpenGL 1.4 compliant !

If the GL driver ever returns “1.4” to the GL_VERSION query, then you may assume that all OpenGL1.4 features are available, even if the corresponding extensions are not visible in the GL_EXTENSIONS query (and it could even be necessary since some features differ when promoted from an extension to the core).

Originally posted by vincoof:
If the GL driver ever returns “1.4” to the GL_VERSION query, then you may assume that all OpenGL1.4 features are available, even if the corresponding extensions are not visible in the GL_EXTENSIONS query (and it could even be necessary since some features differ when promoted from an extension to the core).

Yeah, but the problem is that glBlendFuncSeparate is not working on the Nvidia OpenGL 1.4 current hardware. This is a mandatory function in GL 1.4

Does the GL driver returns “1.4” to the GL_VERSION query ? If so, it’s a driver bug. Minor, but a bug nonetheless. Should either return “1.3” or provide the feature in software.

You see, I think that Nvidia can’t afford right now to admit that their products are only OpenGL 1.3.1 compliant, while R200 and above support 1.4.

Anyway, is there a way to get headers and dll support for OpenGL 1.4 without using the extensions (something like it was gl.h for GL 1.1 from microsoft)? Is there a real effort to make the GL support up to date on Windows? I saw that in .NET the old 1.1 headers were removed completly (thanks again microsoft!)

Yes I know what you mean with NVIDIA driver versions. Not so long ago I used accumulation buffer on a GeForce2 and couldn’t make it working, not even in software, even though it’s a feature of OpenGL1.0.
As a side note, I’m not sure that ATI really supports 100% of OpenGL features they expose, also.

Today you still have to support OpenGL1.1 in Windows. If you were developing for MacOS X or Linux you could enjoy greater OpenGL support, but not for Windows yet.

Originally posted by licu:
Nevertheless, you can call wglGetProcAddress (“glBlendFuncSeparateEXT”) and obtain a pointer to the function.

Try glBlendFuncSeperate without the ‘EXT’ suffix.

Two questions:

  1. You’re saying it “locks up” – how, exactly, is it “locking up” ?

  2. When an extension gets promoted, the suffix (EXT, ARB, etc) gets dropped – did you ask for “glBlendFuncSeparate” ? (Of course, you could only do that if the OpenGL version returned is 1.4 or better)

My guess, assuming that 2) is doing alright, is that the answer to 1) is that it actually didn’t lock up, it just went to software rasterization. VERY SLOW software rasterization.

Originally posted by vincoof:
Does the GL driver returns “1.4” to the GL_VERSION query ? If so, it’s a driver bug. Minor, but a bug nonetheless. Should either return “1.3” or provide the feature in software.

We do provide this feature in software, and it definitely does work in software. So this is in no way a bug.

  • Matt

Okay,
I asked for „glBlendFuncSeparateEXT”, I will try without EXT. ”Locks up” means the screen goes blank (so the prior frame is replaced) and the programs is not responding. Most likely, yes it is in software rasterization mode, I will check.

Thanks for all the answers, I will get back to this post tomorrow to clarify this. I removed the glBlendFuncSeparate code with another solution so I will put it again and wait longer to see if the frame eventually appears.

Jwatte, Mat,
You were right, the glBlendFuncSeparateEXT was running in software. It took more than 1 minute for a frame to appear (while a similar solution in hardware was running on more than 60 fps). Sorry for this…

Jwatte, Mat,
You were right, the glBlendFuncSeparateEXT was running in software. It took more than 1 minute for a frame to appear (while a similar solution in hardware was running on more than 60 fps). Sorry for this…