Re: [utah-glx-dev] I am interested in getting the ATI Rage Pro's working.

[Robert L. <bo...@ya...>]

On Tue, 25 Feb 2003 04:55, Frank Earl wrote:
> On Wednesday 19 February 2003 07:53 am, Robert Lunnon wrote:
> > Yes, what I thought too and It may well be the driver code, once I found
> > out how non-capable the Rage IIC was anyway, and after Phil kindly
> > shipped me a matrox to play with instead, I dropped that project and
> > picked up the mga which now goes OK.
>
> This sounds familiar.  A developer from Loki Games ended up shipping me a
> G400 to fix some of thier woes with Utah-GLX and the G400...
>
> > One problem with the Mach64 driver was that it was left in a non-working
> > state by it's previous maintainer.
>
> Uh, you're talking with the previous maintainer and it was working fine
> with most of the RagePRO chips (which is what it was really designed for)
> out there to the best of my knowlege (I know, I was using it for some time
> before trying to make a go of the DRI version of the driver).  Reading all
> of what you said you did, you got bit by the move to XF 4.X...
>

Frank, In my recollection when I initially started there was some code in 
there that did not even compile that needed to be sorted out. It looked like 
some work in progress was abandoned at some point. It was a while ago so I 
might be mistaken. Given the time between the development of Utah, on XF3 and 
our port to XF4 (About the time XF4.2 came out) there may have been others 
that played with the code (Don't really know). It's not important, the driver 
is a large portion of the way there if the DMA problem could be overcome.


> > I did my best to clean it up, but
> > probably should have done that in XF3 where it was known to work at some
> > time in the past and then ported it to XF4.
>
> Well, I have an answer for you.  The RagePRO DMA code _will_not_work_ with
> the current register settings set by the XF 4.X driver module.  The module
> sets up a larger FIFO and confuses the hell out of the silicon.  We
> couldn't get DMA to work to save our lives while working on the DRI driver
> until we figured out that one.  We ended up forcing the FIFO setting back
> to the "stock" one and doing a soft reset on the chip to make it behave
> itself on DMA.
>

I located the discussion thread on DRI about this and tried to deploy that fix  
but didn't have a lot of success there either (Least on a rage IIC)

> > MMIO works but Utah-Glx design falls back to software rendering when the
> > DMA engine testing fails
>
> It should have a degenerate mode called PDMA (at least it did when I was
> maintaining it)- should be mode 1, if memory serves.  PDMA is MMIO and it
> should be sort-of accelerated when you do this.

OK, I didn't realise this.... This will be useful to progress the port without 
needing to make DMA work. I would need to check that the changes I made don't 
preclude this though. I wouldn't expect so.

Bob