Quoting Jens Owen ([EMAIL PROTECTED]): > Denis Oliver Kropp wrote: > >Quoting Ian Romanick ([EMAIL PROTECTED]): > > > >>Denis Oliver Kropp wrote: > >> > >>>Hi, > >>> > >>>I just branched the embedded-1-branch and committed my changes, > >> > >>>from the commit log message: > >> > >>> > >>>Architectural changes > >>>--------------------- > >>> > >>>Moved global (and static) front/back buffer offset/pitch/cpp to the > >>>drawables > >>>for dynamic allocation of multiple buffers. > >>> > >>>Made driverContext.shared.fbOrigin the amount of video memory that won't > >>>be used by the driver for local textures etc. > >>>The windowing system will allocate front/back buffers below this origin. > >>> > >>>Removed front/back buffer offset, pitch, width, height and cpp from > >>>mgaScreen > >>>and mgaDMAInit. Added them to mga_context_regs_t. > >> > >>This is along the same lines of some changes that will be made with my > >>next round of texmem changes. Could you explain what you've done a bit > >>more? > > > > > >Currently the drivers get statically allocated buffers passed during > >initialization by the server. I want each client to pass these values > >to the driver for each context it created. > > An important case to consider is how to handle the case of running out > of memory. When running in the X environment we share single full > screen buffers and utilize the window clip list to determine which > drawables own which pixels. > > If you go for a scheme where each drawable has a private set of buffers, > it will be possible to run out of memory once a certain number of > drawables has been created or resized. > > Handling these memory allocation failures gracefully is the challenge, > especially with resize.
Memory allocation is handled by DirectFB's surface manager which still is at an early stage but already handles kicking out of old surfaces using a kind of rating. OpenGL front and back buffers are already allocated by DirectFB, they're simply the offscreen surfaces of the windows or the surface of the layer (i.e. the visible screen) in fullscreen mode. The depth buffer is still allocated once by the driver, but I also want to let DirectFB allocate a depth buffer for each DRI drawable. Textures are allocated by the DRI driver. Until there's a way to give DRI a custom memory manager (our surface manager for example) I have split the video memory into two static pools. So running out of video memory for the drawables won't be a problem of DRI but of the windowing system using it. However, abstracting the texture memory manager to override DRI's default implementation might be quite some conceptual work. -- Best regards, Denis Oliver Kropp .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" Convergence GmbH ------------------------------------------------------- Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara The only event dedicated to issues related to Linux enterprise solutions www.enterpriselinuxforum.com _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
