Michel Dänzer writes: > Yeah, the real question is whether it breaks pre-R300 chips on big > endian machines, but it looks fine to me.
Yes, we previously had two byte-swaps on those machines, and now we have no byte-swap, so the outcome should be identical. > Nice. It might also be interesting to experiment with copying the > texture data into the ring itself instead of into indirect buffers (and > use type 3 NOP packets to have the CP skip it), if someone feels so > inclined. Just to avoid the overhead of allocating an indirect buffer? I think that could be worthwhile for smaller textures, although for smaller textures it would probably be just as fast, and a lot simpler, to write the texture directly to the framebuffer. I assumed that the indirect buffer would be at least 1kB-aligned (indirect buffers seem to be page-aligned, from what I could see in the code that creates them). This means that I didn't have to worry about losing bits when shifting buf->offset right 10 bits. We wouldn't have that guarantee if we were putting the texture in the ring buffer, which might make calculation of suitable x and y values interesting. :) > > > + 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? > > > + OUT_RING(0); > > > + OUT_RING((image->x << 16) | image->y); > > > + OUT_RING((image->width << 16) | height); > > > + ADVANCE_RING(); > > > + > > > radeon_cp_discard_buffer(dev, buf); > > I think this needs a RADEON_WAIT_UNTIL_2D_IDLE(), or the indirect buffer > might get reused before the blit is complete. Well, radeon_cp_dispatch_indirect doesn't seem to wait for the blit to complete either, so I was just following what the old code did. I must admit I don't yet understand how indirect buffers get recycled. Regards, Paul. ------------------------------------------------------- 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_ide95&alloc_id396&op=click -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
