[Nouveau] [MESA PATCH] Fix nv40_miptree_layout pitch

Younes Manton younes.m at gmail.com
Fri Dec 25 20:32:33 PST 2009


On Fri, Dec 25, 2009 at 10:37 PM, Luca Barbieri <luca at luca-barbieri.com> wrote:
> You are right. The patch is wrong. Both changes fix my program, but do
> break OpenGL (e.g. redbook/mipmap).
>
> I managed to reproduce the problem with perf/genmipmap.
>
> When run, it causes several instances of one of these 3 errors (using
> swizzled textures):
> [12949.125732] [drm] nouveau 0000:01:00.0: PGRAPH_ERROR - nSource:
> DATA_ERROR, nStatus: BAD_ARGUMENT
> [12949.125738] [drm] nouveau 0000:01:00.0: PGRAPH_ERROR - Ch 3/7 Class
> 0x4097 Mthd 0x020c Data 0x00000000:0x00000008
> [12949.214750] [drm] nouveau 0000:01:00.0: PGRAPH_ERROR - nSource:
> DATA_ERROR, nStatus: BAD_ARGUMENT
> [12949.214757] [drm] nouveau 0000:01:00.0: PGRAPH_ERROR - Ch 3/7 Class
> 0x4097 Mthd 0x020c Data 0x00000000:0x00000010
> [12951.752081] [drm] nouveau 0000:01:00.0: PGRAPH_ERROR - nSource:
> DATA_ERROR, nStatus: BAD_ARGUMENT
> [12951.752088] [drm] nouveau 0000:01:00.0: PGRAPH_ERROR - Ch 3/7 Class
> 0x4097 Mthd 0x020c Data 0x00000000:0x00000020
>
> It seems they are due to PGRAPH not liking an 8/16/32 pitch.
> In my program I got these as well and narrowed it down to doing mipmap
> generation on the small levels that have pitch set that way.
>
> This patch does make them go away but breaks progs/mipmap (both
> changes are wrong).
>
> Apparently the miptree layout is correct, but the lowest mipmap levels
> cannot be rendered to with the current code (that however tries to,
> resulting in the errors), possibly due to an hardware limitation.
>
> I guess a possible solution could be to modify
> nv40_miptree_surface_new to allocate temporary surfaces for pitch <64
> levels (i.e. 8x, 4x and 1x mipmap levels for RGBA) and then do a copy
> with the 2D engine in nv40_miptree_surface_del.
>
> Alternatively, for square Pot textures, it may be possible to map the
> 8x8, 4x4, 2x2 and 1x1 mipmaps as a single 16x16 pitch 64 swizzled
> texture in which they should appear as rectangles, and then restrict
> drawing to the rectangle by adjusting the viewport (and finding a way
> to make bypass work too). Not sure if this works and whether it can be
> generalized to non-square-pot textures.
>
> How does the nVidia driver implement glGenerateMipmap?
>

Hi,

Yes this is a known problem. The hardware has two incompatible
constraints; the layout of swizzled mipmaps makes rendering directly
to the last few levels impossible as you saw. Personally I think the
first approach is cleaner; in nv40_miptree_surface_new() if the
PIPE_BUFFER_USAGE_GPU_WRITE flag is set but the offset & pitch of the
surface doesn't allow it to be used as a render target create a temp.
I have an old patch that does this that I will try to dig up if you
have a program that suffers from this limitation.

The Nvidia driver uses the 2D engine to generate the mipmap chain
IIRC. For us this is handled by shared code in Mesa, which tries to
generate the mipmap chain by using the 3D engine to render each level.
This works fine for linear textures, not so well for swizzled, and
currently the driver framework does not let us generate the mipmap
chain using the 2D engine (at least without ugly hacks).


More information about the Nouveau mailing list