Stephane Marchesin wrote: > Keith Whitwell wrote: > >> We've just merged the texmem-0-3-branch code. This has been a major >> project, probably much bigger than we realized when we started on it. >> >> The fundamental technology underpinning the changes is Thomas >> Hellstrom's new TTM memory manager which dynamically maps buffers into >> and out of the GART aperture as required for rendering. >> >> The benefits that flow from this are: >> - Vastly increased amount of memory available for texturing. >> - No need to reserve/waste memory for texture pool when not rendering. >> - Fast transfers to *and* from video memory. >> >> As a result we've been able to build a whole bunch of features into the >> i915tex driver that haven't been present in DRI-based drivers previously: >> >> - EXT_framebuffer_objects, render to texture >> - ARB_pixel_buffer_objects >> - Accelerated >> - CopyTexSubimage >> - DrawPixels >> - ReadPixels >> - CopyPixels >> - Accelerated texture uploads from pixel buffer objects >> - Potentially texturing directly from the pixel buffer object (zero >> copy texturing). >> >> If/when other drivers are ported to the memory manager, it will be easy >> to support VBO's in the same way. >> >> > > Hello, > > Nice work on the code and design ! It seems to me that this can really > provide significant speedups for AGP access. > > Now, I'm interested in knowing what will happen next. In particular, I > have two questions : > - the current design always assumes that memory chunks are mapped into > the process space, which is not always possible with, say, VRAM above > 128Mb on radeon. If the design is to be unified, that's an assumption > that can cause some trouble. How will that be done ? > - second, no real solution was proposed for cards which have multiple > hardware contexts > (http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg28472.html). > I expect this hardware model to be more widespread in the future. How > should we handle it ? In my opinion, it's not only for supporting a > single kind of hardware (in which case we'd happily write our own memory > manager), but more about being future-proof. > > Anyone ? It would be nice to know the goals of the current memory manager. If it is only tailored for low-end graphics, we will simply write our own system. But we need to know.
Stephane ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
