To all: Ok, here are the kinds of DMA transactions that I want to support:
(1) Direct command buffer. Using a ring buffer with "read pointer" (controlled by GPU) and "write pointer" (controlled by CPU), the host can fill an empty portion of the buffer, starting at the write pointer, with command packets. The GPU fetches words in blocks and feeds them into the GPU fifo. (2) Indirect command buffer. Using PIO or a ring buffer, arbitrary host address ranges are specified. The GPU fetches them in blocks, in order. This is useful for multitasking, where there is a central server and individual packets from different processes are thrown into the one ring buffer. (3) Direct data move. Data to be written to graphic memory is loaded directly into the ring buffer. In this case, the graphics memory, rather than the GPU engine is the target. Moves from card to host are not possible this way. (3) Indirect data move. Using either PIO or a ring buffer, arbitrary host address ranges are specified. The source/target is graphics memory, and either reads or writes can be specified. For indirect DMA, an interrupt can be asserted for the completion of each unit. For direct DMA, two interrupts are available: ring empty; ring has reached low water-mark. On Tue, 1 Feb 2005 22:35:39 +0100, Rodolphe Ortalo <[EMAIL PROTECTED]> wrote: > 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. If you start to swap to disk, you're in a low-memory situation anyhow, so we don't care. > > 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). Yeah, since it's done in software, all sorts of sophistocated algorithms can be implemented with little overhead. > 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. Yeah. Well, when swaps happen, processes waiting on them will sleep anyhow, which at least will free up CPU time for other things. > > 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?). MIP maps are required to be completely contiguous. A texture and its MIP maps must be managed atomically. > > 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.). Yeah... "nice" things are not so interesting to us right now. Only "necessary" things are. As long as the GPU can do a reasonably efficient job of moving data around (repacking or DMA) in the framebuffer, it won't be a problem. > > 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). The zero-copy scheme is for the user process to have a piece of DMA memory that it's mmapped into its address space. The IOCTL is used for two purposes: (1) do not expose register interface to user process, (2) DMA buffer synchronization functions may only be available from inside the kernel. (When the CPU has written to host memory, you have to be sure it's gotten out of the CPU cache into main memory, and that there isn't "old" data cached in the MB chipset. When the GPU has written to host memory, you have to make sure MB chipset buffers are flushed to main 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...) The kernel can have a watch-dog timer, and there would be a reset register to write to in the GPU that kills certain states. If the timer expires, the kernel can just issue the reset command. Also, there could be tools that issue it unconditionally, like pci-tools and usb-tools sort of thing. > > Comments? > > Oh, btw, ioctl() involves copying (arguments) from userspace to kernelspace, > no? Yes, but the arguments to be copied would be trivial. Any actual packet data would be written directly to a DMA buffer by the user application. (Zero-copy) _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
