--- 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

Reply via email to