Bug 57660

I think nouveau could probably easily get support for it, so I don't know if we should default to false, would be better to leave it open.

Working on it.

In nv50_ir_lowering_nv50.cpp in handleTEX, arguments to the texture instruction i are (x, y, z, face, something).
What do they need to be transformed to? Is it (x, y, 6*z+face, something)?

Created attachment 70799 [details]
Partial implementation

This is a partial implementation. It is probably slow and renders incorrectly for some reason.

I think it's only available on nva3...nva8 and nvaf (no idea about nvaa/ac, they've always been special..), not for all of nv50 :)

What's the problem with the older gpu's? Why can't it be implemented?

Looks like support for NVA3+ was added in f7599b2c3. However it's not actually turned on for pre-nvc0, the commit message says:

    NOTE: nv50 support not enabled, someone with nva3/8 please fix.

I have no idea what it is that's left to do/fix there, but I don't have a nva3/5/8/f (which is what I think the list of cards with the NVA3_3D class is).

Sounds like what's left to be done is to test it. Just need to apply the below patch and see if it works (looks like there are a couple of piglit tests... ls bin/*cube_map_array* -- they ought to pass on the nva3+ hardware).

--- a/src/gallium/drivers/nv50/nv50_screen.c
+++ b/src/gallium/drivers/nv50/nv50_screen.c
@@ -114,10 +114,7 @@ nv50_screen_get_param(struct pipe_screen *pscreen, enum pipe_cap param)
    case PIPE_CAP_SEAMLESS_CUBE_MAP_PER_TEXTURE:
       return 0;
    case PIPE_CAP_CUBE_MAP_ARRAY:
-      return 0;
-      /*
       return nv50_screen(pscreen)->tesla->oclass >= NVA3_3D_CLASS;
-      */
    case PIPE_CAP_TWO_SIDED_STENCIL:
    case PIPE_CAP_DEPTH_CLIP_DISABLE:
    case PIPE_CAP_POINT_SPRITE:

(In reply to comment #8)
> Sounds like what's left to be done is to test it. Just need to apply the
> below patch and see if it works (looks like there are a couple of piglit
> tests... ls bin/*cube_map_array* -- they ought to pass on the nva3+
> hardware).
> 
> --- a/src/gallium/drivers/nv50/nv50_screen.c
> +++ b/src/gallium/drivers/nv50/nv50_screen.c
> @@ -114,10 +114,7 @@ nv50_screen_get_param(struct pipe_screen *pscreen, enum
> pipe_cap param)
>     case PIPE_CAP_SEAMLESS_CUBE_MAP_PER_TEXTURE:
>        return 0;
>     case PIPE_CAP_CUBE_MAP_ARRAY:
> -      return 0;
> -      /*
>        return nv50_screen(pscreen)->tesla->oclass >= NVA3_3D_CLASS;
> -      */
>     case PIPE_CAP_TWO_SIDED_STENCIL:
>     case PIPE_CAP_DEPTH_CLIP_DISABLE:
>     case PIPE_CAP_POINT_SPRITE:

I tested this patch with piglit, it doesn't look good :D

* arb_texture_cube_map_array-get: PASS
* arb_texture_cube_map_array-teximage3d-invalid-values: PASS
* arb_texture_cube_map_array-cubemap: FAIL (http://codepad.org/sZpx3ajS)
* arb_texture_cube_map_array-cubemap-lod: FAIL (http://codepad.org/5E8EPmpx)
* arb_texture_cube_map_array-fbo-cubemap-array: FAIL (http://codepad.org/0QqPUEAE)
* arb_texture_cube_map_array-sampler-cube-array-shadow: FAIL (http://codepad.org/orzd5RoU)

I think there are a bunch of places in the nv50 driver where things check for PIPE_TEXTURE_{1D,2D}_ARRAY but also need to check for PIPE_TEXTURE_CUBE_ARRAY. One such place is nv50_create_texture_view but there are probably a bunch of others.

Created attachment 93636 [details] [review]
cubemap array patch

Well, this fixes the one place I found by copying what nvc0 did. But from Martin's test it seems like this probably won't be sufficient, since this just takes layer offsets into account.

(In reply to comment #11)
> Created attachment 93636 [details] [review] [review]
> cubemap array patch
> 
> Well, this fixes the one place I found by copying what nvc0 did. But from
> Martin's test it seems like this probably won't be sufficient, since this
> just takes layer offsets into account.

In case there was any suspense about it, this doesn't work either. It seems like the texprep instruction doesn't actually adjust for the layer (or we're passing the layer in wrong) -- cubemap works for layer 0 but not layer 1. Will need some traces to figure out what's up.

A working impl is in mesa-git now. http://cgit.freedesktop.org/mesa/mesa/commit/?id=0e71c65db0df86401f2caf26209ff73e3715443a

The sampler-cube-array-shadow test fails, but so does sampler-cube-shadow (on nva0+), so I'm guessing those two failures are highly related.