<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW --- - Unigine Valley & Heaven "error: syntax error, unexpected EXTENSION, expecting $end" IVB HD4000" href="https://bugs.freedesktop.org/show_bug.cgi?id=75664#c7">Comment # 7</a> on <a class="bz_bug_link bz_status_NEW " title="NEW --- - Unigine Valley & Heaven "error: syntax error, unexpected EXTENSION, expecting $end" IVB HD4000" href="https://bugs.freedesktop.org/show_bug.cgi?id=75664">bug 75664</a> from <a class="email" href="mailto:idr@freedesktop.org" title="Ian Romanick <idr@freedesktop.org>"> Ian Romanick</a> <pre>(In reply to <a href="show_bug.cgi?id=75664#c6">comment #6</a>) > Yes, Gallium drivers have quite different shader compiler code from classic > Mesa side. The front end of the compiler (the only part that sees the GLSL code from the application) is the same for all Mesa drivers. The difference is the Gallium drivers that are not affected by this issue do not expose GL_ARB_sample_shading... so the Unigine demos don't try to enable it in the middle of the shader. > Blend function issue will be fixed in next version of Valley, it's a bug in > the demo. If you don't want to work around the demo bugs with environment > variables, you have also an option to patch Mesa: > <a href="http://cgit.freedesktop.org/~kwg/mesa/log/?h=unigine">http://cgit.freedesktop.org/~kwg/mesa/log/?h=unigine</a> > > (There are also patches floating around for allowing extension declarations > elsewhere in shader source, but they seem to get fairly quickly out of date, > and AFAIK they won't get merged into Mesa until Khronos GL specs have been > changed accordingly. See e.g. patch mentioned in <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED NOTOURBUG - Second Life shaders fail to compile (extension declared in middle of shader)" href="show_bug.cgi?id=71591">bug 71591</a>.) Allowing extensions in the middle of the shader will NOT be made the default in Mesa. Khronos decided (wisely, IMO) that the spec is correct as-is. At least one vendor vowed to fix his implementation. I posted a bit more explanation in another bug related to this issue... or perhaps it was on the mesa-dev mailing list. Code has landed in Mesa to enable a driconf option for this, and Ken has a patch on the mesa-dev list to enable this driconf option in the i965 driver: <a href="http://lists.freedesktop.org/archives/mesa-dev/2014-August/065134.html">http://lists.freedesktop.org/archives/mesa-dev/2014-August/065134.html</a> This patch should land any time now.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>