Jens Owen wrote:
Ian,AFAIK, your assumptions about AGP mappings are correct. Jeff would be the one to ask, though. :)
I had a chance to read your ideas on memory managment last night. First off, I'd like to thank you for doing a very good job of collecting requirements and then seperating out your ideas for implementation. This level of discipline really helps me understand where you are constrained by requirements vs. where you are exploring solutions.
As you address the very complex issue of virtualizing graphics subsystem resources, I'm going to attempt to influence your thinking to include the concept of a 3D desktop compositing engine. You've make references to capabilities that Apple is supporting, yet to me the ultimate challenge that the Apple desktop paradigm provides today is the 3D and composoting effects they are doing with Genie bottle window iconfication and multilevel window transparancy. Starting to address these capabilities in open source will put additional requirements on the resource management requirements.
Ian Romanick wrote:
What follows is the collected requirements for the new DRI memory manager. This list is the product of several discussions between Brian, Keith, Allen, and myself several months ago. After the list, I have included some of my thoughts on the big picture that I see from these requirements.Are the AGP aperture issues present for any AGP page swapping, or just for assigning new, random virutal memory pages? I was under the impression that preallocated AGP memory could be swapped in and out on the x86 platform. In other words, it would be difficult to dynamically map a user texture into the AGP aperature, but we could create a pool of AGP memory that was larger than the apperature and use the APPLE_client_storage extension to allocate space from that pool to the application.
1. Single-copy textures
Right now each texture exists in two or three places. There is a copy in on-card or AGP memory, in system memory (managed by the driver), and in application memory. Any solution should be able to eliminate one or two of those copies.
If the driver-tracked copy in system memory is eliminated, care must be taken when the texture needs to be removed from on-card / AGP memory. Additionally, changes to the texture image made via glCopyTexImage must not be lost.
It may be possible to eliminate one copy of the texture using APPLE_client_storage. A portion of this could be done purely in Mesa. If the user supplied image matches the internal format of the texture, then the driver can use the application's copy of the texture in place of the driver's copy.
Modulo implementation difficulties, it may even be possible to use the pages that hold the texture as backing store for a portion of the AGP aperture. The is the only way to truly achieve single-copy textures. The implementation may prove too difficult on existing x86 systems to be worth the effort. This functionality is available in MacOS 10.1, so the same difficulties may not exist on Linux PPC.
APPLE_client_storage isn't really an allocator. It allows applications to tell the GL that it can keep and use pointers to application storage (i.e., pointers passed into TexImage2D). The optimization that can be done on MacOS is to not only use those kept pointers as the backing store for textures, but also remapping those pages into AGP space to be directly used by the graphics hardware.
Having multiple physical pages to back AGP pages could be useful for ARB_vertex_array_objects, so I'll keep that usage in mind.
[snip]
That is to say, fall back to the current static back / depth buffer allocation system. That was something that I had considered, but didn't explictly say. For some set of active OpenGL contexts, a kernel memory manager could decide that it was more memory efficient to fall back to the single, full screen back / depth buffer system.3. Accommodate other OpenGL buffersFor traditional 2D window systems, this requirement is sufficient in that you don't need to be able to truly provide an unlimited amount of private buffer space...rather when you run out of space, you can fall back to a method where memory is allocated from a single large buffer based on visible display pixels.
The allocator should also be used for allocating vertex buffers, render targets (pbuffers, back-buffers, depth-buffers, etc.), and other buffers. This can be useful beyond supporting SGIX_pbuffer, ARB_vertex_array_objects, and optimized display lists. Dynamically allocating per-context depth and back-buffers will allow multiple Z depths be used at a time (i.e., 16-bit depth-buffer for one window and 24-bit depth-buffer for another) and super-sampling FSAA.
That said, a 3D compositing window system couldn't fall back on this method. Imagine N transparent windows all stacked on top of each other and each needing dedicated display resources in order to yield the correct final display results. Virtualizing an infinite number of color and alpha layers may not be possible in hardware alone, but software compositing can be prohibitively slow. Perhaps providing a large dedicated amount of resources to 3D compositing and virualizing all non visible resources could provide a reasonable solution. This implies that back buffers, depth buffers, pbuffers and super sampled buffers all need to be potentially swapped out when the rendering context is swapped out.
Ugh. THAT is a difficult problem.
[snip]
With an in-kernel memory manager this would be possible. If everything is running in user-space, one process B would have to copy process A's back-buffer into process A's private address space so that process A could restore it later. This is one of the issues that complicates swapping out render-target textures (i.e., glCopyTexImage targets). When process B need to swap-out process A's texture, it can't do it until process A has copied the modified texture data out of texture memory so that it can be restored later.* My Thoughts *
There are really only two radical departures from the existing memory manager. The first is using the memory manager for non-texture memory objects. The second, which is partially a result of the first, is the need to "pin" objects. It would not do to have one context kick another context's depth-buffer out of memory!
Why not swap out another context's depth buffer? If it's not being used at the time, is that any worse than swapping out textures that are actively being used by the yielding context?
[snip]
That is correct. I had forgotten about that. :)There is another caveat for PBuffers that Allen brought to my attention a few years ago. They way they are currently defined, it's possible for the application to request a PBuffer that can not be "destroyed", but rather must be swapped out and then restored later.- pbuffers - While rendering operations to the pbuffer are in progress. pbuffers have a mechanism to tell an application when the contents of the pbuffer have been "lost." This could be exploited by the memory manager. One caveat is when a pbuffer is bound to a texture (ARB_render_texture). While the pbuffer is bound to a texture, its contents cannot be lost. Can the contents be "swapped out" to some sort of backing store, like with glCopyTexImage targets?
-------------------------------------------------------
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
allow you to extend the highest allowed 128 bit encryption to all your clients even if they use browsers that are limited to 40 bit encryption. Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
