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

Reply via email to