Bug 16452

Created attachment 17280 [details]
screenshot2

The screenshot is from anisotropictest, http://steinsoft.net/index.php?site=Programming/Projects/OpenGL/anisotropictest

I cannot reproduce this with current Git and my R420 (X800 Pro), but obviously there's a problem here.

Uploading small textures seems like a good initial guess. Does anybody know of differences in the texture filtering on that hardware? Also, could you test programs that use small textures to begin with, without mipmapping? For example, start with Mesa's crossbar test and change the texture sizes by editing the code starting at line 246. There are four calls

   glTexImage2D( GL_TEXTURE_2D, 0, GL_RGBA, 8, 8, 0,
                 GL_RGBA, GL_UNSIGNED_BYTE, temp );

The first 8 is the texture width, the second 8 is the texture height. Try with the original size first, and if this works, try with successively smaller sizes and see if it fails. This would point towards small texture memory layout as the culprit. I'd be kind of surprised by that, but then we all know the RS690 is a bit weird ;)

If this does not fail, then who knows... I can't think of anything right now.

I checked mesa crossbar tests, and 8x8 textures are broken. Bigger textures are good

IIRC, RS4xx/RS6xx IGP chips require tiling for small textures.  The patch in bug 8056 fixes the issue I think.

(In reply to comment #4)
> IIRC, RS4xx/RS6xx IGP chips require tiling for small textures.  The patch in
> bug 8056 fixes the issue I think.
> 

Probably, but it doesn't apply anymore.

I checked before only square textures. If it's any help here are results for all POT textures from 1x1 up to 64x64 (all RGBA)

Textures that are broken:
1x2, 1x4, 1x8, 1x16, 1x32, 1x64
2x2, 2x4, 2x8, 2x16, 2x32, 2x64
4x2, 4x4, 4x8, 4x16, 4x32, 4x64
8x8, 8x16, 8x32, 8x64

Created attachment 17311 [details] [review]
updated drm texture tiling patch

Updated texture tiling patch for the drm from bug 8056 (untested).

Created attachment 17312 [details] [review]
updated texture tiling patch for mesa

Updated mesa texture tiling patch from bug 8056 (untested).

Created attachment 17320 [details] [review]
Override pitch alignment in textures to 64 bytes

Except for the fact that you're saying 8x2 and 8x4 is okay, this also looks like the required alignment for textures is different on RS690.

It would be interesting if you could try the attached patch, independently from the texture tiling patches. The attached patch makes the alignment *larger* (to 64 bytes), but you might also want to try making the alignment *smaller* (to 16 bytes) by changing the 63 to a 15 and the 0x3f to 0x0f.

[Of course, the attached patch is incorrect for normal R300/R500 texture engines, but if it works we've learnt something and we can then add an appropriate case switch to the driver; yes, in the long run, enabling texture tiling is better, but it's always nice to have the simpler fallback working as well.]

Alex: those tiling patches helps a LOT, but don't fix the problem completely. Small textures are still broken.

Nicolai: your patch doesn't help at all.

So we'll definitely have to work on texture tiling. It's quite possible that those patches aren't 100% correct or, if we're particularly unlucky, that there is a subtle difference in how tiling works.

One final thing that I'd be curious about is (only if you have the time) a summary of a piglit run (./piglit-run.py tests/r300.tests results-dir) on RS690. I expect that many tests should fail because of the small-texture problem, but I don't think there's an explicit small-texture test. Perhaps I should write one....

I'll see if I can find anything special for IGP chips.  Tiling should be pretty straight forward, see chapter 2 of the r5xx acceleration guide.  The tiling info there is relevant to previous chips as well.

Created attachment 17375 [details]
piglit results

Nicolai: unfortunately my machine soft locks during texcombine test. I uploaded partial results.

Fix commited to radeon-rewrite branch - 0b22615c2c860968a027c04519e25864ae69f6cd

Mass version move, cvs -> git