On Tuesday 23 October 2001 11:28, Manuel Teira wrote: > This is an interesting problem. How are other drivers dealing with this? I > suppose that the mach64 driver only should try to load the agpgart when the > card is agp based. I'm trying to see how could this be made.
The Utah-GLX code's got a good example of this- just check to make sure that the DRM infrastructure code (in the drm* files) isn't the one doing the loading and it's the Mach64 code doing it. > Anyway, what I'm impatient to see is the results with the DMA working. > Frank, when do you think you'll have time to start this work? I've been > looking at the mga and the i810 driver, but I'm not seeing it clear. In the > UTAH-GLX driver there were two dma buffers, true? Should we use a freelist > in the DRI driver for the mach64? When should the DMA buffers be sent to > the hardware? Could different clients have different DMA buffers > simultaneously? I just checked it out last night. I've got to get it where it's compiling so it may be a day or so before I get to any DMA changes. I'm thinking something along the lines of a freelist if it doesn't have too much overhead- but it's going to be largish blocks- from my testing of games for Loki, I've discovered that each pass can use upwards of 512k or more per frame. Better performance is obtained with _long_ lists for the chip to operate against as it allows the CPU to be doing other tasks longer. It's a compromise- you want the longer lists, but you don't want the CPU to be waiting for a free list space too long so you try to pick a decent size and offer up enough slots for it to basically fly. As for when they should be sent, well, it should be at the end of each frame (Mesa knows this and the driver's likely to have a stub for the function called) and when a buffer is really, really close to full (Taken care of by either the driver or the DRM- I'll have to look a little further at the DMA code in the other drivers to get a better idea of who's responsibility it is...). > Is the mga a good example to start to look at? Is the card similar to the > mach64? For the DMA API, perhaps. The RagePRO is an interesting beastie- it doesn't quite work like most of the other cards. Unlike many of the cards that offer DMA support that I've seen, it does scatter-gather operations. This means that we don't need a linear space and we can hand it huge tables of commands (4096 4k pages with a 16k descriptor table- larger descriptor tables are possible...) In some ways, it makes our lives easier, in others it's more interesting. > Another WORK TO DO, is to allow 2D accelerated rendering and 3D at the same > time (actually the 2D acceleration is disabled in the driver). Why must it > be disabled now? What should be done to fix this? Implement the DMA interface, implement proper DRM locking for the DMA pass (and verify that the 2D code is honoring the DRM locks...), and re-code the Mesa layer driver to use the new DMA interface. Implementing the interface code is my current priority as I see it- this way you or someone else can re-work the rest of the code. -- Frank Earl _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
