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

[Marek Olšák]

On Tue, Nov 22, 2011 at 11:11 PM, Ian Romanick <idr at freedesktop.org> wrote:
> All of this discussion is largely moot.  The failure that you're so angry
> about was caused by a bug in the check, not by the check itself. That bug
> has already been fixed (commit 151867b).
>
> The exact same check was previously performed in st_glsl_to_tgsi (or
> ir_to_mesa), and the exact same set of shaders would have been rejected.
>  The check is now done in the linker instead.

Actually, the bug only got my attention and then I realized what is
actually happening in the linker. I probably wouldn't even notice
because I no longer do any 3D on my laptop with r500. I gotta admit, I
didn't know the checks were so... well, "not ready for a release" to
say the least and that's meant regardless of the bug.

Let's analyze the situation a bit, open-minded.

The checks can be enabled for OpenGL ES 2.0 with no problem, we won't
likely get a failure there.

They can also be enabled for D3D10-level and later hardware, because
its limits are pretty high and therefore are unlikely to fail. The
problem is with the D3D9-level hardware (probably related to the
vmware driver too).

We also have to consider that a lot of applications are now developed
with D3D10-level or later hardware and even though the expected
hardware requirements for such an app are meant to be low, there can
be, say, programming mistakes, which raise hardware requirements quite
a lot. The app developer has no way to know about it, because it just
works on his machine. For example, some compositing managers had such
mistakes and there's been a lot of whining about that on Phoronix.

We also should take into account that hardly any app has a fallback if
a shader program fails to link. VDrift has one, but that's rather an
exception to the rule (VDrift is an interesting example though; it
falls back to fixed-function because Mesa is too strict about obeying
specs, just that really). Most apps usually just abort, crash, or
completely ignore that linking failed and render garbage or nothing.
Wine, our biggest user of Mesa, can't fail. D3D shaders must compile
successfully or it's game over.

Although the possibility of a linker failure is a nice feature in
theory, the reality is nobody wants it, because it's the primary cause
of apps aborting themselves or just rendering nothing (and, of course,
everybody blames Mesa, or worse: Linux).

There is a quite a large possibility that if those linker checks were
disabled, more apps would work, especially those were the limits are
exceeded by a little bit, but the difference is eliminated by the
driver. Sure, some apps would still be broken or render garbage, but
it's either this or nothing, don't you think?

Marek