El Dom 23 Sep 2001 00:28, escribiste:
> On Sat, 22 Sep 2001, Manuel Teira wrote:
> > El Sáb 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 demo
> > runs, showing only garbage on the screen. So, it seems that we should
> > 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 render
> > the figures as good as in software mode (with the software GL library),
> > but with some problems:
> > - There's garbage in the background of the window.
> > - The window is not cleaned for each frame, so, all the shapes are 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, but
> 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 sample
> engine reset code in the programmer's guide mentions setting
> BUS_FIFO_ERR_ACK and BUS_HOST_ERR_ACK in BUS_CNTL (0x00a00000), but the
> 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=BUS_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 Card
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 have
3D acceleration (3D RAGE)
- VTB/GTB/LT. This is strange. Assuming they're talking about VT and GT
models (but the GT model is the same as the GTPro). And what about the LT?
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 = 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 older
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 cards,
they are trying to set the BUS_LAT16X == BUS_HOST_ERR_INT, a read only 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 see how
is it setting up the card, allowing Utah-GLX to work.
> Does anyone know what's going on here?
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
