https://bugs.freedesktop.org/show_bug.cgi?id=71591
Eero Tamminen <eero.t.tammi...@intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |eero.t.tammi...@intel.com
--- Comment #4 from Eero Tamminen <eero.t.tammi...@intel.com> ---
E.g. Unigine's Heaven benchmark (v4.0) does this also.
It's a shame as that would be a nice test case for recently added geometry
shader and GL_ARB_sample_shading support in Mesa. 93 of the shaders in Heaven
benchmark (= nearly half of them) have:
#extension GL_ARB_sample_shading : enable
And in none of them it's at the start. There are no other extension
declarations.
(In reply to comment #3)
> This seems a common mistake. I think we should consider applying it in
> upstream mesa too, for sake of compatability.
All the Heaven shaders have main(). I think they're concatenated together from
different parts and in that case it makes sense to declare extensions required
by given part of shader, in the beginning of that part.
Program needing to keep track of what extensions are require by different
shader parts is inconvenient, especially if those concatenated parts can be
edited separately from the program (they e.g. come from disk).
(In reply to comment #1)
> According to the GLSL specification (1.30, page 14), #extension directives
> must come before any non-preprocessor tokens.
The spec says:
"Each extension can define its allowed granularity of scope. If nothing is
said, the granularity is a shader (that is, a single compilation unit), and the
extension directives must occur before any non-preprocessor tokens."
What if extension defines its allowed scope?
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
