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

Kenneth Graunke kenneth at whitecape.org
Thu Nov 24 16:46:13 PST 2011


On 11/24/2011 04:47 AM, Marek Olšák wrote:
> On Wed, Nov 23, 2011 at 7:25 PM, Ian Romanick <idr at freedesktop.org> wrote:
>> Let me paraphrase this a little bit in a way that I think concisely captures
>> the intention:
>>
>>    "We need to work really hard to make things work on older hardware."
>>
>> I don't think anyone disagrees with that.  However, the solutions you have
>> so far proposed to this problem have said:
>>
>>    "We need to let anything through whether it will work or not."
>>
>> Those are very different things.  We can have the first without the second.
>>  I will fight very, very hard to not allow the second in any project with
>> which I'm associated.
> 
> In this specific case, as I understand it, you deliberately want my
> driver to be less capable for the next release (and you probably
> already managed to do that for 7.11, though I think 7.10 was okay).
> What I have so far proposed is:
> 
> We need to let *some* shaders through whether they will work or not,
> because the current code is deliberately crippling at least one
> driver. In order to fix this, some checks should be removed
> *temporarily* and reestablished when they're more mature, or another
> workaround should be found before the next release is out. One way or
> another, no driver should be crippled ever. I know you couldn't care
> less about anything except your driver, but there are people who care.
> 
> Marek

I'm honestly shocked to read this, Marek.  We "deliberately want [your]
driver to be less capable" and "couldn't care about less about anything
except [our] driver"?  This is sounding remarkably like a conspiracy
theory, and I really didn't expect that from you.

Please take a step back and look at what you're saying.

I personally want to see open source 3D graphics flourish, regardless of
vendor.  I have the privilege of working on the Intel driver, and so I
will try to make it the best I possibly can.  But that doesn't mean I'm
not glad to see you and others making great improvements on the Radeon
and Nouveau drivers, too.  Yes, we "compete" to an extent---but we also
collaborate.  I don't think I would accuse anyone in the community of
intentionally sabotaging another person's work.

I think our track record speaks differently.  We've invested a lot into
core Mesa and improving common infrastructure over the years.  When we
work on the GLSL compiler, we try to design things in a way to be
helpful to driver developers across the full range of hardware, not just
ours.  We've also done a bunch of work on GLX, EGL, texturing, and more.

You've also done a great deal of solid work in your driver, in core
Mesa, and also in Piglit, and I respect that.  I feel confident in
saying that the whole community is grateful for your efforts.  People on
my team speak also very highly of you.

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.


More information about the mesa-dev mailing list