--- Felix Kühling <[EMAIL PROTECTED]> wrote: > Am Montag, den 24.01.2005, 18:12 +0100 schrieb Roland Scheidegger: > > Felix Kühling wrote: > > > I intend to improve the heuristics that chooses the texture heap in > > > driAllocateTexture. This may involve the texture size to allocate, > the > > > heap sizes and the amount of free space on each heap and maybe the > ages > > > of textures on each heap. I haven't thought too much about the > details > > > yet. If anyone has already put some thought into this I'd appreciate > > > your input. > > IMHO, the ages of textures might be crucial to get a reasonable > > heuristic. I'm not sure how much of a performance hit (especially with > > > agp 4x and the relatively slow savage chips) agp texturing has (if the > > > cards in question only have slow, narrow ram interfaces it might > > actually even be faster), but I would think that in general it would > be > > beneficial to try local memory first, but if no recently-not-accessed > > textures exist (though determining of the threshold what is recent > > enough might involve some black magic), just use the agp gart heap > > instead of throwing some local texture out. > > At least on the Savage4 with 4x AGP there is no major performance Is there a way to clock this performance? on all chips? If so this should be done by the DRM for the first fue runes of each size bracket, yes it's tax season.
> difference between local and AGP textures. However, the performance hit > of texture uploads is really bad (could probably be improved a lot by This is too. > optimizing the tiling functions). So my assumptions for an optimization > will be that, if you have to start kicking textures, you want to balance > kicks fairly (proportionally?) between texture heaps. > > > I don't think the other criteria you suggest (such as texture size in > > relation to heap size) are really a good indicator where you'd want to > > > place the texture (ok for that just-fits-local-heap big texture you > > might be better off usually with gart heap so all other textures fit > > into local memory, but OTOH maybe it's the only texture currently > really > > accessed). > > I started thinking about some variation of round robin that would ensure Weighted by ?performance?, ?total heap size?, ?number of textures?, ?avg texture size?, ?avg|max age?. Then the textures in this heap should be unmaped by age. > that each heap kicks an equal proportion of data on average over time. Weighted by performance. There is no need to force a slow heap to swap the smae as a faster one. > This would avoid the black magic of age thresholds and the like and > would allow new textures to replace old textures on all heaps, thus > reducing texture trashing on the first heap. > Texture trashing on faster heaps should be encouraged, providad there is nothing realy old on any other heap. Mike > > > > Roland > > > -- > | Felix Kühling <[EMAIL PROTECTED]> http://fxk.de.vu | > | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | > > > > ------------------------------------------------------- > 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 > Dri-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dri-devel > __________________________________ Do you Yahoo!? The all-new My Yahoo! - What will yours do? http://my.yahoo.com ------------------------------------------------------- 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 Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel