From: Keith W. <ke...@tu...> - 2005-02-07 23:17:48
|
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 |