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

[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.

Jose