Anyone experienced with Texture management & priorities

[Rodéric]

I would like to know how to choose a texture priority in a Texture Manager for maximal efficiency.

At the moment I've found that scheme:
For each 'active' Texture, count Mesh using it => Texture Active Mesh Count
Count all 'active' Meshs => Active Mesh Count

Priority = ( TAMC / AMC )

I think the Priority would need to be tweaked depending on the texture size, but since compression... is involved it's hard to know how much it really takes... could maybe use pixel count instead...

Any idea, suggestion, article, link ?

 

[darkblu]

many approaches try to avoid what you've been trying to sole with those priorities: meshes are sorted by texture so that when a texture is used in the scene it's more or less done with. of course, here we can distinguish among several types of textures potentially paticipating in a multi-texutre shader, but the principle remains.

ps & ot: you may want to move this topic to '3d arch and code' for better exposure.

 

[Dio]

Here's a few things to think about

- typical pixels per texel. 'standard' mipmapped textures this factor is ~1, raise priority for minified textures (if forcing LOD bias - I don't recommend this), lower priority for usually magnified textures (e.g. lightmaps)
- filtering type. Aniso > trilinear > bilinear
- size isn't a big effect (the chips are designed to assume you miss every pixel) although very small textures can usually be given low priority
- raise priority for textures used in multitexturing (but note that one texture of a set placed into AGP will probably not be a significant hit)
- compression lowers priority somewhat, but use up less space: 20 compressed textures in VRAM vs 4 uncompressed in AGP is probably a lot better than the other way round...

Note that the most important thing to do with priorities is ensure that you register textures in priority order, most important first.

 

[Rodéric]

The task of the priorities is to make sure most often used textures are in VRAM by giving them a high priority, and also to reduce texture trashing/upload through AGP by giving BIG textures a high priority.

(So that only small textures are transfered over the AGP bridge)

 

[Dio]

It doesn't matter too much how big it is, just how many times the chip has to issue misses to read it.

What I gave above were the rough parameters defining miss rate assuming the same number of pixels are rendered using each texture, so modulate this by pixel count and you have a reasonable formula.

 

[darkblu]

ok, i somehow got the imression you were talking of per-frame textures prioritisation, my bad.

though you may be searching for empirical hints, it would still be interesting to outline some underlying guidelines for defining an effective texture-handling strategy. for instance, you may want to start with formulating what you actually expect from such a strategy: in the ideal case, you're pursuing a strategy which would allow you at each gpu-idle moment from the frame rendition timespan to have something ready to "pass on" to that gpu (i.e. a mesh with its corresponding textures available locally).

inferring from the above, you may need to constantly keep the following information at hand:

* which of the draw-pending meshes have their textures already uploaded (group A)
* which of the draw-pending meshes need their textures yet to be uploaded (group B)
* which of the already drawn meshes from the scene have texures not to be used anymore, and to what space amount the latter (group C)

knowing the above you may want to arrenge that:
whenever you have a set of geometry to be rendered from A, you pick the best* corresponding texture set from B that would still fit in the room freed after disposing the textures from C.

* the 'best fitness' criterium in the above would be one that selects such a texture set from B, the upload time for which would best match the rendition time of the geom set from A, i.e. generally you pick a bigger texture set to upload whenever you have more geometry to render and a lesser texure set to upload when you have something simpler to render.

from here on you can start searching for factors, could be purely empirical as well, which would help you in achieving the above 'streaming' strategy, utilising best the asyncronous nature of gpu's (cpu-gpu asynchronicity and rendition-dma asynchronicity, or lack thereof, within the gpu itself, and generally stuff like that : )

ugh, despite my wish to be of help i'll have to leave my ramblings at this stage and step back from the soapbox for a while. in the meantime some of the more knowledgeable folks around may step in with actual info on how to achieve texture streamability on this or that gpu (as i suppose Dio did : )

 

[Rodéric]

Been busy on other things, not really had time to read everything and understand it, however be assured that what you say isn't falling in a deaf hear.

I think the idea is to load all ressources required for a frame before it starts being rendered, and what to remove from VRAM to make that update as fast as possible.
In the case all ressources can't fit VRAM anyway, I think we fall in non interactive framerates...

-late so I might be w bit off-

 

[darkblu]

I think the idea is to load all ressources required for a frame before it starts being rendered, and what to remove from VRAM to make that update as fast as possible.
In the case all ressources can't fit VRAM anyway, I think we fall in non interactive framerates...

-late so I might be w bit off-

you'll be surprised how interactive a framerate could be when using streaming techniques to handle insufficient VRAM conditions -- just take a look at a console game* : )

* not on the xbox where they have UMA

 

[Rodéric]

I was really out of my mind yesterday... kept saying stupid things...

Little sleep + many things to do = broken

 

[Rodéric]

In the end I took into account the texture size, size = Bytes, not dimensions, and only have a special 0 use value which set the Priority to 0.

(So just like Dio suggested, that was already how I was computing tex size)

I scale priority between 0-0.9 and keep 1.0 for RenderTexture (although I think that's maybe not required).