Currently Mesa needs to keep the system memory copy because texture images in card or agp memory can be clobbered by other apps at any
time - Ian's texture manager will address this.
In the via and sis drivers, texture allocations are permanent, so I've been able to try a different strategy:
- Application calls glTexImage - Mesa allocates AGP/card memory and copies texture directly to final destination (using memcpy().)
This resulted in an approximate 2x speedup in texture downloads against a strategy similar to the first one outlined (but implemented with cpu copies, not a hostdata blit).
That would be a good strategy. I'm not sure though you really get much of a speed improvement, I believe hostdata blits should be more efficient than cpu copies, at least for local memory. And in practice, I don't think texture upload speed is really that critical usually. Though it would be nice just to save some memory. I'm not sure how these drivers handle it when Mesa needs to access the texture again, but I guess since that's a slow path anyway it doesn't really matter if it's going to be a lot slower...
Ideally you'd have the driver mlock() the user data and have the GPU blit it right out of that space.
You need to be able to copy the data back in low-texture-memory situations, so you could use the same mechanism for fallbacks. At the moment I just leave it where it is in the via driver.
Keith
------------------------------------------------------- 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 Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
