This was posted in the utah-glx list (@sourceforge) and rather reminded me of pingpong buffers, which we were talking about earlier. It would be nice if somehow there was a convergence towards doing the right thing, outside XFree86 4. Justin Forwarded message: > The recent official nvidia 3d driver release for linux seems to have > stopped all nv bug reports, so I've been lucky enough to have lots of > spare time to devote to experimentation with the nv driver. > > The official nvidia driver is fast. Damn fast. Their driver uses DMA > to transfer commands to the card, and uses their equivalent of direct > rendering, so I'm not surprised that it zooms along. > > I've spoken with some people who have suggested that a kernel module > might help improve the utah-glx driver, even without DMA support. The > idea would be to create a largish command buffer in system memory, 4 > to 8 meg, contiguous pages (?). The client side would mmap the buffer > and pile lots of commands directly into the buffer. > > The kernel module would usually be inactive, but using the timer irq > it could be forced to periodically wake up and push the commands onto > the nvidia FIFOs. By tuning the period it should be possible to keep > the FIFOs never empty and therefore the 3d processor always busy. Two > command buffers would let you empty one while filling the other. > > The immediate speed benefits would be... > > - no process switch from the client when rendering > - no busy polling in the client (waiting for FIFOs to empty) > - no GLX encoding/decoding at any stage > - 3d processor should always be busy due to full FIFOs > > What I'm fishing for is advice from people who know more about stuff > like this. Does the idea have merit? It's a non-trivial coding job or > I'd have already determined the idea's merit in practise. > > Or to put it another way, I've tried writing this code, and I've got > the fscked disks to prove it, so I've decided to stand back and think > a bit more before I do permanent damage. > > The DRI in XF4 seems to share some ideas in common here, and DRI has > already solved all the hairy problems with multiple clients, commands > which return data (GetPixel), etc. Would I be better off porting the > nv 3d driver to XF4 with DRI then code the FIFO-pushing kernel module > idea there, rather than stuffing around with 3.3.6 and utah-glx? > > If people don't have answers, I'm cool with that. I've got plenty of > experiments I can try which may answer some of these questions. But I > wouldn't mind some advice from the wiser beards on this list first. > > _______________________________________________ > utah-glx-dev mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/mailman/listinfo/utah-glx-dev >
