Direct Rendering Infrastructure

On Thu, 2001-11-29 at 19:12, Derrik Pates wrote:
> I have an iBook running Linux, with BenH's 2.4.16-ben0 kernel, and=20
> Debian XFree packages (with one minor hack to get line width right). The=20
> UniNorth AGPGART seems to be working, and I'm able to successfully do=20
> DRI (all the GL XScreenSaver hacks work, glxgears works, glxinfo says=20
> direct rendering is enabled).

agpgart is really stable for you? Most things like glxgears work fine on
my Pismo with it, but a few other things like tuxracer reliably lock up.

> However, some of the XScreenSaver GL hacks, when they end, leave the mous=
e
> pointer in a weird state - as an (approx.) 64x64 box, with what looks
> like ~24 lines inverting, ~24 lines transparent, then ~8 lines
> inverting.

Never seen that. Or heard of it, for that matter. :)

Sounds like the hardware cursor image gets overwritten, maybe an
offscreen memory glitch or related to agpgart?

> Other than that, it works quite well, though the frame rate seems a
> bit on the low side (~190 fps according to glxgears).

That's too low indeed. I get ~350 without agpgart and almost 500 with
it. (Or is your CPU slower than 300 MHz?)

Are you running a 'complex' window manager like Enlightenment or any 2D
clients at the same time? If yes, the context switching overhead might
explain this. That will be better with current CVS and 4.2.0.

> Also, I'm still seeing the bleedthrough effect that had been mentioned on
> this list previously with Rage128 DRI support - is there a fix in CVS
> that eliminates this problem? Maybe lined up for the upcoming 4.2.0
> release? :)

You mean the 'meltdown' effect, which is a symptom of the chip hanging
up? Yep, that might be better too. Sounds like you should try current
CVS, eh? :)


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

Michel Dänzer wrote:

> agpgart is really stable for you? Most things like glxgears work fine on
> my Pismo with it, but a few other things like tuxracer reliably lock up.


Haven't tried anything like TuxRacer yet. Don't know what kind of effect 
that will have on it.

> Never seen that. Or heard of it, for that matter. :)
> 
> Sounds like the hardware cursor image gets overwritten, maybe an

> offscreen memory glitch or related to agpgart?


That was my general guess, but I don't know how to fix it... :)

> That's too low indeed. I get ~350 without agpgart and almost 500 with
> it. (Or is your CPU slower than 300 MHz?)


It's a 366 MHz G3 processor.

> Are you running a 'complex' window manager like Enlightenment or any 2D
> clients at the same time? If yes, the context switching overhead might
> explain this. That will be better with current CVS and 4.2.0.


I'm running WindowMaker 0.70.0, with some dock.apps, but nothing 
particularly complex.

> You mean the 'meltdown' effect, which is a symptom of the chip hanging
> up? Yep, that might be better too. Sounds like you should try current
> CVS, eh? :)


No, I mean when you run two simultaneous GL clients, and one window lays 
over the other, some of the drawn surfaces for the bottom client show 
through in the top client's window.

Derrik Pates
dpates@...

Michel Dänzer wrote:

> Sounds like the hardware cursor image gets overwritten, maybe an
> offscreen memory glitch or related to agpgart?

Just realized, it's not related to AGPGART, because I see the same thing 
when I set the "ForcePCIMode" option. (Also, I see it at both 16bpp and 
24bpp depths - 24bpp works for me, yes.)

Derrik Pates
dpates@...

> However, some of the XScreenSaver GL 
> hacks, when they end, leave the mouse pointer in a weird state - as an 
> (approx.) 64x64 box, with what looks like ~24 lines inverting, ~24 lines 
> transparent, then ~8 lines inverting. 

Hmmz, is dit related with (one of the) bugs i'm getting with the mach64
branch? It also seems like a 64x64 box with weird lines in it, but not
only after a hack but also sometimes during one...

Ohwell, i've recieved register documentation from ATI, zo i'll see if i
can fix some code this weekend. Does anyone have the mach64 programming
guide, might help a bit :)

greetings,
Alex de Landgraaf

Alex de Landgraaf wrote:

