On Friday 28 January 2005 18:21, Timothy Miller wrote: > I want to drop a feature: The ability for the rendering engine to > access host memory. That is, you can't have a texture in host memory. > Instead, DMA can do two things: (1) fetch drawing commands, and (2) > move blocks of memory data in and out of the graphics memory.
I'd favour anything that simplifies the hw DMA programming. IMHO the key issues are not in fancy hw DMA, but in a design that take into account the rest of the system components (kernel, MMU, etc.). > What this means is that if a texture is not in graphics memory, > something has to be swapped out first. IMHO, that's not a problem... that's even a feature. >From what I saw, performance-oriented guys usually do not even listen about rendering with textures in main memory (even with AGPx8). They _may_ listen if one talks about the graphics chipset fetching vertices list from main memory, but only if AGP >8x and if they do not code themselves... :-) Non performance oriented guys do not even notice if the textures come from the on-board memory (the non-framebuffer part of the framebuffer), from main memory via AGP (1x,2x,4x,8x - they'd buy 3x if it was cheaper) or from main memory via PCI. The _may_ notice if it comes from the hard disk swap with a slow disk. So, the whole issue is IMHO, the scheduling of the texture "cache" (it seems to me the on-board memory is used as a sort of texture cache) replacement. The strategy of replacement may not be very important: every software I saw used LRU (I welcome contradiction on this one, I always wondered if better strategies were useful). However, the scheduling is very important to "smooth" the texture cache management. One has to avoid absolutely to freeze the rendering process enough for users to see it. Another issue here may be mipmapping (?). I am not sure of my terminology here but I think mipmapping is the right word: I mean when one stores a texture a various resolutions (typically a power of 2: 4x4, 16x16, 32x32, etc.). There, managing the texture cache becomes complex no? (Unless you have _several_ distinct texture caches in the on-board memory - but this probably leads to hw design issues then?). > This then makes me thing about memory management. What I would like is > unified memory management between GL and X. We can implement this as a > daemon. The daemon manages both graphic memory and pixmaps/textures > which have been swapped out. In addition, it's good to use a user > process for this so that swapped out images can also be swapped to disk > (automatically by the VM). Don't bother... Software guys will invent their own techniques managing memory. But think about the hw mechanisms they will want to use (zero copy by moving pages at once, hw driven copying, "clean page" bits, write protection, etc.). > Our kernel driver can provide an ioctl interface which allows > applications to allocate memory (and when an application dies, the > kernel can figure it out and automatically free the resources). While > this would entail some overhead, I don't think it would be so bad. It's certainly not bad. But think about a zero-copy scheme (wrt to main memory I mean, of course one will need to copy from main memory to on-board memory). > One of the jobs of the memory manager is to make sure that textures are > available when they're needed. Using a LRU algorithm, it can swap > textures in and out just before they get used. No problem at all. Personnally, I'd like to have several such managers, so I would also like to have some form of memory protection on the on-board memory so that one manager cannot mess the memory of another manager. A single (start,end) region can be useful (switching between the two managers need not be efficient), with write-protection; and possibly also read-protection (wrt your confidentiality concern). [...] > Furthermore, we only ever want the user process to instruct the GPU via > DMA, and we can limit the DMA command set so that the worst it can do is > corrupt graphics memory data. While we'll give X11 direct control over > DMA, user-space OpenGL will generate command packets and place them > appropriately into a DMA buffer, but it will have to SUBMIT those > commands via an IOCTl. Then the only thing left is being able to lock > up the GPU. However, as it stands, I believe that the worst that can be > done is to make the rasterizer loop for a long time. Can this loop issue be easily solved by offering a "privileged" interrupt operation? BTW, it seems to me it would also be useful for debugging. (Sometimes, such rasterizer loops are just accidental, and CTRL-C does not work...) > Comments? Oh, btw, ioctl() involves copying (arguments) from userspace to kernelspace, no? _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
