On Mon, Feb 10, 2014 at 4:43 PM, Ian Romanick <i...@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 <imir...@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 <imir...@alum.mit.edu>
>> Cc: 9.1 9.2 10.0 10.1 <mesa-sta...@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-com...@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-commit
>>
>
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