> Ohwell, i've recieved register documentation from ATI, zo i'll see if i
> can fix some code this weekend. Does anyone have the mach64 programming
> guide, might help a bit :)


Except the chip isn't a Mach64, it's a Rage Mobility M3 (Rage128 
derivative).

Derrik Pates
dpates@...

On Thu, 2001-11-29 at 21:00, Derrik Pates wrote:
> Michel D=E4nzer wrote:
>=20
> > That's too low indeed. I get ~350 without agpgart and almost 500 with
> > it. (Or is your CPU slower than 300 MHz?)
>=20
> It's a 366 MHz G3 processor.

So you should be able to achieve higher numbers. I'd expect somewhere
between 300 and 400 fps.

> > Are you running a 'complex' window manager like Enlightenment or any 2D
> > clients at the same time? If yes, the context switching overhead might
> > explain this. That will be better with current CVS and 4.2.0.
>=20
> I'm running WindowMaker 0.70.0, with some dock.apps, but nothing=20
> particularly complex.

Something which draws regularly (system status monitor, ...) could be
enough. The driver used to shut down the CCE for 2D operations and
restart it again afterwards.


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

On 30 Nov 2001, Michel D=E4nzer wrote:

> So you should be able to achieve higher numbers. I'd expect somewhere
> between 300 and 400 fps.

Got me. I am trying a CVS build of XFree (4.1.99.1), and the framerate is
slightly better - glxgears gets generally closer to 200 fps, and TuxRacer
averages 8-9 fps (versus ~6 with 4.1.0.1 from Debian). It is using the
AGPGART, and I even tried switching it to AGP 2x mode (the X server log
claims it's running at 2x anyway).

> Something which draws regularly (system status monitor, ...) could be
> enough. The driver used to shut down the CCE for 2D operations and
> restart it again afterwards.

I did try killing all the dock.apps, and that pushed it up a little, to
about 220 fps. Not a huge gain.

Also, can I get you to add a fix for the Rage128 line width problem into
the ATI driver? I'd really like to see the fix added (it's one line,
changing one value) before the current CVS HEAD becomes 4.2.0.

Derrik Pates      |   Sysadmin, Douglas School   |    #linuxOS on EFnet
dpates@... |     District (dsdk12.net)    |    #linuxOS on OPN

On Fri, 2001-11-30 at 08:19, Derrik Pates wrote:

> Also, can I get you to add a fix for the Rage128 line width problem into
> the ATI driver? I'd really like to see the fix added (it's one line,
> changing one value) before the current CVS HEAD becomes 4.2.0.

I'll see to it that it gets fixed, but I'd like to check the docs for
what the value should really be. I hope I'll get around to it this
weekend.


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

On 30 Nov 2001, Michel D=E4nzer wrote:

> I'll see to it that it gets fixed, but I'd like to check the docs for
> what the value should really be. I hope I'll get around to it this
> weekend.

Well, the tdfx driver uses 16 * pScrn->bitsPerPixel, and that's the value
I've been using. 64 * pScrn->bitsPerPixel obviously can't be right,
it's why the X server wants a row with of 832 on this iBook, requiring you
to jump through weird hoops to force it into doing the right thing. 32 *
pScrn->bitsPerPixel should also work, unless I'm just not thinking of any
"unusual" dimension modes that would require 16-pixel resolution to get
the right line width.

I'm actually surprised it's not just standardized across all the drivers.

Derrik Pates      |   Sysadmin, Douglas School   |    #linuxOS on EFnet
dpates@... |     District (dsdk12.net)    |    #linuxOS on OPN

On Fri, 2001-11-30 at 09:48, Derrik Pates wrote:
> On 30 Nov 2001, Michel D=E4nzer wrote:
>=20
> > I'll see to it that it gets fixed, but I'd like to check the docs for
> > what the value should really be. I hope I'll get around to it this
> > weekend.
>=20
> Well, the tdfx driver uses 16 * pScrn->bitsPerPixel, and that's the value
> I've been using. 64 * pScrn->bitsPerPixel obviously can't be right,
> it's why the X server wants a row with of 832 on this iBook, requiring yo=
u
> to jump through weird hoops to force it into doing the right thing. 32 *
> pScrn->bitsPerPixel should also work, unless I'm just not thinking of any
> "unusual" dimension modes that would require 16-pixel resolution to get
> the right line width.
>=20
> I'm actually surprised it's not just standardized across all the drivers.

