Hi Michael, Coincidentally, much of what you're talking about is in progress already, though with i915 as the initial target.
Basically the old style memory manager had some advantages of simplicity (no kernel component, primarily), but you are right that it can be improved on and a rewrite is overdue... Keith --- Michael Bautin <[EMAIL PROTECTED]> wrote: > Hello All, > > I have a question about texture memory management in the r200 driver. > What is a primary need for a separate memory layout version for every > client? > Would not it be simpler if there was only one memory heap in the sarea with > a > global LRU list? Then there would be no need for heap layout synchronization > and region aging, as well as for a global LRU region list. And that would > possibly > allow for economical memory management (we don't need to kick out up to 2MB > of other people's textures at once, we only need as much as we need). Also, > this would allow for texture sharing if we somehow could find out that > someone else > is using exactly the same texture. Was that solution considered when the > r200/radeon > driver was being designed? What difficulties that I have overseen would it > imply? > > Sorry for offtopic as this is not really related to the current r300 > development activities. > > Thank you. > Mikhail Bautin > ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 -- _______________________________________________ Dri-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
