--- Felix Kühling <[EMAIL PROTECTED]> wrote: > 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 I was thinking allong the lines of not doing any thing extra exept getting the time and comparing time stamps. I just can't see how this would work for something like a GPU/chip access.
> 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 My asumption was we woulden't need these numbers untill after was had been rendering since I was thinking about doing this system-wide. > 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. ;-) > This dosen't take into account memory bus speeds and AGP brige vendor/product and settings. > > > > > 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? > I didn't think it would be independent, the hooks should reside in the text upload and *use* functions. What would be driver-independent is where, how and if the results are stored. > Also, it's not at all clear to me how these two different performance > values would influence the heap choice heuristics. Upload performance is Let's say heap one(A) is half a fast as head two(B). For every block(16 bytes?) in B that we swap out there should be 2 for A. Basicaly so that the time we spend swaping in each heap is the same, not the amount. > 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 This is where things get driver-specific. I don't realy think this of use unless text can be premoted and demoted. This type of performance may not need to be measured. > 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. > yes, but if one heap is slower it's kick/upload rate won't be able to be as high per byte. > 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 > __________________________________ Do you Yahoo!? The all-new My Yahoo! - Get yours free! 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