If all drivers were supposed to use the same value, why would it have to
be passed to the function at all? I assume it's hardware specific. I'll
look it up in the docs.


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

>Got me. I am trying a CVS build of XFree (4.1.99.1), and the framerate is
>slightly better - glxgears gets generally closer to 200 fps, and TuxRacer
>averages 8-9 fps (versus ~6 with 4.1.0.1 from Debian). It is using the
>
>AGPGART, and I even tried switching it to AGP 2x mode (the X server log
>claims it's running at 2x anyway).

Your numbers make me think that while your X server might be enabling
DRI & AGP, for some reason, you are still using software rendering, that
is probably because of a software only mesa library on your system.

Ben.

On Fri, 2001-11-30 at 10:30, Benjamin Herrenschmidt wrote:
> >Got me. I am trying a CVS build of XFree (4.1.99.1), and the framerate i=
s
> >slightly better - glxgears gets generally closer to 200 fps, and TuxRace=
r
> >averages 8-9 fps (versus ~6 with 4.1.0.1 from Debian). It is using the
> >
> >AGPGART, and I even tried switching it to AGP 2x mode (the X server log
> >claims it's running at 2x anyway).
>=20
> Your numbers make me think that while your X server might be enabling
> DRI & AGP, for some reason, you are still using software rendering, that
> is probably because of a software only mesa library on your system.

I don't know, the numbers seem a bit high for software rendering. :)
This Athlon 800 only achieves 190 fps in glxgears with software
rendering...

I guess the iBook is slow, with the lower bus clock and all.


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

On Fri, Nov 30, 2001 at 01:48:16AM -0700, Derrik Pates wrote:
> On 30 Nov 2001, Michel D=E4nzer wrote:
>=20
> > I'll see to it that it gets fixed, but I'd like to check the docs for
> > what the value should really be. I hope I'll get around to it this
> > weekend.
>=20
> Well, the tdfx driver uses 16 * pScrn->bitsPerPixel, and that's the val=
ue
> I've been using. 64 * pScrn->bitsPerPixel obviously can't be right,
> it's why the X server wants a row with of 832 on this iBook, requiring =
you
> to jump through weird hoops to force it into doing the right thing. 32 =
*
> pScrn->bitsPerPixel should also work, unless I'm just not thinking of a=
ny
> "unusual" dimension modes that would require 16-pixel resolution to get
> the right line width.
>=20
> I'm actually surprised it's not just standardized across all the driver=
s.

If I remember correctly, the hardware requires pitches to be multiples
of 64 (that's pixels, not bytes).  It's been a while, but we don't do
that sort of thing for nothing...

-- Gareth

Thats why its so weird! :)

On Thu, 2001-11-29 at 22:56, Derrik Pates wrote:
> Alex de Landgraaf wrote:
> 
> > Ohwell, i've recieved register documentation from ATI, zo i'll see if i
> > can fix some code this weekend. Does anyone have the mach64 programming
> > guide, might help a bit :)
> 
> 
> Except the chip isn't a Mach64, it's a Rage Mobility M3 (Rage128 
> derivative).
> 
> Derrik Pates
> dpates@...
> 
>

On 29 Nov 2001, Alex de Landgraaf wrote:

> > However, some of the XScreenSaver GL 
> > hacks, when they end, leave the mouse pointer in a weird state - as an 
> > (approx.) 64x64 box, with what looks like ~24 lines inverting, ~24 lines 
> > transparent, then ~8 lines inverting. 
> 
> Hmmz, is dit related with (one of the) bugs i'm getting with the mach64
> branch? It also seems like a 64x64 box with weird lines in it, but not
> only after a hack but also sometimes during one...

I've seen this happen with mach64 also, but I don't remember the exact 
circumstances at the moment.

> Ohwell, i've recieved register documentation from ATI, zo i'll see if i
> can fix some code this weekend. Does anyone have the mach64 programming
> guide, might help a bit :)

