On Mon, Mar 14, 2011 at 1:07 PM, José Fonseca <[email protected]> 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 [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
