[Mesa-dev] [PATCH] ir_to_mesa: do not check the number of uniforms against hw limits

[Brian Paul]

On Mon, Mar 14, 2011 at 1:07 PM, José Fonseca <jfonseca at vmware.com> wrote:
> On Mon, 2011-03-14 at 11:23 -0700, Brian Paul wrote:
>> On 03/12/2011 07:44 PM, Marek Olšák wrote:
>> > The r300 compiler can eliminate unused uniforms and remap uniform locations
>> > if their number surpasses hardware limits, so the limit is actually
>> > NumParameters + NumUnusedParameters. This is important for some apps
>> > under Wine to run.
>> >
>> > Wine sometimes declares a uniform array of 256 vec4's and some Wine-specific
>> > constants on top of that, so in total there is more uniforms than r300 can
>> > handle. This was the main motivation for implementing the elimination
>> > of unused constants.
>> >
>> > We should allow drivers to implement fail&  recovery paths where it makes
>> > sense, so giving up too early especially when comes to uniforms is not
>> > so good idea, though I agree there should be some hard limit for all drivers.
>>
>> I added the check_resources() code to fix an issue with the SVGA
>> driver.  If we can't do resource checking against the
>> ctx->Const.Vertex/FragmentProgram limits we need something else.
>>
>> In Gallium we have the PIPE_SHADER_CAP_MAX_x queries.  Are you saying
>> we shouldn't check shaders against those limits either?
>>
>> If we were to push all the shader resource checking down into the
>> Gallium drivers we'll need a new way to propagate error messages back
>> to the user (we can only return NULL from create_X_state() now).
>> Another other problem would be instituting consistant error reporting
>> across all the drivers.
>>
>> We've kind of tiptoed around this issue in the past.  It's probably
>> time to come up with some real solutions.
>
> Not only some drivers are able to optimize away declared-yet-unused
> registers; but other drivers drivers may actually need to add extra
> temps/const regs to implement certain opcodes/state. Both issues make it
> difficult to make guarantees around PIPE_SHADER_CAP_MAX_x, as we can
> easily end up advertising too little or too much.
>
> It looks there's not much alternative to mimicking GLSL here, i.e.,
> advertise these as limits but allow concrete shaders to pass/fail to
> compile on a case-by-case basis.
>
> I'm not sure what's the best what to convey errors from the drivers: to
> return pipe_error and extend it to include things like
>    PIPE_ERROR_TOO_MANY_CONSTS
>    PIPE_ERROR_TOO_MANY_TEMPS
>    PIPE_ERROR_TOO_MANY_INSTRUCTIONS
>    etc.
> and translate them in the state tracker; or use message strings. At a
> glance, it looks like an error enum would be expressive enough for most
> stuff.

That would probably be a good first step.  We should probably think a
bit more to see if we could get by with a simple set of enumerated
error codes or if we need a way to convey details.

Probably the least Gallium interface change would be to add a simple
pipe->get_shader_error() that would return PIPE_ERROR_x if the
previous create_fs/vs/gs_state() call returned NULL.

I think we can still do some resource checking at a high level in Mesa
and the state tracker.  For example, the number of texture units and
the number of constant buffers seem to be pretty solid limits.

-Brian