If you have the register doc, you should also have access to the 
programmer's guide at the same URL they gave you for the register doc 
(minus the filename).  They forgot to mention that to me too when I got 
the register doc.

-- 
Leif Delgass 
http://www.retinalburn.net

On Fri, 30 Nov 2001, Benjamin Herrenschmidt wrote:

> Your numbers make me think that while your X server might be enabling
> DRI & AGP, for some reason, you are still using software rendering, that
> is probably because of a software only mesa library on your system.

'glxinfo' claimed that direct rendering was working. I just ran glxgears
in software mode (just had to reboot this iBook, wrong DRM got loaded, I'm
using XFree CVS), and I only get 57 fps. So it looks like DRI is sort of
working.

Derrik Pates      |   Sysadmin, Douglas School   |    #linuxOS on EFnet
dpates@... |     District (dsdk12.net)    |    #linuxOS on OPN

On Fri, 30 Nov 2001, Gareth Hughes wrote:

> If I remember correctly, the hardware requires pitches to be multiples
> of 64 (that's pixels, not bytes).  It's been a while, but we don't do
> that sort of thing for nothing...

Well, how would an 800x600 display work on it then? The iBook's display is
800x600, and as it works now (the 64 X pScrn->bitsPerPixel value) the X
server always gets the wrong line pitch (832) because 800 is not a round
multiple of 64. With the existing code, the X server has to be forced into
doing the "right" thing. With my change, it does the right thing
completely by itself.

I don't have the Rage128 docs, I can only tell you what I'm seeing here -
and that's what I'm seeing. If the docs claim that the line pitch must be
a multiple of 64 pixels, maybe the docs are incorrect. (Would it be the
first time?)

Derrik Pates      |   Sysadmin, Douglas School   |    #linuxOS on EFnet
dpates@... |     District (dsdk12.net)    |    #linuxOS on OPN

On Fri, 2001-11-30 at 17:17, Derrik Pates wrote:
> On Fri, 30 Nov 2001, Gareth Hughes wrote:
>=20
> > If I remember correctly, the hardware requires pitches to be multiples
> > of 64 (that's pixels, not bytes).  It's been a while, but we don't do
> > that sort of thing for nothing...
>=20
> Well, how would an 800x600 display work on it then? The iBook's display i=
s
> 800x600, and as it works now (the 64 X pScrn->bitsPerPixel value) the X
> server always gets the wrong line pitch (832) because 800 is not a round
> multiple of 64. With the existing code, the X server has to be forced int=
o
> doing the "right" thing. With my change, it does the right thing
> completely by itself.

horizontal resolution !=3D line pitch


> I don't have the Rage128 docs, I can only tell you what I'm seeing here -
> and that's what I'm seeing. If the docs claim that the line pitch must be
> a multiple of 64 pixels, maybe the docs are incorrect. (Would it be the
> first time?)

Probably not, still I suspect your change doesn't address the real
problem. I think the problem is that the r128 driver doesn't use the
same pitch as aty128fb. Your change just happens to make it use the same
one.

Maybe the slowness and cursor problems you experience are related to
your not using a multiple of 64 for the pitch?


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

On Fri, Nov 30, 2001 at 09:17:07AM -0700, Derrik Pates wrote:
> On Fri, 30 Nov 2001, Gareth Hughes wrote:
> 
> > If I remember correctly, the hardware requires pitches to be multiples
> > of 64 (that's pixels, not bytes).  It's been a while, but we don't do
> > that sort of thing for nothing...
> 
> Well, how would an 800x600 display work on it then? The iBook's display is
> 800x600, and as it works now (the 64 X pScrn->bitsPerPixel value) the X
> server always gets the wrong line pitch (832) because 800 is not a round
> multiple of 64. With the existing code, the X server has to be forced into
> doing the "right" thing. With my change, it does the right thing
> completely by itself.
> 
> I don't have the Rage128 docs, I can only tell you what I'm seeing here -
> and that's what I'm seeing. If the docs claim that the line pitch must be
> a multiple of 64 pixels, maybe the docs are incorrect. (Would it be the
> first time?)

I'm not familiar with your problem, or your proposed fix.

Two things, however:

1) These pitches may have nothing to do with the current mode.  Mode
   initialization probably touches different registers.

2) If the pitch register looks like this, say:

	Bits		Field

	0 - 12		Pitch, in multiples of 64 pixels
	...		...

(and I seem to remember that all the ATI cards look like this), then
there is no way to program a pitch that *isn't* a multiple of 64
pixels.  Hence:

	/* Offset in multiples of some large number.  Radeon has
	 * 4k alignment, from memory -- something large in any case.
	 */
	hw_offset = real_offset / 4096;

	/* Pitch in multiples of 64 pixels.
	 */
	hw_pitch = real_pitch / 64;

	reg.src_pitch_offset = ((hw_pitch  <<  0) |
			        (hw_offset << 12));

Of course, it's been almost a year since I worked on that part of the
driver, so I may be completely wrong.

Note that even though a surface is allocated with a pitch that is a
multiple of 64 pixels (832 in this case), the RAMDAC may only scan out
the first 800 pixels or whatever the current mode is set to.

-- Gareth

On 30 Nov 2001, Michel D=E4nzer wrote:

> horizontal resolution !=3D line pitch

This driver certainly seems to think it should be.

> Probably not, still I suspect your change doesn't address the real
> problem. I think the problem is that the r128 driver doesn't use the
> same pitch as aty128fb. Your change just happens to make it use the same
> one.

Well, when XFree worked without "UseFBDev" on PPC (the current Debian
builds do not), I saw the same problem - if you don't force it to use the
right mode, you get a "stair-stepping" effect, where 32 pixels of each
line wrap around to the next line.

Derrik Pates      |   Sysadmin, Douglas School   |    #linuxOS on EFnet
dpates@... |     District (dsdk12.net)    |    #linuxOS on OPN

On Fri, 30 Nov 2001, Gareth Hughes wrote:

> 1) These pitches may have nothing to do with the current mode.  Mode
>    initialization probably touches different registers.

