Re: [Dri-devel] Mach64 developers

[Carl B. <afn...@af...>]

Hi all,
I've looked at the documentation, and it's odd, it seems like nobody is 
mentioning the Mach64 GB.  It might be this is simply named wrong in my 
bios, and it seems to run the same as other cards.

Here's my PCI entry: pci bus 0x1 cardnum 0x00 function 0x0000: vendor 
0x1002 device 0x4742 ATI Mach64 GB

This is a All in Wonder model but this may all be irrelevant.

Carl Busjahn

Manuel Teira wrote:

>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
>Dri...@li...
>https://lists.sourceforge.net/lists/listinfo/dri-devel
>