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

[Marek Olšák]

There is a fail path in r300g that has been working very well for us. If
shader compilation fails, a dummy shader emitting one instruction is used
(usually outputting (0,0,0,1) into the first output). This approach allows
the applications with failing shaders to run with misrendering on specific
objects (in case of a fragment shader failure) or with missing objects (in
case of a vertex shader failure). The fact there is no crash or abort or
anything preventing the apps from running makes some of them usable. It also
makes debugging easier, because all failing shaders must go through the r300
compiler and we can analyze whether the compiler is doing a good job in
reducing the number of instructions and temporaries, and whether we can do
something about it to make it better.

If we are about to introduce new shader error enums, I'd like to preserve
the current r300g behavior for OpenGL apps, because it appears to be a win
in most cases.

Marek

On Tue, Mar 15, 2011 at 1:31 AM, Brian Paul <brian.e.paul at gmail.com> wrote:

> 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
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20110315/62911da2/attachment-0001.htm>