If this is the case, then something in the driver is assuming that line
width and the number of pixels per line should be equivalent - I get a
"stair-stepping" effect where the end of each line wraps down to the next,
producing an unusable display, unless you force the video mode. If my
solution to the problem is the wrong one, I'd certainly like to see the
right one, whatever it is, implemented.

Derrik Pates      |   Sysadmin, Douglas School   |    #linuxOS on EFnet
dpates@... |     District (dsdk12.net)    |    #linuxOS on OPN

On Fri, 2001-11-30 at 17:46, Derrik Pates wrote:
> On 30 Nov 2001, Michel D=E4nzer wrote:
>=20
> > horizontal resolution !=3D line pitch
>=20
> This driver certainly seems to think it should be.

That might be the bug then; maybe it's using the width where it should
use the pitch or vice versa.


What still irritates me is that the pitch seems to be connected to the
mode in reality whereas it shouldn't be in thery (right?)...


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

On 30 Nov 2001, Michel D=E4nzer wrote:

> That might be the bug then; maybe it's using the width where it should
> use the pitch or vice versa.

Sounds more like the reverse - something's using the pitch where it should
be using the actual width.

> What still irritates me is that the pitch seems to be connected to the
> mode in reality whereas it shouldn't be in thery (right?)...

Sounds like an accurate summary to me.

Derrik Pates      |   Sysadmin, Douglas School   |    #linuxOS on EFnet
dpates@... |     District (dsdk12.net)    |    #linuxOS on OPN

Derrik,

the Rage128 register reference says the pitch must be a multiple of 64
bytes, so the code really seems to be wrong. The pitchInc value should
be 8 * 64.

And indeed this works for me, except for depth 8. Something obviously
can't handle the pitch not being virtualX*bitPerPixel/8, but I scanned
the driver for pitch, virtualX and displayWidth and didn't find any
obvious mistakes.

I'll submit a patch for this anyway.


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