What the: NVIDIA glBlendFunci on GeForce 8!

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

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:

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.

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) :o

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.

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.