[Mesa-dev] [PATCH] [rfc] mesa: don't allow GLSL 1.30 without GL3.
kenneth at whitecape.org
Fri Jan 20 14:00:26 PST 2012
On 01/20/2012 03:06 AM, Dave Airlie wrote:
> On Wed, Jan 11, 2012 at 5:40 PM, Paul Berry<stereotype441 at gmail.com> wrote:
>> On 10 January 2012 13:38, Christoph Bumiller<e0425955 at student.tuwien.ac.at>
>>> On 01/10/2012 10:09 PM, Dave Airlie wrote:
>>>> On Tue, Jan 10, 2012 at 7:28 PM, Eric Anholt<eric at anholt.net> wrote:
>>>>> On Tue, 10 Jan 2012 11:52:57 +0000, Dave Airlie<airlied at gmail.com>
>>>>>> From: Dave Airlie<airlied at redhat.com>
>>>>>> Things can get confused if you expose one without the other which can
>>>>>> if you are missing one or two of the extensions (like say float
>>>>> Can you clarify what "things can get confused" means?
>>>> Well piglit starts to fail in wierd and wonderful way, I just don't
>>>> think we have any valid use cases for exposing GLSL1.30 without GL3
>>>> and I'd like to enforce that.
>>> Some tests only check for GLSL 1.3 and then use functions like
>>> glUniform*ui that glew only sets up if GL_VERSION_3_0 and as a result
>>> they call a NULL pointer.
>> Personally I would call this a flaw in the piglit tests. If sloppy
>> dependency checking in piglit tests is our only reason for making this
>> change, then I'd rather fix the piglit tests rather than constrain what GLSL
>> version Mesa can advertise. It was really useful for us in our GL 3.0 work
>> on Sandy Bridge to be able to enable GLSL 1.30 support when it was ready,
>> and not have to wait until we had all the components of GL 3.0 in place
>> before we could start testing the GLSL 1.30 features.
> At a guess you guys used version overrides, so I can't see how this
> constraint would stop it being really useful.
Right. We can override the versions to be whatever. No big deal.
> The thing is no application in existance is expected GL2.1 + GLSL
> 1.30, like what features of GLSL1.30 would a GL2 targeted app use? and
> the fact that our own test suite chokes on it should show this.
> If we finish EXT_gpu_shader4, then we should expose that, but exposing
> GLSL 1.30 without the means for applications to get access to the
> features via the GL api is just going to hurt.
> I don't mind carrying this in Fedora, but we have to realise that
> nearly all vendors can't ship GL3 drivers currently so we should try
> and keep things working. Maybe when we get EXT_gpu_shader4 we can
> revisit and check if GLEW can do the right thing.
In principle, it seems like we ought to be able to expose newer GLSL
without necessarily bumping GL version...but I agree, it seems like it
would likely cause more harm than good.
Reviewed-by: Kenneth Graunke <kenneth at whitecape.org>
More information about the mesa-dev