Keith Whitwell wrote:
- Application calls glTexImage - Mesa allocates AGP/card memory and copies texture directly to final destination (using memcpy().)
I have a couple questions about this. How does this handle things like glGetTexImage? What happens when there is memory pressure and a texture has to be kicked out?
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...
You'd be surprised. Another advantage of this strategy is that you can accelerate things like automatic mipmap generation and glCopyTexImage / glCopyTexSubImage.
------------------------------------------------------- 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
