> About the Mesa backing store for textures, is there any reason why this
> memory cannot be mapped into AGP space? Admittedly, my knowledge of AGP
is
> very thin, but I always thought that you had some amount of virtual AGP
> address space that you could map to basically arbitrary physical pages...
Well there are some issues with mapping the backing store into AGP. If we
ever need to directly access an image from the CPU we can't map the physical
pages into agp memory because every read access from the CPU will be
uncached. (Unless the host chipset has a special cached agp memory type,
which most do not have anything close to this functionality.)
However there are some cleaver things that could be done here. We could
always create an image in agp memory for each texture. We would keep the
mesa image though in case we need to manipulate it. Whenever we load a
texture to the card we could always load from the agp image. In situations
where there is more then one context we could decide to swap in and out
regions of agp memory from addressable agp space. This requires an aging
mechanism, and in degenerate cases a graphics pipeline flush. However this
aging mechanism should be optimized for common cases, so that pipeline
flushes are rare. Perhaps always having at least two seperate swap regions
in agp space would be useful in this sort of arrangement. That way at least
the two contexts situation never can cause a pipeline flush.
In my opinion though any implementation should be very careful not to cause
memory to be swapped in and out when there is not an open slot in their agp
space. It will typically be faster to fallback to writing the texture
directly to the card then to flush the pipeline.
Another thing that could possible be interesting is only keeping one copy of
the texture in memory. If the card can perform blits to either agp or pci
memory this could be accomplished. In the optimial case the card would be
able to perform both. In most cases it writes back the texture to agp
space, but if you need to read it back you use pci memory, which won't have
the cache penality. Anyhow you get the general idea.
> Yes, it could be, vektor was asking about this for video on the irc
monday.
> We just never have, but I'm sure it can be a big win. Also for putimage,
> etc. We've never done anything clever with dynamic agp usage. Jeff might
> have more info, if he's out there...
>
> Keith
Remember whenever you transition memory into agp space that has been cached
before, you must flush the cache's on all CPUs. (Can be very bad on SMP
systems, seems managable for single cpu systems, but less then ideal.)
Basically the rule is that if you need to ever read something again, don't
use agp memory (unless like stated before the card can do that for you.) If
you can get around the readback problem, and you can avoid graphics pipeline
flushes, dynamic agp usage can be a good thing. My personal opinion is that
if a client uses agp memory, we should limit how much they can use. If a
client continues to request texture space above that given limit, we should
fallback to only using regular memory.
Perhaps a good solution for some cards is to fallback to using regular page
aligned cached memory. Some cards can load textures from there, and we can
have the kernel only lock the pages when they need to be used by the card.
Basically there is alot of work that could be done to optimize this part of
the DRI. If anyone wants more specific information, email away...
-Jeff
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
