What the: NVIDIA glBlendFunci on GeForce 8 !

[kRogue]

This is a pretty minor bug, and possible not really a bug, but worth noting/reporting:

Current NVIDIA GL drivers on GeForce 8 correctly do NOT list GL_ARB_draw_buffers_blend in their extension string jazz, but the functions glBlendFunci and glBlendEquationi can be fetched (via glXGetProcAddress). Also calling glEnablei(GL_BLEND, buffer) and using both glBlendFunci and glBlendEquationi does NOT result in any GL error, but results in very poor performance, but the output is the same. I guess that the function entry point exists is ok, especially since the same driver is for GeForce 6,7,8,9,1xx,2xx,3xx and 4xx... but I'd imagine that there are codes out there that don't check the extension string jazz, but only check if they can fetch the function pointers..


-Kevin

[Dark Photon]

This is a pretty minor bug, and possible not really a bug, but worth noting/reporting:

Current NVIDIA GL drivers on GeForce 8 correctly do NOT list GL_ARB_draw_buffers_blend in their extension string jazz, but the functions glBlendFunci and glBlendEquationi can be fetched (via glXGetProcAddress).

No problem there, is there? glXGetProcAddress isn't required to limit what entry points it returns based on the GL version+extensions that your GPU supports.

The NVidia drivers contain all the entry points supported by the most recent GL supported by the driver (both via exported dynamic lib symbols and glXGetProcAddress, the former of which cannot be arbitrarily "dialed back" based on your GPU. You wouldn't want it to stop linking randomly on different GPUs anyway.)

But the GL version it reports and available extensions is dynamically dialed back at run-time based on your GPU's capabilities.

Also calling glEnablei(GL_BLEND, buffer) and using both glBlendFunci and glBlendEquationi does NOT result in any GL error, but results in very poor performance...

That would seem to be a problem, since this is only mentioned in the GL4.0 spec (not supp on GF8) and ARB_blend_func_extended (which is supported, but...) where it says:

If ARB_draw_buffers_blend is not supported, all references to BlendFunci and BlendFuncSeparatei should be removed. In this case, the blend functions for all attached draw buffers will be the same.

[kRogue]

No problem there, is there? glXGetProcAddress isn't required to limit what entry points it returns based on the GL version+extensions that your GPU supports.

The NVidia drivers ...

But the GL version it reports and available extensions is dynamically dialed back at run-time based on your GPU's capabilities.

Yeps... that is why I say "and possible not really a bug". Get kind of into wacky land in fetching functions that are in an extension that is not listed.

If ARB_draw_buffers_blend is not supported, all references to BlendFunci and BlendFuncSeparatei should be removed. In this case, the blend functions for all attached draw buffers will be the same.

what does " all references to .. should be removed" mean precisely? I've always read that as "all references within the extension specification document should be removed".

I freely admit that this is off onto undefined/wacky land behaviour, since the extension was NOT listed.. I would prefer a GL error or something though. Maybe the debug contexts print something in this case, worth checking that is... check that I will (eventually)

[Dark Photon]

what does " all references to .. should be removed" mean precisely?

Think they just mean removed from the language in the extension spec, if you don't have the extension. With that, there's no need to predicate the mentions in the base spec.

But yeah, I agree. GL error would be good here.