On Tue, May 15, 2018 at 1:38 PM, Marek Olšák <mar...@gmail.com> wrote:
> On Tue, May 15, 2018 at 4:09 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote: > >> On Tue, May 15, 2018 at 3:54 PM, Marek Olšák <mar...@gmail.com> wrote: >> > On Tue, May 15, 2018 at 3:36 PM, Ilia Mirkin <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. Another option would be to allow drirc to force-enable GLSL extensions and shader versions and use that to make the one app work. --Jason
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
