From: Manuel T. <man...@so...> - 2001-09-22 23:45:37
|
El Dom 23 Sep 2001 00:28, escribiste: > On Sat, 22 Sep 2001, Manuel Teira wrote: > > El S=E1b 22 Sep 2001 19:08, escribiste: > > And now, the results: > > > > 1.-When the new bm_dma_test is called from the dma_init it fails as = ever. > > Then, if I try to run the 'gears' demo, it hangs the machine. > > 2.-When the bm_dma_test is called from the dma_cleanout, the gears d= emo > > runs, showing only garbage on the screen. So, it seems that we shoul= d > > blame the DMA test for the locks. > > 3.-Finally, and in the same environment than (2), I've tried to run = the > > isosurf demo. Against all the bets, it worked. Well, it's able to re= nder > > the figures as good as in software mode (with the software GL librar= y), > > but with some problems: > > =09- There's garbage in the background of the window. > > =09- The window is not cleaned for each frame, so, all the shapes ar= e mixed > > on the screen after some key strokes. > > I've tried out the changes and I got the same results with glxheads. = The > garbage in the background for me is part of the KDE splash screen and = part > of my desktop background. Again, the shapes are drawn and rotated, bu= t > the window is not cleared for each frame. Exactly the same I'm experimenting (part of the KDE splash screen). > > I'm a bit confused about something in the engine reset code. The samp= le > engine reset code in the programmer's guide mentions setting > BUS_FIFO_ERR_ACK and BUS_HOST_ERR_ACK in BUS_CNTL (0x00a00000), but th= e > register guide shows these bits as BUS_MSTR_RD_LINE and LAT16X > respectively, with LAT16X being read-only. The 2D driver (atiregs.h) = has > these defines: > > #define BUS_FIFO_ERR_INT_EN 0x00100000ul > #define BUS_MSTR_RD_MULT 0x00100000ul /* VTB/GTB/LT = */ > #define BUS_FIFO_ERR_INT 0x00200000ul > #define BUS_MSTR_RD_LINE 0x00200000ul /* VTB/GTB/LT = */ > #define BUS_HOST_ERR_INT_EN 0x00400000ul > #define BUS_SUSPEND 0x00400000ul /* GTPro */ > #define BUS_HOST_ERR_INT 0x00800000ul > #define BUS_LAT16X 0x00800000ul /* GTPro */ > Yes, it's really weird. Comparing the Programmers Guide and the Register= 's Reference guide, I see the following: iow32(BUS_CNTL,(ior32(BUS_CNTL)|0x00a00000)) and after reading the Register Reference Guide, 0x00a00000=3DBUS_MSTR_RD_LINE | BUS_LAT16X while in the Programmers Guide, they are talking about setting: BUS_FIFO_ERR_ACK@BUS_CNTL and BUS_HOST_ERR_ACK@BUS_CNTL. It seems that the register bits have different meanings regarding the Ca= rd Model, as you can see in the define comments. Anyway, it's not clear for= me: - GTPro. I assume, they're talking about a GT Model (Rage I, RageII, II+= , IIC, Rage PRO). If we trust the Mach64 Programmers Guide, these models h= ave 3D acceleration (3D RAGE) - VTB/GTB/LT. This is strange. Assuming they're talking about VT and G= T models (but the GT model is the same as the GTPro). And what about the L= T? Perhaps a RAGE LT-Pro (actually a LB/GM model). > ..and there is code like this in atiprobe.c: > > /* Make sure any Mach64 is not in some weird state */ > bus_cntl =3D inr(BUS_CNTL); > if (Chip < ATI_CHIP_264VTB) > outr(BUS_CNTL, > (bus_cntl & ~(BUS_HOST_ERR_INT_EN | BUS_FIFO_ERR_INT_EN))= | > (BUS_HOST_ERR_INT | BUS_FIFO_ERR_INT)); > else > outr(BUS_CNTL, (bus_cntl & ~BUS_HOST_ERR_INT_EN) | > BUS_HOST_ERR_INT); > After reading this, I suppose that with GTPro they're talking about an o= lder model than the VT, that is, a Mach64GX Family model (if Chip < ATI_CHIP_264VTB) . And there's something wrong, assuming that the 'else' is for the GTPro c= ards, they are trying to set the BUS_LAT16X =3D=3D BUS_HOST_ERR_INT, a read on= ly bit in the BUS_CNTL register. Perhaps the Register Reference is not updated or have some bugs. I don't= know. Could be a good idea to take a look at the XFree 3.x version to se= e how is it setting up the card, allowing Utah-GLX to work. > Does anyone know what's going on here? |