Stephane Marchesin wrote:
Hi,
I was considering how complicated it can be to implement a texture
replacement policy, and then I had the following idea : we could make
use of hardware cocclusion queries on cards that support them to
determine actual texture usage and thus have a good texture replacement
policy. Here is a simplified view of how this could work :
- a usage counter is added to each texture
- each time a texture is bound, a query is started
- each time a texture is unbound, the counter is read back and added to
the corresponding texture counter
- after a number of frames, we are able to compute the number of pixels
actually contributed to by each texture, and thereby determine texture
usage on the fly. Then, we can use this information to move textures
to/from agp/video ram accordingly.
Given that occlusion queries are virtually free (at least when supported
by the underlying hardware) I think this approach could work quite well.
It is also possible to extend it to multitexturing without too much
trouble. What do you think ?
An interesting idea. I have some doubts though it is worthwile to
implement this (though occlusion queries on their own certainly seem
useful). One reason I think it might not be too useful is because gart
texturing is not _that_ slow usually, so using feedback might be
overkill. Also, just because you know how many pixels are affected by a
texture doesn't really tell you how much memory bandwidth for texture
reads is necessary, it only gives you a rough idea (since there are
texture caches, and also the texture associated with an object might be
huge but reads only occur for a small mipmap etc.).
I think some mechanism not using any feedback (i.e. just counting how
many times a texture is used per frame and taking texture size into
account) would be quite acceptable for now - and in a world where xaa
wouldn't steal half your local video memory for pixmaps memory pressure
should be quite a bit lower too.
And while occlusion queries might be virtually free in terms of hardware
resources, the code might not look pretty.
I think at least newer gpus should probably have even more appropriate
performance counters if you really want to use a feedback mechanism.
Roland
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
