On 09/24/2012 01:04 PM, Roland Scheidegger wrote: > Am 24.09.2012 21:06, schrieb Kenneth Graunke: >> On 09/22/2012 02:04 PM, Eric Anholt wrote: >>> I don't know of any programs that would need more than this. The larger >>> programs I've seen have neared 100 instructions. This prevent excessive >>> runtimes of automatic tests that attempt to test up to the exposed maximums >>> (like fp-long-alu). >>> --- >>> src/mesa/drivers/dri/i965/brw_context.c | 8 ++++---- >>> 1 file changed, 4 insertions(+), 4 deletions(-) >>> >>> diff --git a/src/mesa/drivers/dri/i965/brw_context.c >>> b/src/mesa/drivers/dri/i965/brw_context.c >>> index 1083e28..a7d61bd 100644 >>> --- a/src/mesa/drivers/dri/i965/brw_context.c >>> +++ b/src/mesa/drivers/dri/i965/brw_context.c >>> @@ -250,10 +250,10 @@ brwCreateContext(int api, >>> MIN2(ctx->Const.VertexProgram.MaxNativeParameters, >>> ctx->Const.VertexProgram.MaxEnvParams); >>> >>> - ctx->Const.FragmentProgram.MaxNativeInstructions = (16 * 1024); >>> - ctx->Const.FragmentProgram.MaxNativeAluInstructions = (16 * 1024); >>> - ctx->Const.FragmentProgram.MaxNativeTexInstructions = (16 * 1024); >>> - ctx->Const.FragmentProgram.MaxNativeTexIndirections = (16 * 1024); >>> + ctx->Const.FragmentProgram.MaxNativeInstructions = (1 * 1024); >>> + ctx->Const.FragmentProgram.MaxNativeAluInstructions = (1 * 1024); >>> + ctx->Const.FragmentProgram.MaxNativeTexInstructions = (1 * 1024); >>> + ctx->Const.FragmentProgram.MaxNativeTexIndirections = (1 * 1024); >>> ctx->Const.FragmentProgram.MaxNativeAttribs = 12; >>> ctx->Const.FragmentProgram.MaxNativeTemps = 256; >>> ctx->Const.FragmentProgram.MaxNativeAddressRegs = 0; >> >> I've definitely seen 600 instruction shaders generated by Cg. (Some >> Crystal Space based games use shaders written in Cg, which translates to >> stellar ARBfp code...) I'm afraid there may be even bigger ones. > > I'm not sure there are really larger ones out in the wild. > I would guess that the arbfp1 target was mostly used for targetting > ati cards (since geforce cards had their own target profile), and these were > limited to 512 (hw) instructions (for r4xx, much less for r3xx). > I guess the stellar arbfp code is mostly due to the necessary loop unrolling, > and if you were targetting cards which actually could do loops you'd be > using the glsl target of cg (of course you could use glsl target for those > older cards too but arbfp1 target is probably older?). > And I bet you could cut down the MaxNativeTexInstructions and especially > the number of MaxNativeTexIndirections a lot more without hurting any > real apps. > But of course I don't actually know for sure if there isn't some stupid > app out there trying to compile some nice small simple cg shader but with > loops > into some arb_fp mess even if it should really use glsl target. > > Roland
For some reason using Cg's glsl target always crashed and burned for me. But it's been a while since I tried and I never did figure out whose bug it was. The game I tested also recently switched to using GLSL directly, so it may be a moot point. I suppose we could always lower it and then re-raise it if something broke. It is really hard to imagine >= 1024 instruction ARB fp programs. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
