On 16/05/18 09:41, Marek Olšák wrote:
On Tue, May 15, 2018 at 4:59 PM, Jason Ekstrand <ja...@jlekstrand.net
<mailto:ja...@jlekstrand.net>> wrote:
On Tue, May 15, 2018 at 1:38 PM, Marek Olšák <mar...@gmail.com
<mailto:mar...@gmail.com>> wrote:
On Tue, May 15, 2018 at 4:09 PM, Ilia Mirkin
<imir...@alum.mit.edu <mailto:imir...@alum.mit.edu>> wrote:
On Tue, May 15, 2018 at 3:54 PM, Marek Olšák
<mar...@gmail.com <mailto:mar...@gmail.com>> wrote:
> On Tue, May 15, 2018 at 3:36 PM, Ilia Mirkin <imir...@alum.mit.edu
<mailto:imir...@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
I did consider just using force_glsl_version, maybe we should just do
that for now. Old extensions like these are going to haunt us for a
while I think. I was trying to get Doom (2016) running yesterday and it
seems it uses bits from EXT_direct_state_access.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
