Am Montag, den 07.02.2005, 09:20 +0000 schrieb Keith Whitwell:
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.
One 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.
The Savage driver does this. Currently it waits for engine idle before uploading a texture. I thought there must be some more efficient (age-based) method. I havn't looked into the details yet. Do you have a hint that would get me started in the right direction?
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).
The Savage driver uploads textures by memcpy (actually a bit more complicated due to texture tiling) to destination memory.
The savage upload mechanism is effectively the same as the via's was before this change - Mesa is still creating a copy of the texture in local memory (and using it's texstore functions to populate it). Later on, the upload to AGP/FB memory is done by a SetTexImages/UploadTexImages step.
Because savage (like via) has a simple kernel texture memory manager, there's no actual reason the upload can't go straight to AGP or framebuffer memory, skipping the intermediate copy.
Have a look at the code on the mesa_20050114_branch - it's quite different to the standard dri driver mechanisms. It's really just waiting for Ian's memory manager to round the whole thing out to a "grown up" texture memory system.
I did some optimization of that tiled upload recently. Now oprofile shows that most CPU usage in texdown is not in the tiled upload but in mesa's texstore-functions. I suppose they could use some optimization too.
I've done a little bit of this on the (badly named) mesa_20050114_branch. There are some pretty obvious things to do there which I'll pull onto the trunk today.
Keith
------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- _______________________________________________ Dri-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
