[Mesa-dev] [PATCH] st/mesa: remove ARB_color_buffer_float from core profile contexts

Ilia Mirkin imirkin at alum.mit.edu
Tue Jan 10 16:13:52 UTC 2017

On Tue, Jan 10, 2017 at 10:31 AM, Nicolai Hähnle <nhaehnle at gmail.com> wrote:
> On 10.01.2017 16:21, Ilia Mirkin wrote:
>> This will just cause shader based workarounds in the affected
>> applications, no? What's the benefit of removing this? Fwiw, Nvidia hw
>> has support for this.
> It's only supposed to remove the extension string, nothing else. Can you
> explain in which scenario you would expect a shader-based workaround?
> The benefit of removing this is that it sidesteps a silly spec lawyering
> issue, which is that:
> 1. If we advertise an OpenGL core context, we're supposed to _not_ support
> 2. ARB_color_buffer_float on the other hand says that those enums _should_
> be supported.
> It's not clear how to reconcile these two when both are advertised. The
> GLCTS expects the enums to be unsupported in core contexts, no matter which
> extensions are present.
> If the NVidia blob advertises ARB_color_buffer_float also in core contexts,
> it probably just doesn't "fully implement" the extension. We could do the
> same by changing the check in _mesa_ClampColor instead of this patch

Hmm. My understanding was that exposing ARB_color_buffer_float *was*
supposed to enable the clamping functionality. But GL 3.1 came after
the ext did (and was subsumed into GL 3.0), so ... odd.


The proprietary NVIDIA, AMD, and even Intel drivers on Windows appear
to expose it in core contexts. However I have no idea if the clamping
functionality is still there or not.

> I don't care much either way, but this patch brings us in line with what the
> Intel driver has been doing since 2013...

I suspect that's more because they didn't have the clamping logic in
hw and didn't want to unnecessarily expose variants.

If it's not too difficult, could you see what fglrx did with it? Or
maybe someone with easy NVIDIA blob access?


More information about the mesa-dev mailing list