Ian Romanick wrote:
Roland Scheidegger wrote:

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?

Well I've got some code there for the memory pressure situation, but it's really a placeholder for what I hope your kernel memory manager might do (hint hint...)...


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.

Indeed - though as yet I haven't taken advantage of that.

I'm trying to work this as a development of what the userspace should look like in the situation where there is a reliable kernel memory manager, so I should probably get onto this.

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

Reply via email to