[Mesa-dev] [PATCH 3/3] mesa: glsl: force version too when force_glsl_extensions_warn is used

[Ian Romanick]

On 08/22/2012 08:54 AM, Maxim Levitsky wrote:
> On Wed, 2012-08-22 at 18:53 +0300, Maxim Levitsky wrote:
>> On Wed, 2012-08-22 at 08:48 -0600, Brian Paul wrote:
>>> On 08/22/2012 02:23 AM, Maxim Levitsky wrote:
>>>> Unfortunelly some buggy programs use extensions without asking ether for
>>>> proper GLSL version nor ask for particular extension.
>>>>
>>>> Moreover the force_glsl_extensions_warn hack is only effective for some
>>>> extensions (GL_EXT_texture_array) but unfortunelly isnt effective for other
>>>> extensions (I suspect these that declare new built in functions)
>>>> Example of this is recently added ARB_shader_bit_encoding extension.
>>>> Forcing GLSL version to high value seems to fix this, not sure if this
>>>> is acceptable hack though.
>>>>
>>>> This can be reproducted in Unigine Heaven with "ambient occlusion" on.
>>>> Note that even with this path shader compilatin fails, because code in Unigine
>>>> that gets activated when this extension gets enabled expects implicit conversions
>>>> between signed and unsigned immidiate constants.
>>>
>>> Can you give a short example of the GLSL code that's causing the problem?
>>>
>>>
>>>> Whether GLSL shold allow this is open
>>>> for debate.
>>>
>>>
>>> In my opinion, it's better to bend the rules a bit to allow broken
>>> apps to run than to just give up so I'm OK with this patch.  But let's
>>> hear what Ian thinks.
>>>
>>> -Brian
>> Sure!
>>
>> uniform uint foo;
>> void main() {
>> float x = float(foo & 0xffu);
>> }
>>
>> Best regards,
>> Maxim Levitsky
>>
> Oops, that is the "fixed" code.....
>
> This doesn't compile.
>
> uniform uint normal;
> void main() {
> float x = float(normal & 0xff);
> }

If they really only need to add one character to their shader, I'm not 
excited about hacking around in our type checker.