Re: [Dri-devel] radeon driver on current trunk

[Michel <mi...@da...>]

On Mon, 2002-06-17 at 09:58, Keith Whitwell wrote:
> Michel D=E4nzer wrote:
> > I have a couple items to discuss:
> >=20
> > - Keith, some files like radeon_{render,tris,vb}.c can be removed now,
> > right?
>=20
> Oh, yes.  I didn't notice they were still there.

I see you've removed them, thanks.


> > - Portability fixes for the new driver:
> > http://penguinppc.org/~daenzer/DRI/radeon-endianness.diff
> > Feedback and testing appreciated as always, in particular on the change=
s
> > to the x86 specific parts.
>=20
> Looks ok.

So the x86 specific parts don't break?

> The radeon has some COLOR_ORDER_BGRA/RGBA flags, I don't know if=20
> these help your rearrangement,

No, because the 'A' is still in the same wrong place. ;)

> but as you only twiddle ubyte colors and not float ones, there would be
> extra bookkeeping to make it work.

Yep, I'm simply on a crusade against fixed indices in ubyte arrays. :)


> > - Now that the driver has such a great performance (I could hardly
> > believe the glxgears numbers at first, towards 2000 fps! Fabulous work
> > Keith!), I thought sync on vertical blank wouldn't be bad as an option
> > (130-150 fps in bzflag seems like a waste :). The attached patch is a
> > hack to achieve that, it works but is of course horrible with apps wher=
e
> > the maximum framerate is around or below the refresh rate. I guess the
> > best way would be to make this an environment variable option, but that
> > would require a new ioctl, right? Also, radeonWaitForFrameCompletion()
> > should probably sleep instead of just spinning in that case, but the
> > xf86_ansic.h header gets in the way there - does anyone see where that
> > comes in and/or know if it's actually needed (I guess not)?
>=20
> You have to be careful not to block the performance of other applications=
=20
> and/or the x server.  I think this is where we really need to be using=20
> interrupts -- put that client to sleep waiting on an interrupt but allow=20
> others full access to the graphics hardware in the meantime.

True, I'll have a look at that GATOS IRQ code to see if there's anything
useful.

> I guess you're using "EnablePageFlip" -- gears doesn't really benefit fro=
m tcl=20
> as there aren't many vertices - it's really a test of clear & swap speeds=
 now.

Both seem to give about the same boost here, but maybe that's just
because we don't have PPC assembler optimizations yet.


--=20
Earthling Michel D=E4nzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member   /  CS student, Free Software enthusiast