On Sat, 2005-11-26 at 19:51 -0500, Timothy Miller wrote: > Never, ever delete a texture from it's shadow (backing store?) in host > memory. When you need to swap textures, just unlink the ones you need > to delete from the framebuffer. Software fallbacks can also be made > to reference the host shadow. > > The only time you ever need to download something is if the GPU > modified it. Usually, textures are static, but it you have a dynamic > one, then you run into these problems.
Yes, that's what EXA does. When it uses the 3D engine for implementing compositing, the pixmap is marked "dirty". If it then needs to be migrated back to main RAM, a download is required. Similar things may happen with fb objects and other niceties that modern desktop are likely to rely on (like Xgl). > You're right that if the texture is just sitting there in memory, and > the CPU isn't modifying it, then you'll have to dedicate extra CPU > time to compressing it That, plus the cost of actually reading it from memory, especially for a large texture that doesn't fit in the L1. > Still, in many cases, compression time plus > xfer time of the compressed image may be less than xfer time of the > uncompressed image. Compare PCI speed to main memory speed. Plus, > you can maintain pre-compressed textures in memory, along with the > uncompressed versions. The other case is if the CPU _is_ modifying > the texture, in which case, it's 'hot' in the CPU cache, reducing the > CPU overhead further. Yah, possibly. We would have to be careful however how much of a burden it would be to implement such a mecanism in a Mesa driver. We may end up having to keep a pool of compressed versions of textures locally in the driver... I suppose it's worth experimenting with (heh, it's an FPGA after all) but I'm not sure how efficient that would be in the long run. > One alternative that I intend to provide is an "inline" upload. You > always have to have pages DMA mapped for your command buffer (user > processes aren't allowed PIO access to the GPU anyhow). For small > images, you can just copy the pixels into the command buffer (in an > appropriate packet). That's what radeon does.... In fact, what they have that I find quite pratical is indirect buffers. That is, the main command ring can contain a special packet type that points to a separate buffer of commands. This has several advantages. The main command buffer for example is never mapped in user space (for security reasons). The user client fills up pre-allocated/pre-mapped (typically in AGP memory but that doesn't matter) indirect buffers with commands (and possibly inline textures) and submit them at once to the kernel. That allows the kernel to do a verification pass on the command buffers for security reasons before putting them in the main command buffer, among others... > In this case, it's definitely worth it to > compress, since you have to copy the texture data around in main > memory anyhow. Yah, in that case, you could I suppose to a very fast RLE kind of algorithm or taht sort of thing .. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
