On Wed, Mar 26, 2003 at 12:10:48AM -0800, Ian Romanick wrote:
Philip Brown wrote:
Well, okay, there needs to be a little extra handholding between server and client. So, you add a GLX_dri_reserve_mem extension or something that reserves video memory by proxy. Or do it in some more direct fashion, bypassing GLX protocol overhead if you prefer, but still letting the GLX module on the server reserve it cleanly through the server interfaces.
That's the clean way to do it, even if it requires more coding on the DRI side.
For non-video (ie AGP) memory, the issue isnt relevant, since the client can do the reservation through the drm kernel driver directly, I believe.
After reading this I honestly believe that you and I must be talking about different things. I'm talking about allocating a block of memory to hold a texture that's going to be read directly by the rendering hardware. The texture should be kept in directly readable memory (either on-card or AGP) unless the space is needed by some other operation.
Not only that, this is an operation that needs to be fast. As fast as possible, in fact.
Yes, I know that. Sounds like we just didnt get down to discussing the details.
Consider the GLX_dri_reserve_mem as equivalent to sbrk() Then have a more local memory allocator for subdividing the large chunk. That's going to be a lot more efficient that relying on the XFree routines to do fine-level memory management anyways. xfree's routines arent really optimized for that sort of thing, I think.
Okay. You're just not listening. THAT WON'T ALLOW US TO IMPLEMENT A FUNCTIONING 3D DRIVER. Textures memory is like a cache that is shared by multiple running processes. We need to be able to do the equivalent of paging out blocks from that cache when one process needs more memory. An OS needs something under sbrk in order to implement paged memory, and so do we.
Going to a system where we add memory to our available pool while processes are running won't add much, if any, tangible benefit to users. Instead, it will make a lot of work for DRI developers (every process with a GL context will have to be notified when any context makes a magic sbrk call).
Utah-GLX doesn't have these worries because it only supports one GL context at a time. DRI drivers don't have that luxury.
------------------------------------------------------- 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
