On Thu, May 30, 2002 at 02:32:10PM +0100, Alan Hourihane wrote:
> On Thu, May 30, 2002 at 02:21:42PM +0100, Michael wrote:
> > On Thu, May 30, 2002 at 01:59:31PM +0100, Keith Whitwell wrote:
> > > Michael wrote:
> > > >On Thu, May 30, 2002 at 12:59:23PM +0100, Keith Whitwell wrote:
> > > >
> > > >>So, I've been writing a sanity checker for the radeon dma stream.  All 
> > > >>going nicely & found one stupid bug already.
> > > >>
> > > >
> > > >I'm struggling to see what the dyslexic bug is? It just looked like one of
> > > >the header files was wrong (but if you emit state from 0x1c4c onwards it
> > > >wouldn't have mattered anyway?)
> > > >
> > > >Unless I'm being loopy, the kernel (that's now emitting SE_COORD_FMT
> > > >directly) is using the header that has the value as 0x1c50 not 0x15c0
> > > >which would have been happening anyway (and looks like the right value
> > > >because 0x15c0 is something for 2d colour compare)
> > > 
> > > The previous version emitted SE_CNTL and SE_COORD_FMT as if they were 
> > > contiguous.
> > > 
> > > #define RADEON_SE_CNTL                      0x1c4c
> > > #define RADEON_SE_COORD_FMT                 0x15c0
> > > 
> > > ... they aren't ...
> > 
> > Yeah, drivers/ati/radeon_reg.h says that, but the kernel uses
> > radeon_drv.h, which has 0x1c50?
> > 
> > So you're still emitting to 0x1c50, which is either fine and it always
> > has been, or it's still buggy.
> 
> 0x1C50 is correct for RADEON_SE_COORD_FMT.

And, I've changed this in the XFree86 tree.  It will be checked in when
I finish my current work.

Still working on the Radeon 2D code...
Kevin

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to