[Mesa-dev] Mesa (master): nv30: report 8 maximum inputs

[Ilia Mirkin]

On Mon, Feb 10, 2014 at 4:43 PM, Ian Romanick <idr at freedesktop.org> wrote:
> On 02/08/2014 04:18 PM, Ilia Mirkin wrote:
>> Module: Mesa
>> Branch: master
>> Commit: 356aff3a5c08be055d6befff99a72f5551b3ac2d
>> URL:    http://cgit.freedesktop.org/mesa/mesa/commit/?id=356aff3a5c08be055d6befff99a72f5551b3ac2d
>>
>> Author: Ilia Mirkin <imirkin at alum.mit.edu>
>> Date:   Wed Jan 29 12:36:13 2014 -0500
>>
>> nv30: report 8 maximum inputs
>>
>> nvfx_fragprog_assign_generic only allows for up to 10/8 texcoords for
>> nv40/nv30. This fixes compilation of the varying-packing tests.
>> Furthermore it appears that the last 2 inputs on nv4x don't seem to
>> work in those tests, so just report 8 everywhere for now.
>
> Is it possible that the last two inputs are supposed to be used for
> gl_Color and gl_SecondaryColor?  In that case, they may have clamping
> enabled by default (or always enabled, if the hardware cannot disable
> GL_CLAMP_VERTEX_COLOR).  Does that match the behavior that you saw?

I'm definitely out of my depth here. What I saw were piglit tests
failing and hard-to-understand code with little additional
documentation.

There's a mask that enables passing of outputs from VP -> FP. This
mask has separate entries for colors, fog, psize, and clipping. The
texcoord's, as they are called, are in a different part of the mask.
The last 2 are in a different-yet part of the mask from the first 8.
This of course does not preclude them getting clamped/modified in some
way. Ideally those varying-packing tests would be rewritten in a way
that better exposes what actually went wrong, but I realize it's not
easy to add printf("interesting values: %f %f") into a shader.

It's also entirely possible that the issue is that the way you address
those last 2 texcoord's in the FP has to be done in some different way
than the first 8. Ideally I (or someone) would trace the blob and
analyze the bytecode/engine setup to see what the difference is. I
haven't gotten around to that (and unfortunately envydis doesn't
support the nv30/nv40 shader ISA).

However I was trying to make a dent in the nv4x failures and crashes.
This is the latest state, btw:
http://people.freedesktop.org/~imirkin/nv40-comparison/problems.html
-- I think actually a bunch of the test failures are due to incorrect
piglit tests (e.g. "shader uses too many input components (48 > 32)"),
so it's not _quite_ as bad as it looks. But before all of those were
"assertion failure trying to parse the TGSI because it had too many
inputs".

>
>> Tested on NV42, NV44. NV4B appears to have additional problems.
>>
>> Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu>
>> Cc: 9.1 9.2 10.0 10.1 <mesa-stable at lists.freedesktop.org>
>>
>> ---
>>
>>  src/gallium/drivers/nouveau/nv30/nv30_screen.c |    2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/src/gallium/drivers/nouveau/nv30/nv30_screen.c b/src/gallium/drivers/nouveau/nv30/nv30_screen.c
>> index 787802d..4045fdc 100644
>> --- a/src/gallium/drivers/nouveau/nv30/nv30_screen.c
>> +++ b/src/gallium/drivers/nouveau/nv30/nv30_screen.c
>> @@ -217,7 +217,7 @@ nv30_screen_get_shader_param(struct pipe_screen *pscreen, unsigned shader,
>>        case PIPE_SHADER_CAP_MAX_CONTROL_FLOW_DEPTH:
>>           return 0;
>>        case PIPE_SHADER_CAP_MAX_INPUTS:
>> -         return (eng3d->oclass >= NV40_3D_CLASS) ? 12 : 10;
>> +         return 8; /* should be possible to do 10 with nv4x */
>>        case PIPE_SHADER_CAP_MAX_CONSTS:
>>           return (eng3d->oclass >= NV40_3D_CLASS) ? 224 : 32;
>>        case PIPE_SHADER_CAP_MAX_CONST_BUFFERS:
>>
>> _______________________________________________
>> mesa-commit mailing list
>> mesa-commit at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-commit
>>
>