Yes, that's probably the reason. Actually, I was a bit surprised the
btw texdown showed that texture transfers to card memory are faster than to AGP memory, but not by very much (something like 100MB/s vs. 140MB/s in the best case, though the numbers I got fluctuated quite a bit).
How are AGP texture uploads being done?
The card memory uploads are actually done via agp buffers - ie the data is written by the driver to agp memory, the card then copies that to card memory. If the AGP case is the same, the data probably travels up to the card and then back down again to AGP memory, accounting for the relative slowdown.
difference isn't that big, with AGP "2.66x" and agp->vid mem transfers I
would have expected higher numbers, maybe something like half the
theoretical peak bandwidth, but I got only 1/4th. Though maybe the mesa overhead was just too big (some formats dropped to 22MB/s or so).
There are other benefits too, for instance if you use the gpu blitter itOne benefit of using the card to do the up/downloads is synchronization with the graphics engine - if you were to write the texture data directly you'd have to have some extra mechanisms to ensure that the memory wasn't being used by commands still unprocessed by the GPU. This actually wouldn't be that hard to organize.
can tile the textures itself (not that it would be a big deal to do that with the cpu) (with limits - it can't tile very small textures/mipmaps correctly for microtiling, or if it can I couldn't figure out how at least...).
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...Also, note that there is quite a bit of copying going on:
- Application calls glTexImage - Mesa allocates system memory and copies image - Driver allocates agp buffers and copies image into them - Card receives blit command and copies image to final destination.
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).
Roland
------------------------------------------------------- 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
