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

[Marek Olšák]

On Mon, Nov 28, 2011 at 12:08 AM, Ian Romanick <idr at freedesktop.org> wrote:
> In Mesa, we have four drivers that advertise 4096 uniform components on some
> combinations of hardware: i915, i915g, nouveau, and r300g.  By putting
> resource counting in the driver we have the potential for shaders to compile
> and link on exactly one driver but fail on the other three.

r300g does not advertise 4096 uniform components. The limits are:

1024 uniform components on r300 vertex shaders.
128 uniform components on r300 fragment shaders.
1024 uniform components on r500 fragment shaders.

I was investigating how the Intel driver sets the maximum and I didn't
find it. Maybe the Intel driver is reporting Mesa defaults (most
probably incorrect). Maybe I didn't look hard enough.

I have not faked any limits so far. But now I will probably have to
raise them a bit in order to comply with the strict rules of the GLSL
linker, to close bugs in some other way than WONTFIX of course, and
just making work what used to work. Yes, it's lying, but it would make
things better at the same time, what other option do I have? (with the
least amount of work, of course, I have better things to do)


> Which is it?  Is a consistent ecosystem on which developers can depend a
> virtue, or is it me trying to ruin someone's driver?  You can't argue that
> it's both.
>
> If someone thinks that compacting uniform arrays or varying arrays is an
> important optimization that our OpenGL ecosystem needs to make applications
> run, that's great.  Patches are welcome.

Great. I just committed this last year, is it welcome too?
http://cgit.freedesktop.org/mesa/mesa/commit/?id=574ba4b5f50bfe661427327cd792a8a200559376

Though it seems to me that what you're telling me is "give me a patch
for the GLSL IR or **** off".

In theory, the GLSL compiler is not the only client in Gallium, so I
guess none of the Gallium folks are gonna be eager to move things into
it. If I move some optimization into the GLSL compiler, it doesn't
mean I can remove it from a Gallium driver. I have to keep in mind
there's video acceleration and maybe even X acceleration coming for
Gallium.

As far as varyings are concerned, no driver can do compaction to my
knowledge yet. The problem with the GLSL compiler is that it can't
even do a _simple_ dead-code elimination on unused varyings like
gl_TexCoord[insert_literal_here], i.e. something the years-old ARB
program implementation can do (and set the OutputsWritten flag
accordingly). For example, if gl_TexCoord[1] is unused, what's
stopping you from assigning some user-defined varying to the same
location? I am not expecting an answer, I know this issue will be
fixed by somebody sooner or later. I am just showing the problem.


> This is an ecosystem.  We will all either fail or succeed together.  Why do
> you think so much of the work that I and my team does lives in the shared
> components?  Huge amounts of the code that we've written, especially the
> GLSL optimizations, could live in our drivers.  Doing so would have let us
> accomplish our goals much, much faster, but we didn't do that because it
> hurts the ecosystem as a whole.

I agree, but forcing the rules of your driver onto somebody else's
driver may be met with disagreement, especially if your shader backend
is mediocre to others (because it heavily relies on shared components,
unlike other backends, especially Gallium drivers cannot solely rely
just on the GLSL compiler).

I don't think Mesa is an ecosystem to users such that it has to behave
the same no matter what driver is used. Mesa competes with two
proprietary drivers, which own quite a large market share, and both
are by several orders of magnitude better. They are so much better and
popular among professionals that they basically set the standard,
because most apps are tested on them and made work on them. Who really
cares about Mesa besides regular users who don't/can't replace the
graphics driver (including distribution vendors) and open source
enthusiasts? We can only shut up and do what the other driver
providers do.* Now that I live in a world where some apps are tested
only on R600-class hardware (at least) and proprietary drivers, I have
to make compromises and hard decisions to keep them working on the old
hardware. I tried hard to avoid reporting false limits, but I seem to
have been given no other choice.

* For example, I cannot advertise ARB_draw_instanced in r600g, because
it would break Unigine Heaven and pretty much anything else which uses
the extension. Mesa's implementation of ARB_draw_instanced is broken
for me. Whether it's broken in the name of religion or compliance with
the specification, I don't really give a damn. What I truly give a
damn about is whether the Unigine engine works. And last time I tried,
it worked without any graphical glitches on all Radeon Gallium drivers
as long as I don't enable that extension.

Marek