On Thu, 18 Apr 2002, José Fonseca wrote: [snip]
> I didn't take over the DMA part, but that will eventually happen. For now > I'm moving all register programming from GL driver to the DRM, but faking > DMA at the same time. This will allow to prepare and debug everything very > well making the DMA programming much more straightforward. The downside is > that the DMA-emulation is very slow. > > This is taken a greate deal of changes. I can imagine. It's great that you're starting this effort. > At this moment I'm trying to debug to make things work barely before I'll > make a new branch: mach64-0-0-4-branch. But tommorrow I'll create it > anyway, so that others can help on this work as well - I'm thinking on > Leif, but Frank is welcome to join to and commit whatever he has done so > far. I just don't see point to wait any further for doing this work, as > it's the next logic step to take. I eagerly await the commit message... :) > >> But really nothing prevents someone to work on that subject since it > >> can be made in parallel. Why don't you start work on it instead? I know > >> as much from that subject as you do - almost nothing. I guess that > >> basically what is needed is to see how R128 and Radeon do the 2D accel > >> locking and apply the same. If there is a need of a missing feature on > >> the DRM I'll fill in the missing part as I'm currently working very > >> closely on it. > > > > I think I could start looking into this. However, I have never worked on > > XFree86 or DRI before. The first time (maybe the 2nd) I looked in the > > the sources was when I reported the last bug (Bool not defined). I'm > > also not sure how much time I could spend on it, since I'm quite busy > > with my studies right now. But it could be more relaxed the next 1 and > > 1/2 months. And if I reduce the time I spend "testing" and do something > > useful instead, I might actually get some work done. > > > > Sure. That would be nice. David Bronaugh also volunteered, so you can > coordinate efforts with him. It's always more easy being two. I can provide some background on this, since I played around with the locks back when Manuel was working on this. First off, it'll probably be most productive to work on this on the new branch, when all the register programming and DMA will be in the DRM. However, a good start could be made by investigating and hacking on the current branch too. There are locks in place in aticonsole.c for vt/mode switches (xc/programs/Xserver/hw/xfree86/drivers/ati) and in atimach64.c for the XAA functions. The disabled code to initialize 2D acceleration is in ATIMach64AccelInit() in atimach64.c. I guess the first thing to do is to make sure that the locks are in the right place, and that the 2D driver's state is restored correctly. Currently, if a GL context is active, a vt or mode switch will cause a lockup on returning to the X server (ATIEnterVT and ATISwitchMode). Also dragging a window or other XAA accelerated actions will cause a lockup. These lockups will likely require a reboot, but you may be a able to kill the X server remotely if you're lucky. :) I can say from experience that debugging this can be frustrating and time-consuming. While r128 and radeon driver code can be a useful reference, it's important to realize that they have command engines that are quite different from mach64. At any rate, if anyone is interested in helping out and has the time -- read Jose's developer FAQ, have a look at the code, post questions and results to the list, and try to drop in on the Monday IRC meetings when you get the chance. Any help you can provide would be greatly appreciated. -- Leif Delgass http://www.retinalburn.net _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
