[Mesa-dev] The ARB_shader_subroutine extension

[Gustaw Smolarczyk]

Yeah, I understand this concern. But this could be said about any
uber-shader approach. For cases when one cannot afford to change
shader program in between draw calls (using features like multi draw
indirect), it should be better to use shader subroutine arrays instead
of a switch. If the difference in register pressure between the
simplest and the most complex subroutine is not that large, the
problem you described wouldn't exist. One can always batch draw calls
with very simple subroutines separately.

It would be great if there was a possibility to change *the whole*
program for a given draw, so that renderings with simple shaders
wouldn't be penalized by the artificial register pressure caused by
the dynamically unused paths. But I guess, the hardware is unable to
implement such a feature.

2014-11-18 19:51 GMT+01:00 Ian Romanick <idr at freedesktop.org>:
> On 11/16/2014 08:31 AM, Gustaw Smolarczyk wrote:
>> Hello once again,
>>
>> This time, I would like to ask about the shader subroutine extension.
>> I believe this extension is not very popular, but is still needed for
>> GL4 compliance.
>>
>> What is the reason for its unpopularity?
>> Is it because one needs to reset subroutine uniform values after any glUse*?
>> Or it just didn't provide enough value?
>> Wouldn't it be good to implement uber-shaders (especially using
>> subroutine uniform array)?
>
> It has a very strong negative affect on register allocation.  Basically,
> the compiler has to, at the very least, allocate registers for the
> "worst" subroutine.  This means that subroutines that use fewer
> registers will often perform worse (on some GPUs much, much worse) than
> they should.  On Intel GPUs this means that you might just get SIMD8 for
> a shader that could have had SIMD16.  I've been told that on AMD GPUs it
> means you have much fewer vertices or pixels executing in parallel
> leading to dramatic performance hits.
>
>> Is anybody actively working on it? I guess, there are changes needed
>> in the GLSL compiler. It could be easily lowered to a
>> switch-on-uniform-int thing, or something like that, if only
>> compliance to the GL4 matters and not the performance.
>>
>> Regards,
>> Gustaw
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>