El Sáb 27 Oct 2001 18:49, Leif Delgass escribió: > First off, I messed up on the FIFO size defines in mach64_drv.h (drm > kernel module), they should be: > > # define MACH64_CMDFIFO_SIZE_MASK 0x00000003ul > # define MACH64_CMDFIFO_SIZE_192 0x00000000ul > # define MACH64_CMDFIFO_SIZE_128 0x00000001ul > # define MACH64_CMDFIFO_SIZE_64 0x00000002ul > > I was mixing up my hex and binary, yikes! (at least 1 is always 1 so no > harm done) Embarassing. Don't drink and code. Anyway...
:-) Fixed. > > > > Well. I've written a pair of macros to interlock drm and Xdriver and > > > used it in all the accelerated access from the XDriver. I've also used > > > the DRILock/DRIUnlock API to lock the ATILeaveVT and ATIEnterVT in the > > > aticonsole.c file. After this, we cannot enable 2D accelerated > > > rendering yet, because the drm and mesa sides are not honouring this > > > interlocking. This should be made when Frank has the new DMA API > > > finished, because the points to lock will be less than now (I suppose > > > that we only will need to lock the actual DMA transfers) because the > > > DMAOUTREG is only going to append the register writes to a DMA buffer. > > > So, I suppose that the EnterVT/LeaveVT bug is still here, because of a > > > non locking DRM. > > What about mode switches? The mga and i810 drivers use DRILock/DRIUnlock > in the ModeInit functions, and the r128/radeon drivers have a comment that > says: > > /* FIXME? DRILock/DRIUnlock here? */ I don't know if it's necessary. Perhaps we could try to change the screen mode while running gears or Quake3. If the machine locks, then, it'll be necessary. ;-) > > > > Anyway, I tried to reenable 2D acceleration and run gears. The engine > > > locked after trying to close gears, but the cursor still worked. > > > > > > My idea is updating the branch with this changes (still without > > > reenabling the 2D acceleration) and Leif ones for the AGP corrections. > > > Leif, I've (#ifdef)ed the AGP code as you told me, but I think that > > > your host.def changes are good for the mach64 branch (disabling the > > > Glide dependencies and enabling builds of DRM drivers) and I plan > > > update it too. > > > > > > Another secondary issue: I'm still have a problem compiling the branch: > > > The xf86cfg directory in programs/Xserver/hw/xfree86 needs a lot of > > > shared libraries and I think that there is no need to build this > > > utilities in the DRI context. So, I'm also going to add another change > > > to the host.def file: > > > > > > -#define BuildXFree86ConfigTools YES > > > +#define BuildXFree86ConfigTools NO > > > > > > In this way, the Imakefile in programs/Xserver/hw/xfree86 will disable > > > this tools build: > > > ... > > > #if !BuildServersOnly || BuildXFree86ConfigTools > > > XF86CFGDIRS = xf86cfg xf86config > > > #endif > > > ... > > > > > > and we will need less libraries. > > > > > > Finally, and to accelerate the build, the line: > > > > > > #define XF86CardDrivers tdfx i810 mga ati glint vga > > > > > > should be: > > > > > > #define XF86CardDrivers ati > > > > > > And perhaps: > > > > > > #define XFree86CustomVersion "DRI trunk" > > > > > > should be replaced by: > > > > > > #define XFree86CustomVersion "DRI mach64 branch" > > > > > > > > > Do you agree ? > > I think these changes are fine for the branch, it should speed up the > build. We'll just need to make sure not to merge them to the trunk when > the time comes. Well, I think that we (or whoever that do it) don't even try to merge our host.def to the main trunk, it has nosense. I think that I will update the CVS branch this night. There aren't very important changes, but I think that it's better to have the branch as updated as possible. _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
