[Mesa-dev] [PATCH 2/2] mesa: add hard limits for the number of varyings and uniforms for the linker

[Roland Scheidegger]

Am 25.11.2011 09:15, schrieb Jose Fonseca:
> ----- Original Message -----
>> While Ian and I may take a more idealist stance (favoring strict 
>> compliance), and you perhaps a more pragmatic view (get more apps 
>> running), we're all working toward the same goal: to build great 
>> OpenGL drivers and advance the state of the art for open source 3D
>> graphics.
>> 
>> Our community has been quite fractured for some time now, and I'd 
>> rather not see it devolve any worse that it has.  This argument
>> really isn't helping us solve anything.
>> 
>> I made two suggestions for how we could work around the issue.
>> The first was to move said optimizations into the common compiler,
>> where they could benefit Radeon, Nouveau, and Intel.  I believe the
>> gist is that, while this is a good idea long term, it's too much
>> work at the moment.
>> 
>> The second was to move the resource limit checks into the driver
>> so they would occur after any backend optimizations.  I haven't
>> heard from anyone whether they think this would solve the problem,
>> whether they think it's a good idea, or how we might best make it
>> happen.
>> 
>> Or, perhaps someone has a better idea still.
> 
> I think you've summarized very well my feelings and thoughts on this
> as well, Kenneth.
> 
> I think that moving resource limit checks into the driver has own
> merit, not only for this case where the driver can handle shaders
> that exceed limits by optimizing things away, but also the reverse
> case where the driver does not handle shaders which do not exceed the
> advertise limit due to workarounds -- many drivers need to emit
> additional temp registers, varyings, or uniforms when translating
> certain instructions/features.  And applications that do check errors
> would probably appreciate an error message when the driver can't
> handle the shader, rather than silent corruption.
> 
> Moving the resource limits into the driver shouldn't be hard. The
> only question is how to handle shader variants due to non orthogonal
> state -- probably the driver needs to do a trial compilation with a
> representative/worst-case variant when the shader is linked.
> 
> For gallium drivers there is also the issue that there is no way to
> express error conditions when the pipe driver compiles shaders
> (distinguish e.g. OOM or shader beyond limits) in the interface, but
> this is trivial to fix.
>

I think it would be nice (for interface reasons) if we could do the
resource checks in the glsl compiler, but as you said ultimately only
the backend really knows with certainty if a shader is going to work.
But due to possible non-orthogonal state the answer might not be correct
neither, so it won't really solve the problem 100%. So I don't know how
this should be solved, but in any case I'd vote for more optimizations
being done in common code in any case.

Roland