Am Montag, den 24.01.2005, 15:27 -0800 schrieb Mike Mestnik: > --- Felix Khling <[EMAIL PROTECTED]> wrote: > > > Am Montag, den 24.01.2005, 18:12 +0100 schrieb Roland Scheidegger: > > > Felix Khling 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.
Not easily. You'd have to do some actual rendering with textures on different heaps. In order to get meaningful numbers you'd have to do a lot of rendering (a few seconds in time) with each tex heap as texture source. This would be very hard to do in a driver-independent way. The easiest way would probably be a hook in the driver. The easiest implementation of such a hook would be to return constants based on previous benchmarks. ;-) > > > 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. With pipelined texture uploads this is hard to measure, because you're interested in throughput, not in latency. The Savage driver doesn't pipeline texture uploads, so it would be easier to measure, but you asked for something driver-independent, didn't you? Also, it's not at all clear to me how these two different performance values would influence the heap choice heuristics. Upload performance is easy to consider. But texture rendering performance is harder. Would you refuse to use the AGP heap because it's slower? Maybe in that case you'd want to disable the AGP heap altogether. > > > 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. Weighted by heap size. In my eyes it makes sense that a heap with more data also has data uploaded and kicked at a higher rate. In the ideal case you'd observe the same behavior as if you arbitrarily split a single texture heap and measure the kick/upload rate on each part. And yes, once you have chosen a texture heap, you'll kick oldest textures first. I'm not planning to change that. > > > 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. More precisely, weighted by upload performance, if you really want to do this. BTW, in case of the Savage driver we currently do the worst. We have texture trashing on a small heap with slow upload performance. > > > 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. Only if you mean "uploads are really fast" with faster heaps. I don't know how realistic that scenario that is on different hardware. IMHO trashing is a bad thing in general. If you have a second heap, use it. If you don't want to use it, because it has slower rendering performance, then simply disable it. It may make sense to make this configurable per-application. > > Mike > Thanks for the feedback. You may not agree with all my conclusions, but you certainly made me consider a few more parameters. -- | 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
