I had trouble to understand that too, both when I added support for+ OUT_RING((texpitch << 22) | (offset >> 10)); + OUT_RING((texpitch << 22) | (tex->offset >> 10));
Are source and destination pitch always the same?
I found it quite hard to understand what was going on with tex->width, tex->height and tex->pitch vs. image->width and image->height, since they seem to be used inconsistently. It turns out that in fact tex->pitch isn't actually the pitch of the texture image - it can be a power of two multiple of the actual texture pitch. By the time the data gets to the indirect buffer it is laid out as we want it in the framebuffer, though, and what we want is just a 1-D block copy, and using the same pitch, with width equal to pitch / pixelsize, effectively gives us a 1-D block copy.
Do you have a better explanation of how tex->width/height/pitch relate to image->width/height?
compressed textures and then again for tiled textures. This IS confusing.
You might not need that for r300, however this will break texture tiling for older chips. texpitch includes the tile bits, so you need different pitches for source and destination (or you'd need to tile everything yourself). Also, be careful with that 1-D block copy assumption - you cannot tweak all parameters like you want, since all the pitch, width and height parameters need to be correct, otherwise the gpu will tile the textures incorrectly.
Roland
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- _______________________________________________ Dri-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
