Philip Brown wrote:
On Tue, Mar 25, 2003 at 05:07:38PM -0800, Ian Romanick wrote:

Philip Brown wrote:

The core X server should not be making calls into extension modules.
Extension modules should be making calls to xfree-exported functions.
If there arent sufficient xfree-exported functions, extend or add new ones.

The idea is that the X server and the 3D driver can use the same memory manager for off-screen memory. That way pixmap cache, textures, and vertex buffers all get managed in the "same" way and share ALL of off screen memory.

Yes, and existing core X server APIs allow that.

How can it do that with direct rendering?


This was something that was discussed during the texmem-0-0-2 design talks. At that time we had talked about writing some interface routines so that the server could connect to the DRM, use the various shared memory regions, and act like a direct rendering client for the purposes of memory management. This would only be used when DRI is enabled. If DRI is enabled, the GLX layer will load the actual 3D driver that already has all of that code in it. Why have the same code in two places? Even worse, if the 3D driver code "lives" in Mesa CVS and the core server code lives in XFree86 CVS, we would have the same code living in two different trees!

Currently, when DRI is enables, the pixmap cache is very, very small, even if there are no 3D clients running.

Then DRI isnt behaving nicely, and should be a better "neighbour". And/or, the 2d layer should be more practical about its use of xf86AllocateOffscreenLinear()

Like Michel Dänzer pointed out, this turns out to not be true. It used to be, once upon a time. Aparently that problem was solved.




-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to