On Wed, 2005-08-24 at 09:18 -0600, Brian Paul wrote: > Michel Dänzer wrote: > > On Wed, 2005-08-24 at 00:40 +0200, Stephane Marchesin wrote: > > > >>Alan Cox wrote: > >> > >>>Other stuff like textures is merely annoyance value. Knowing who owned a > >>>block for cleanup matters and the DRI lock/mem handling on some chips > >>>already handles it. Its also cheap because you only have to track some > >>>kind of texture handles not pages for cleanup. > >> > >>Actually, the long term idea is to have both dri and ddx allocate from > >>the same memory pool. So we can't rely on texture handles for that. > > > > > > May I ask why we can't, assuming this is done via EXA callbacks into the > > DDX driver that use the shared memory manager? > > When thinking about the memory manager, there's far more uses for > graphics memory than just textures: > > The framebuffer (including color, Z, stencil, etc) > Pbuffers > Renderbuffer/Framebuffer objects > Pixel/Vertex buffer objects > Texture images > OpenGL miscellaneous (e.g. vertex/fragment programs) > X server miscellaneous (pixmap cache, etc) > > So, just constructing a memory manager around texture handles seems > short-sighted.
Indeed, I think Alan probably meant the opaque handle for memory objects you mention below, at least that's how I read it. > Furthermore, different memory objects may have different > requirements/properties: > > 1. The location of the object in memory (perhaps the framebuffer has > to be at the start of memory). > 2. Particular byte/word alignments > 3. Can we use VRAM and/or AGP memory for the object? > 4. Can the object can be lost asynchronously (Pbuffers)? > ... plus others I'm surely forgetting or not aware of. Yes, I think these and maybe more should be handled via parameters when allocating a memory object. What I'm not sure is whether it's better to specify these specific but HW-dependent attributes or maybe some kind of abstract attributes (can be rendered to/from / scanned out / ...) which are then translated into specific constraints by a HW specific part of the memory manager. I'm leaning towards the latter. > Bearing in mind that I'm probably among the least knowledgeable of the > Linux kernel among those here, here are my thoughts on the subject. [...] I agree with all your requirements. > I think it would be worthwhile to start a specification document for > this project (or perhaps a wiki page) where the requirements, issues > and proposed interface could be recorded. Indeed, thanks for such a nice summary! -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast | http://svcs.affero.net/rm.php?r=daenzer ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf -- _______________________________________________ Dri-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
