[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 6:04 PM, Jose Fonseca <jfonseca at vmware.com> wrote:
> ----- Original Message -----
>> On Tue, Nov 22, 2011 at 4:05 PM, Jose Fonseca <jfonseca at vmware.com>
>> wrote:
>> > Marek,
>> >
>> > I think we should take one of two approaches here:
>> > - aim for a short-term workaround, without gallium interface
>> > changes:
>> >  - e.g., provide to GLSL compiler infinite/huge limits, while
>> >  advertising to the app the pipe driver ones
>> >  - or detect the wine process and advertise bigger limits in the
>> >  r300 driver
>> > - aim for accurately describing the pipe driver compiling abilities
>> >  - e.g., allow the state tracker to create shaders that exceed
>> >  abilities, and force a trial generation and compilation of the
>> >  TGSI shaders when the GLSL shader is first linked
>> >
>> > But the hard limit caps interface change you propose below doesn't
>> > quite align to neither approach: it is an interface change which
>> > doesn't truly help describing the pipe driver compiler abilities
>> > any better (the actual maximum constants/inputs depends on the
>> > shader and is not a global constant), so it merely provides a
>> > short term relief.
>>
>> I would gladly commit this patch:
>>
> [...]
>
> Isn't there anything equally easy that can be done without touching src/glsl/*?

I don't think so. From the looks of it, drivers don't even get to see
any shader the linker rejects.

I guess it would be cleaner to have boolean flags
SkipVaryingLimitChecking and SkipUniformLimitChecking in gl_constants
and changing the linker to read those flags. Does that sound like a
good idea?

>
>> Now seriously. I do really care about users. And I'd like to release
>> a
>> product which works best for them.
>
> I understand. And I agree that on this particular case this is an intolerable regression for the users concerned.
>
> However, I don't think that Ian doesn't care about users, but rather that not following the spec is more harmful to the users on the long term. And, given he's one of the main GLSL author/maintainer that carries weight on my book, as far as that sub-component is concerned.
>
> Anyway, I don't see any need for us to clash against each others: all Mesa developers have and will always have different goals, schedules, and external pressures; but it should be possible to share the same code between all drivers without having to share the same policy.
>
> GLSL is a sub-component among others. Surely it must be possible to accommodate both a strict enforcement of max uniforms on Intel drivers, and a more lenient enforcement on another drivers. So instead of trying to decide who's right, let's just focus our energy into finding that flexible solution.

Sorry, I didn't mean to offend anybody.

Marek