[Mesa-dev] [RFC] glsl: bump default glsl version to 130 if EXT_gpu_shader4 used

[Marek Olšák]

On Tue, May 15, 2018 at 4:59 PM, Jason Ekstrand <jason at jlekstrand.net>
wrote:

> On Tue, May 15, 2018 at 1:38 PM, Marek Olšák <maraeo at gmail.com> wrote:
>
>> On Tue, May 15, 2018 at 4:09 PM, Ilia Mirkin <imirkin at alum.mit.edu>
>> wrote:
>>
>>> On Tue, May 15, 2018 at 3:54 PM, Marek Olšák <maraeo at gmail.com> wrote:
>>> > On Tue, May 15, 2018 at 3:36 PM, Ilia Mirkin <imirkin at alum.mit.edu>
>>> wrote:
>>> >>
>>> >> The extension is totally different... it adds things like "unsigned
>>> >> int", and a ton of texture*/shadow* variants. If it helps this one
>>> >> shader compile, that's a coincidence. IMO it's dangerous to start
>>> >> throwing things like this in.
>>> >
>>> >
>>> > That's why it prints a warning. The extension isn't exposed.
>>>
>>> It bumps the GLSL version to 1.30 though, which e.g. makes "in" and
>>> "out" a keyword. And a bunch of other stuff like that. Just seems
>>> dangerous.
>>>
>>
>> It may seem dangerous, but not after you consider that it changes a
>> compile failure into "some behavior" and a warning. That is pretty safe,
>> because you'll either get a compile failure again, or you'll get correct
>> behavior as if a subset of the extension was exposed. Either case is
>> harmless.
>>
>
> This does seem really sketchy.  It's a spec violation because we are
> required to fail the shader compile for unknown extensions.  And it's
> letting a shader through even though we know it's likely to die in a fire
> later on due to the fact that we only implement 30% of gpu_shader4.  On top
> of that, the best justification we can come up with is a broken app that
> assumes gpu_shader4 but doesn't actually use it.
>

The best justification that we actually have is that there is an app which
uses GLSL 1.20 + EXT_gpu_shader4 but actually only needs GLSL 1.30.

Marek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20180515/86b1af7a/attachment.html>