r128 DRI driver now fully functional on PPC

r128 DRI driver now fully functional on PPC

[Gareth Hughes]

I've just committed the last of the updates required to get full hardware
accelerated 3D rendering with the ATI Rage 128 on PowerPC.  Many thanks to Paul
Mackerras for allowing me to hack away on his machine over the last week!

The code is available on the ati-pcigart-0-0-1-branch in the DRI CVS
repository.  Please feel free to check it out and report any problems you have.

Now all we need is a PPC Linux build of Q3A...

-- Gareth

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: r128 DRI driver now fully functional on PPC

[Benjamin Herrenschmidt]

>
>I've just committed the last of the updates required to get full hardware
>accelerated 3D rendering with the ATI Rage 128 on PowerPC.  Many thanks
>to Paul
>Mackerras for allowing me to hack away on his machine over the last week!
>
>The code is available on the ati-pcigart-0-0-1-branch in the DRI CVS
>repository.  Please feel free to check it out and report any problems you
>have.

I've done a first try and encountered a show-stopper (on this machine).
The machine is a PowerBook G3 with a r128 M3 (mobility), 8Mb video mem.
The issues are:

 - DRI support works only in 16 and 24/32 bits. However, 16 bits is
broken with UseFBDev and I can't use it without fbdev (see below). The
colors are screwed up (but the server works. I didn't yet try 3D since I
have not yet compiled a GL app to test with). 15 bits works fine with the
kernel driver but it's unuspported for DRI.
I beleive the aty128fb kernel driver need to be fixed for 16 bits.

 - I can't use 32 bits (it needs 9.4Mb of VRAM, I have only 8)

 - If I try to use the r128 driver without UseFBDev, the ATI chip locks
up (the LCD loose sync, the machine is hard locked up). This used to work
with earlier 4.0.1 servers, we need to figure out what changed. That
match what other people already noticed.

I'll do some tests with the broken 16 bits mode to see if I get 3D
working properly. I'll then see if I can figure out what cause the chip
to lockup without UseFBDev.

Except for those (minor hopefully) issues, its a nice work ;)

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [linux-fbdev] Re: r128 DRI driver now fully functional on PPC

[Andreas Hundt]

[-- Attachment #1: Type: text/plain, Size: 1395 bytes --]

Benjamin Herrenschmidt wrote:

> >
> >I've just committed the last of the updates required to get full hardware
> >accelerated 3D rendering with the ATI Rage 128 on PowerPC.  Many thanks
> >to Paul
> >Mackerras for allowing me to hack away on his machine over the last week!
> >
> >The code is available on the ati-pcigart-0-0-1-branch in the DRI CVS
> >repository.  Please feel free to check it out and report any problems you
> >have.
>
> I've done a first try and encountered a show-stopper (on this machine).
> The machine is a PowerBook G3 with a r128 M3 (mobility), 8Mb video mem.
> The issues are:
>
>  - DRI support works only in 16 and 24/32 bits. However, 16 bits is
> broken with UseFBDev and I can't use it without fbdev (see below). The
> colors are screwed up (but the server works. I didn't yet try 3D since I
> have not yet compiled a GL app to test with). 15 bits works fine with the
> kernel driver but it's unuspported for DRI.
> I beleive the aty128fb kernel driver need to be fixed for 16 bits.
>

I fixed this ages ago (screwed up colors and 16 bit support).
Read the README for details. thanks.

--
Andreas Hundt                              andi@convergence.de
Convergence Integrated Media GmbH          http://www.convergence.de
Rosenthaler Str. 51                        fon: +49(0)30-72 62 06 50
D-10178 Berlin                             fax: +49(0)30-72 62 06 55




[-- Attachment #2: README.atyfb_patch_2.4.0-andi --]
[-- Type: text/plain, Size: 1186 bytes --]


Hi,

this patch is for linux-2.4.0-test12-pre4,
I included the full source file if you cannot use the patch.

It would be great if this patch would be included in the mainstream kernel.

Apply this patch this way:

1. copy it to linux/drivers/video/
2. change to that directory
3. type "patch -p0 < aty128fb_patch_2.4.0-andi"

--------------------------------------------------------------------
README:


This patch fixes/changes the following:

- driver now supports RGB565 16-bit mode

- pannig works now, allows correct dublebuffering, without jittering screen.

- FB_ACTIVATE_NOW and FB_ACTIVATE_VBL are now supported, CRTC_OFFSET_CNTL
  register is set correctly. aty128fb only accepted FB_ACTIVATE_NOW before
  but acted always like FB_ACTIVATE_VBL.
  This fix eliminates flickering in ClanLib (and other fbdev applications)
  when using doublebuffering.

- no more messed up colors in modes > 8 bpp. driver no longer uses hardware
  palette in modes > 8bpp, sets fbcon palette correctly instead.

- removed powerpc mmio endian conversion, since it is already done by
  readl() and writel() kernel functions

without this patch games like ClanBomber are a mess and unplayable.


[-- Attachment #3: aty128fb_patch_2.4.0-andi --]
[-- Type: text/plain, Size: 5959 bytes --]

--- aty128fb.c.orig	Mon Dec  4 17:30:03 2000
+++ aty128fb.c	Sat Dec  9 01:15:19 2000
@@ -432,36 +432,18 @@
 };
 #endif /* CONFIG_PMAC_BACKLIGHT */

-    /*
-     * Functions to read from/write to the mmio registers
-     *	- endian conversions may possibly be avoided by
-     *    using the other register aperture. TODO.
-     */
 static inline u32
 _aty_ld_le32(volatile unsigned int regindex,
                               const struct fb_info_aty128 *info)
 {
-    u32 val;
-
-#if defined(__powerpc__)
-    asm("lwbrx %0,%1,%2;eieio" : "=r"(val) : "b"(regindex), "r"(info->regbase));
-#else
-    val = readl (info->regbase + regindex);
-#endif
-
-    return val;
+    return  readl (info->regbase + regindex);
 }

 static inline void
 _aty_st_le32(volatile unsigned int regindex, u32 val,
                                const struct fb_info_aty128 *info)
 {
-#if defined(__powerpc__)
-    asm("stwbrx %0,%1,%2;eieio" : : "r"(val), "b"(regindex),
-                "r"(info->regbase) : "memory");
-#else
     writel (val, info->regbase + regindex);
-#endif
 }

 static inline u8
@@ -707,6 +689,7 @@
 		GMC_WRITE_MASK_SET);

     wait_for_fifo(8, info);
+
     /* clear the line drawing registers */
     aty_st_le32(DST_BRES_ERR, 0);
     aty_st_le32(DST_BRES_INC, 0);
@@ -735,7 +718,7 @@
     if (bpp <= 8)
 	return DST_8BPP;
     else if (bpp <= 16)
-        return DST_15BPP;
+        return DST_16BPP;
     else if (bpp <= 24)
 	return DST_24BPP;
     else if (bpp <= 32)
@@ -880,8 +863,12 @@
     crtc->pitch = vxres >> 3;

     crtc->offset = 0;
-    crtc->offset_cntl = 0;

+    if ((var->activate & FB_ACTIVATE_MASK) == FB_ACTIVATE_NOW)
+        crtc->offset_cntl = 0x00010000;
+    else
+        crtc->offset_cntl = 0;
+
     crtc->vxres = vxres;
     crtc->vyres = vyres;
     crtc->xoffset = xoffset;
@@ -912,10 +899,10 @@
     case CRTC_PIX_WIDTH_15BPP:
     case CRTC_PIX_WIDTH_16BPP:
 	var->bits_per_pixel = 16;
-	var->red.offset = 10;
+	var->red.offset = 11;
 	var->red.length = 5;
 	var->green.offset = 5;
-	var->green.length = 5;
+	var->green.length = 6;
 	var->blue.offset = 0;
 	var->blue.length = 5;
 	var->transp.offset = 0;
@@ -1363,7 +1350,7 @@

     aty128_encode_var(var, &par, info);

-    if ((var->activate & FB_ACTIVATE_MASK) != FB_ACTIVATE_NOW)
+    if ((var->activate & FB_ACTIVATE_MASK) == FB_ACTIVATE_TEST)
 	return 0;

     oldxres = display->var.xres;
@@ -1527,7 +1514,7 @@
     par->crtc.xoffset = xoffset;
     par->crtc.yoffset = yoffset;

-    offset = ((yoffset * par->crtc.vxres + xoffset) * par->crtc.bpp) >> 6;
+    offset = ((yoffset * par->crtc.vxres + xoffset) * par->crtc.bpp) >> 3;

     aty_st_le32(CRTC_OFFSET, offset);

@@ -2217,69 +2204,52 @@

     /* initialize gamma ramp for hi-color+ */

-    if ((info->current_par.crtc.bpp > 8) && (regno == 0)) {
+    if (info->current_par.crtc.bpp > 8) {
         int i;

-        if (info->chip_gen == rage_M3)
-            aty_st_le32(DAC_CNTL, aty_ld_le32(DAC_CNTL) & ~DAC_PALETTE_ACCESS_CNTL);
+        aty_st_le32(DAC_CNTL, aty_ld_le32(DAC_CNTL) & ~DAC_PALETTE_ACCESS_CNTL);

-        for (i=16; i<256; i++) {
+        for (i=0; i<256; i++) {
             aty_st_8(PALETTE_INDEX, i);
             col = (i << 16) | (i << 8) | i;
             aty_st_le32(PALETTE_DATA, col);
         }
-
-        if (info->chip_gen == rage_M3) {
-            aty_st_le32(DAC_CNTL, aty_ld_le32(DAC_CNTL) | DAC_PALETTE_ACCESS_CNTL);
-
-            for (i=16; i<256; i++) {
-                aty_st_8(PALETTE_INDEX, i);
-                col = (i << 16) | (i << 8) | i;
-                aty_st_le32(PALETTE_DATA, col);
-            }
-        }
     }
+    else {
+        /* initialize palette */

-    /* initialize palette */
-
-    if (info->chip_gen == rage_M3)
-        aty_st_le32(DAC_CNTL, aty_ld_le32(DAC_CNTL) & ~DAC_PALETTE_ACCESS_CNTL);
+        if (info->chip_gen == rage_M3)
+            aty_st_le32(DAC_CNTL, aty_ld_le32(DAC_CNTL) & ~DAC_PALETTE_ACCESS_CNTL);

-    if (info->current_par.crtc.bpp == 16)
-        aty_st_8(PALETTE_INDEX, (regno << 3));
-    else
         aty_st_8(PALETTE_INDEX, regno);
-    col = (red << 16) | (green << 8) | blue;
-    aty_st_le32(PALETTE_DATA, col);
-    if (info->chip_gen == rage_M3) {
-    	aty_st_le32(DAC_CNTL, aty_ld_le32(DAC_CNTL) | DAC_PALETTE_ACCESS_CNTL);
-        if (info->current_par.crtc.bpp == 16)
-            aty_st_8(PALETTE_INDEX, (regno << 3));
-        else
-            aty_st_8(PALETTE_INDEX, regno);
+        col = (red << 16) | (green << 8) | blue;
         aty_st_le32(PALETTE_DATA, col);
+        if (info->chip_gen == rage_M3) {
+            aty_st_le32(DAC_CNTL, aty_ld_le32(DAC_CNTL) | DAC_PALETTE_ACCESS_CNTL);
+	    aty_st_8(PALETTE_INDEX, regno);
+	    aty_st_le32(PALETTE_DATA, col);
+	}
     }

     if (regno < 16)
 	switch (info->current_par.crtc.bpp) {
 #ifdef FBCON_HAS_CFB16
 	case 9 ... 16:
-	    info->fbcon_cmap.cfb16[regno] = (regno << 10) | (regno << 5) |
-                regno;
+	    info->fbcon_cmap.cfb16[regno] =   ( ((red   & 0xF8) << 8) |
+	                                        ((green & 0xFC) << 3) |
+	                                        ((blue  & 0xF8) >> 3) );
 	    break;
 #endif
 #ifdef FBCON_HAS_CFB24
 	case 17 ... 24:
-	    info->fbcon_cmap.cfb24[regno] = (regno << 16) | (regno << 8) |
-		regno;
+	    info->fbcon_cmap.cfb24[regno] = (red << 16) | (green << 8) |
+		blue;
 	    break;
 #endif
 #ifdef FBCON_HAS_CFB32
 	case 25 ... 32: {
-            u32 i;
-
-            i = (regno << 8) | regno;
-            info->fbcon_cmap.cfb32[regno] = (i << 16) | i;
+	    info->fbcon_cmap.cfb24[regno] = 0xFF000000 | (red << 16) |
+	                                    (green << 8) | blue;
 	    break;
         }
 #endif
@@ -2378,7 +2348,7 @@

     wait_for_fifo(2, info);
     aty_st_le32(DP_DATATYPE, save_dp_datatype);
-    aty_st_le32(DP_CNTL, save_dp_cntl);
+    aty_st_le32(DP_CNTL, save_dp_cntl);
 }


@@ -2635,3 +2605,4 @@
     }
 }
 #endif /* MODULE */
+

Re: r128 DRI driver now fully functional on PPC

[Kostas Gewrgiou]

On Wed, 31 Jan 2001, Benjamin Herrenschmidt wrote:

> I'll do some tests with the broken 16 bits mode to see if I get 3D
> working properly. I'll then see if I can figure out what cause the chip
> to lockup without UseFBDev.

After a quick look i noticed that R128EnterVTFBDev/R128LeaveVTFBDev have to
enable/disable DRI just as R128EnterVT/R128LeaveVT. So dont try to switch to
console until its fixed while you use UseFBDev and DRI.

Kostas


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: r128 DRI driver now fully functional on PPC

[Michel Dänzer]

Benjamin Herrenschmidt wrote:

>  - DRI support works only in 16 and 24/32 bits. However, 16 bits is
> broken with UseFBDev and I can't use it without fbdev (see below). The
> colors are screwed up (but the server works. I didn't yet try 3D since I
> have not yet compiled a GL app to test with). 15 bits works fine with the
> kernel driver but it's unuspported for DRI.
> I beleive the aty128fb kernel driver need to be fixed for 16 bits.

Indeed. (More on that in another post from me) But even if it was fixed, I'm
afraid the DRI won't work with UseFBDev - it messed up the display (even more
;) when I tried. Some strange interaction between aty128fb and DRI I guess.


>  - If I try to use the r128 driver without UseFBDev, the ATI chip locks
> up (the LCD loose sync, the machine is hard locked up). This used to work
> with earlier 4.0.1 servers, we need to figure out what changed. That
> match what other people already noticed.

The server works for me without UseFBDev but with Option "ProgramFPRegs" "No".

We need to look at the changes to the flat panel code shortly before 4.0.2 .


Beware that I have other problems with my Pismo; windowed GL apps lock up
sooner rather than later. Fullscreen stuff works great. Even Intel users with
Mobility chips reported such problems on the Xpert list; I'm curious how it
fares on desktop machines.


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

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [linux-fbdev] Re: r128 DRI driver now fully functional on PPC

[Michel Dänzer]

Andreas Hundt wrote:

> - driver now supports RGB565 16-bit mode

Looks like you killed RGB555 instead? I have another patch which makes both
available, but I never got the colors right in 565. I'll try to merge my patch
into yours and re-post it here and to Brad Douglas.


> - pannig works now, allows correct dublebuffering, without jittering screen.
>
> - FB_ACTIVATE_NOW and FB_ACTIVATE_VBL are now supported, CRTC_OFFSET_CNTL
>   register is set correctly. aty128fb only accepted FB_ACTIVATE_NOW before
>   but acted always like FB_ACTIVATE_VBL.
>   This fix eliminates flickering in ClanLib (and other fbdev applications)
>   when using doublebuffering.
>
> - no more messed up colors in modes > 8 bpp. driver no longer uses hardware
>   palette in modes > 8bpp, sets fbcon palette correctly instead.

Sounds great!


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

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [linux-fbdev] Re: r128 DRI driver now fully functional on PPC

[Geert Uytterhoeven]

On Wed, 31 Jan 2001, Michel Dänzer wrote:
> > - no more messed up colors in modes > 8 bpp. driver no longer uses hardware
> >   palette in modes > 8bpp, sets fbcon palette correctly instead.
>
> Sounds great!

The disadvantage is that if you change the palette, the text colors don't
change until you redraw the screen (or switch VC back-and-forth). That's why I
decided to use the hardware palette in directcolor modes.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [linux-fbdev] Re: r128 DRI driver now fully functional on PPC

[Michel Dänzer]

Geert Uytterhoeven wrote:
>
> On Wed, 31 Jan 2001, Michel Dänzer wrote:
> > > - no more messed up colors in modes > 8 bpp. driver no longer uses
> > >   hardware palette in modes > 8bpp, sets fbcon palette correctly
> > >   instead.
> >
> > Sounds great!
>
> The disadvantage is that if you change the palette, the text colors don't
> change until you redraw the screen (or switch VC back-and-forth). That's why
> I decided to use the hardware palette in directcolor modes.

I don't mind using the hardware palette if you (or anyone) tell me how to get
RGB565 working with that. :)


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

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [linux-fbdev] Re: r128 DRI driver now fully functional on PPC

[Andreas Hundt]

> The disadvantage is that if you change the palette, the text colors don't
> change until you redraw the screen (or switch VC back-and-forth). That's why I
> decided to use the hardware palette in directcolor modes.

I dont think it is good to use a palette in >8bpp modes. At least it
breaks
my fbdev software.

--
Andreas Hundt                              andi@convergence.de
Convergence Integrated Media GmbH          http://www.convergence.de
Rosenthaler Str. 51                        fon: +49(0)30-72 62 06 50
D-10178 Berlin                             fax: +49(0)30-72 62 06 55

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: r128 DRI driver now fully functional on PPC

[Timothy A. Seufert]

At 7:08 PM +1100 1/30/01, Gareth Hughes wrote:
>I've just committed the last of the updates required to get full hardware
>accelerated 3D rendering with the ATI Rage 128 on PowerPC.  Many
>thanks to Paul
>Mackerras for allowing me to hack away on his machine over the last week!
>
>The code is available on the ati-pcigart-0-0-1-branch in the DRI CVS
>repository.  Please feel free to check it out and report any
>problems you have.

Gareth (& everybody on the ppc dev list),

I've been trying to get this to work on a B&W G3 with a 100 MHz R128
PCI OEM card.

I'm getting things to build OK, but I did experience a couple
problems along the way.  The first was an old distribution /
compiler; when compiled by it, the X server would crash during
startup.  Reinstalling with LinuxPPC 2000 Q4 cured that.

The second is that the DRM kernel modules fail to build against the
2.2.18 headers.  A function in vm.c (I think) tries to access a field
named 'virtual' in struct page, which simply isn't there in 2.2.18.
The #if statements surrounding the code seem to be deliberately
compiling it only if the kernel is a 2.2 series, so I'm not sure what
is going on.  So I shifted over to the PPC 2.4 BK kernels and got
everything to build OK that way.

Where I'm at now is that the X server loads and runs (quite well I
might add), automatically loads the r128.o kernel module, and (in the
logfile) claims to have enabled direct rendering.  However, both
windowed and fullscreen GL apps are very clearly not being
accelerated.  Frame rates are obviously software renderer type frame
rates, and apps which check for multitexture capability complain that
it isn't there.

Any suggestions?  If anybody wants to see some logs from the server
starting up, I'll supply 'em.  Also, if anybody out there has gotten
this working, could you send me your XF86Config so I can make sure I
didn't do something silly to mine?

   Tim Seufert

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: r128 DRI driver now fully functional on PPC

[Gareth Hughes]

"Timothy A. Seufert" wrote:
>
> The second is that the DRM kernel modules fail to build against the
> 2.2.18 headers.  A function in vm.c (I think) tries to access a field
> named 'virtual' in struct page, which simply isn't there in 2.2.18.
> The #if statements surrounding the code seem to be deliberately
> compiling it only if the kernel is a 2.2 series, so I'm not sure what
> is going on.  So I shifted over to the PPC 2.4 BK kernels and got
> everything to build OK that way.

2.2 was never really well supported.  We've been using 2.4 for a long
time...

> Where I'm at now is that the X server loads and runs (quite well I
> might add), automatically loads the r128.o kernel module, and (in the
> logfile) claims to have enabled direct rendering.  However, both
> windowed and fullscreen GL apps are very clearly not being
> accelerated.  Frame rates are obviously software renderer type frame
> rates, and apps which check for multitexture capability complain that
> it isn't there.
>
> Any suggestions?  If anybody wants to see some logs from the server
> starting up, I'll supply 'em.  Also, if anybody out there has gotten
> this working, could you send me your XF86Config so I can make sure I
> didn't do something silly to mine?

Run with LIBGL_DEBUG=1 and see what it says.  Also, try the glxinfo
program (available from the DRI resources page) or Mesa/demos/glinfo --
these print out information about the OpenGL library being used.

-- Gareth

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: r128 DRI driver now fully functional on PPC

[Michel Dänzer]

"Timothy A. Seufert" wrote:

> Any suggestions?  If anybody wants to see some logs from the server
> starting up, I'll supply 'em.  Also, if anybody out there has gotten
> this working, could you send me your XF86Config so I can make sure I
> didn't do something silly to mine?

http://n.ethz.ch/student/daenzerm/download/DRI/XF86Config

is what I use on my Pismo.


Beware that I have merged in locally some fixes from the trunk which seem to
help for some problems I had - Gareth, will we merge the branch into the trunk
anytime soon or should I commit those to the branch?

The only issues I'm seeing now are broken lighting textures in quake-gl,
missing texture in xtraceroute and garbage at the top of the framebuffer
periodically. The last also causes a delay so I suspect it's some DMA
operation going wrong and the driver hitting a timeout, unfortunately I don't
have time to track it down and probably won't have for weeks. :(

Otherwise it works great for me!


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

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: r128 DRI driver now fully functional on PPC

[Gareth Hughes]

Michel Dänzer wrote:
>
> Beware that I have merged in locally some fixes from the trunk which seem to
> help for some problems I had - Gareth, will we merge the branch into the trunk
> anytime soon or should I commit those to the branch?

Jeff Hartmann has informed me he'll be merging it in RSN.

> The only issues I'm seeing now are broken lighting textures in quake-gl,
> missing texture in xtraceroute and garbage at the top of the framebuffer
> periodically. The last also causes a delay so I suspect it's some DMA
> operation going wrong and the driver hitting a timeout, unfortunately I don't
> have time to track it down and probably won't have for weeks. :(

Once we get everything on the trunk, we should look into these more.
There may already be fixes on the trunk for these problems -- the branch
was created a while ago now.

-- Gareth

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: r128 DRI driver now fully functional on PPC

[Michel Dänzer]

Gareth Hughes wrote:
>
> Michel Dänzer wrote:
> >
> > Beware that I have merged in locally some fixes from the trunk which seem
> > to help for some problems I had - Gareth, will we merge the branch into
> > the trunk anytime soon or should I commit those to the branch?
>
> Jeff Hartmann has informed me he'll be merging it in RSN.

Cool. I assume it won't get into an XFree86 release before 4.1.0 though?


> > The only issues I'm seeing now are broken lighting textures in quake-gl,
> > missing texture in xtraceroute and garbage at the top of the framebuffer
> > periodically. The last also causes a delay so I suspect it's some DMA
> > operation going wrong and the driver hitting a timeout, unfortunately I
> > don't have time to track it down and probably won't have for weeks. :(
>
> Once we get everything on the trunk, we should look into these more.
> There may already be fixes on the trunk for these problems -- the branch
> was created a while ago now.

Looking forward to that - I'd expect the first one to be an endianness
leftover though, and the second one might even be a client issue.


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

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: r128 DRI driver now fully functional on PPC

[Timothy A. Seufert]

At 9:02 PM +1100 2/23/01, Gareth Hughes wrote:

>Run with LIBGL_DEBUG=1 and see what it says.

This revealed what was happening.

I set the project root to /usr/Xgart to avoid having to overwrite my
existing X11 installation.  libGL was trying to load r128_dri.so, but
it was looking under /usr/X11R6/lib/modules/dri, which doesn't even
exist.

Since then, I've been trying a number of things, with partial success:


1. Tried to replace /usr/X11R6/lib in /etc/ld.so.conf with
/usr/Xgart/lib.  Result: X server won't start because the DRI tree
isn't building most of the various X shared libraries like Xmu, ICE,
etc.


2. Tried to work around #1 by leaving both /usr/Xgart/lib and
/usr/X11R6/lib in ld.so.conf (Xgart first so it gets priority).

Result: 3D acceleration works!  However, there are a couple major
problems.  First, window titles aren't drawn (the borders are, but
the title text is not), and second, upon running a GL program (I've
been using gears and gloss from Mesa 3.3), I lose keyboard and mouse
input.  Sometimes the mouse cursor is still visible, but clicks do
nothing.  Even pressing caps lock doesn't toggle the capslock light.
I have to telnet into the machine and kill the GL program to get
control back.


3. As an alternate to #2, I went back to just /usr/X11R6/lib in
ld.so.conf, and added symlinks under /usr/X11R6/lib to the missing GL
and DRI libs in the Xgart tree.  I got the window titles back this
way (must be a busted non-3D library somewhere in the DRI tree
causing that), but the input device problems persist.


4. Tried to do the right thing by figuring out how to build the
missing libraries in the DRI tree.  The source code for all the
relevant libs seems to be there, but I can't decipher the X11 build
system enough to figure out exactly why they aren't being built.

I think it's the "#define BuildServersOnly YES" line in host.def, but
commenting it out breaks the build because the DRI tree is not a full
XFree86 source tree.


I'm guessing that this is really the way to go.  Does anybody know of
a way to force building more of the libraries without actually
building everything?  Or do I need to download the remaining chunks
of the Xfree86 source tree and do a full build of everything?

   Tim Seufert

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: r128 DRI driver now fully functional on PPC

[Michel Dänzer]

"Timothy A. Seufert" wrote:
>
> At 9:02 PM +1100 2/23/01, Gareth Hughes wrote:
>
> >Run with LIBGL_DEBUG=1 and see what it says.
>
> This revealed what was happening.
>
> I set the project root to /usr/Xgart to avoid having to overwrite my
> existing X11 installation.  libGL was trying to load r128_dri.so, but
> it was looking under /usr/X11R6/lib/modules/dri, which doesn't even
> exist.

Strange, it should look in <ProjectRoot>/lib/modules/dri/ . Seems it didn't
pick up the right libGL.


> Since then, I've been trying a number of things, with partial success:
>
> 1. Tried to replace /usr/X11R6/lib in /etc/ld.so.conf with
> /usr/Xgart/lib.  Result: X server won't start because the DRI tree
> isn't building most of the various X shared libraries like Xmu, ICE,
> etc.
>
> 2. Tried to work around #1 by leaving both /usr/Xgart/lib and
> /usr/X11R6/lib in ld.so.conf (Xgart first so it gets priority).
>
> Result: 3D acceleration works!  However, there are a couple major
> problems.  First, window titles aren't drawn (the borders are, but
> the title text is not), and second, upon running a GL program (I've
> been using gears and gloss from Mesa 3.3), I lose keyboard and mouse
> input.  Sometimes the mouse cursor is still visible, but clicks do
> nothing.  Even pressing caps lock doesn't toggle the capslock light.
> I have to telnet into the machine and kill the GL program to get
> control back.

What's your hardware? Jack Howarth used to have similar problems with the old
driver, but AFAIR it was because he tried to build things with the Red Hat
following the Red Hat procedure.


> 3. As an alternate to #2, I went back to just /usr/X11R6/lib in
> ld.so.conf, and added symlinks under /usr/X11R6/lib to the missing GL
> and DRI libs in the Xgart tree.  I got the window titles back this
> way (must be a busted non-3D library somewhere in the DRI tree
> causing that), but the input device problems persist.
>
> 4. Tried to do the right thing by figuring out how to build the
> missing libraries in the DRI tree.  The source code for all the
> relevant libs seems to be there, but I can't decipher the X11 build
> system enough to figure out exactly why they aren't being built.
>
> I think it's the "#define BuildServersOnly YES" line in host.def, but
> commenting it out breaks the build because the DRI tree is not a full
> XFree86 source tree.
>
> I'm guessing that this is really the way to go.  Does anybody know of
> a way to force building more of the libraries without actually
> building everything?  Or do I need to download the remaining chunks
> of the Xfree86 source tree and do a full build of everything?

I wouldn't waste too much time to figure that out (if it works at all) because
this will eventually be in the standard XFree86. For now, I use a symlink for
r128_dri.so and set LD_LIBRARY_PATH.


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

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: r128 DRI driver now fully functional on PPC

[Gareth Hughes]

Michel Dänzer wrote:
>
> "Timothy A. Seufert" wrote:
> >
> > At 9:02 PM +1100 2/23/01, Gareth Hughes wrote:
> >
> > >Run with LIBGL_DEBUG=1 and see what it says.
> >
> > This revealed what was happening.
> >
> > I set the project root to /usr/Xgart to avoid having to overwrite my
> > existing X11 installation.  libGL was trying to load r128_dri.so, but
> > it was looking under /usr/X11R6/lib/modules/dri, which doesn't even
> > exist.
>
> Strange, it should look in <ProjectRoot>/lib/modules/dri/ . Seems it didn't
> pick up the right libGL.

I'd say libGL.so is doing dlopen( "modules/dri/r128_dri.so", ... ) and
thus picking up the first instance of that in the dynamic loader's
path.  Similarly, applications linked with -lGL will pick up the first
instance of libGL.so, not necessarily the one residing under the current
X server's ProjectRoot directory.

It's very important you have ld.so.conf set to pick up the correct
version if you haven't installed the DRI-enabled X server in /usr/X11R6.

-- Gareth

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: r128 DRI driver now fully functional on PPC

[Michel Dänzer]

Gareth Hughes wrote:
>
> Michel Dänzer wrote:
> >
> > "Timothy A. Seufert" wrote:
> > >
> > > At 9:02 PM +1100 2/23/01, Gareth Hughes wrote:
> > >
> > > >Run with LIBGL_DEBUG=1 and see what it says.
> > >
> > > This revealed what was happening.
> > >
> > > I set the project root to /usr/Xgart to avoid having to overwrite my
> > > existing X11 installation.  libGL was trying to load r128_dri.so, but
> > > it was looking under /usr/X11R6/lib/modules/dri, which doesn't even
> > > exist.
> >
> > Strange, it should look in <ProjectRoot>/lib/modules/dri/ . Seems it
> > didn't pick up the right libGL.
>
> I'd say libGL.so is doing dlopen( "modules/dri/r128_dri.so", ... ) and
> thus picking up the first instance of that in the dynamic loader's
> path.  Similarly, applications linked with -lGL will pick up the first
> instance of libGL.so, not necessarily the one residing under the current
> X server's ProjectRoot directory.

First I thought I'd stand corrected, but on second thought - it looks for
/usr/X11R6-DRI/lib/modules/dri/r128_dri.so on my machine (if ProjectRoot is
/usr/X11R6-DRI), but /usr/X11R6-DRI/lib isn't in ld.so.conf . It even looks
there if I set LD_LIBRARY_PATH to the exports/lib directory in the build tree.


Am I still not getting it? :)


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

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: r128 DRI driver now fully functional on PPC

[Gareth Hughes]

Michel Dänzer wrote:
>
> First I thought I'd stand corrected, but on second thought - it looks for
> /usr/X11R6-DRI/lib/modules/dri/r128_dri.so on my machine (if ProjectRoot is
> /usr/X11R6-DRI), but /usr/X11R6-DRI/lib isn't in ld.so.conf . It even looks
> there if I set LD_LIBRARY_PATH to the exports/lib directory in the build tree.
>
> Am I still not getting it? :)

Sorry, my mistake.  libGL.so opens $MODULEDIR/dri/r128_dri.so, where
$MODULEDIR is defined by the Imakefiles (and would be
/usr/X11R6-DRI/lib/modules in your case).  So, the problem may be that
the wrong libGL.so is being picked up -- and this *is* an ld.so.conf
problem.

-- Gareth

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: r128 DRI driver now fully functional on PPC

[Timothy A. Seufert]

At 9:28 PM +1100 2/26/01, Gareth Hughes wrote:
>Michel Dänzer wrote:
>>
>>  First I thought I'd stand corrected, but on second thought - it looks for
>>  /usr/X11R6-DRI/lib/modules/dri/r128_dri.so on my machine (if ProjectRoot is
>>  /usr/X11R6-DRI), but /usr/X11R6-DRI/lib isn't in ld.so.conf . It even looks
>>  there if I set LD_LIBRARY_PATH to the exports/lib directory in the
>>build tree.
>>
>>  Am I still not getting it? :)
>
>Sorry, my mistake.  libGL.so opens $MODULEDIR/dri/r128_dri.so, where
>$MODULEDIR is defined by the Imakefiles (and would be
>/usr/X11R6-DRI/lib/modules in your case).  So, the problem may be that
>the wrong libGL.so is being picked up -- and this *is* an ld.so.conf
>problem.

Could the Imakefiles have been broken by the following options in site.def?

#define NothingOutsideProjectRoot YES
#define EtcX11Directory ProjectRoot/etc

I enabled (uncommented) both of these since I thought it might be a
good idea to force X to be completely self-contained within
ProjectRoot.

I just tried a build without these options and it seems to clear up
the library problem.  After doing so I have only two differences from
the config files in CVS: I set ProjectRoot and disabled Glide3.  So
it's entirely possible that setting Nothing... and/or EtcX11Dir...
caused the compiled-in default library search path you describe to
get mangled.


I still have the problem with keyboard/mouse input being ignored once
a GL app starts.  A friend suggested disabling DGA, but that didn't
help.  I do notice this message popping in the system logs, repeated
numerous times:

[drm:drm_lock_take] *ERROR* 1 holds heavyweight lock

   Tim Seufert

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: r128 DRI driver now fully functional on PPC

[Gareth Hughes]

"Timothy A. Seufert" wrote:
>
> I still have the problem with keyboard/mouse input being ignored once
> a GL app starts.  A friend suggested disabling DGA, but that didn't
> help.  I do notice this message popping in the system logs, repeated
> numerous times:
>
> [drm:drm_lock_take] *ERROR* 1 holds heavyweight lock

This happens when the lock ioctl occurs when the lock is already held.
'1' is the X server, so the X server is grabbing the lock when it
already has it.

-- Gareth

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: r128 DRI driver now fully functional on PPC

[Michel Dänzer]

[-- Attachment #1: Type: text/plain, Size: 838 bytes --]

Gareth Hughes wrote:
>
> "Timothy A. Seufert" wrote:
> >
> > I still have the problem with keyboard/mouse input being ignored once
> > a GL app starts.  A friend suggested disabling DGA, but that didn't
> > help.  I do notice this message popping in the system logs, repeated
> > numerous times:
> >
> > [drm:drm_lock_take] *ERROR* 1 holds heavyweight lock
>
> This happens when the lock ioctl occurs when the lock is already held.
> '1' is the X server, so the X server is grabbing the lock when it
> already has it.

Which might be fixed by the attached patch which Gareth posted to dri-devel
lately.

But don't expect this to solve your input problems as I never had them.


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

[-- Attachment #2: r128-4.0.2-patch --]
[-- Type: text/plain, Size: 3645 bytes --]

diff -ur xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/r128_cce.c xc.gh/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/r128_cce.c
--- xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/r128_cce.c	Wed Dec 13 11:02:12 2000
+++ xc.gh/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/r128_cce.c	Tue Feb 20 18:10:16 2001
@@ -36,9 +36,8 @@
 #include <linux/interrupt.h>	/* For task queue support */
 #include <linux/delay.h>

+#define R128_FIFO_DEBUG		0

-/* FIXME: Temporary CCE packet buffer */
-u32 r128_cce_buffer[(1 << 14)] __attribute__ ((aligned (32)));

 /* CCE microcode (from ATI) */
 static u32 r128_cce_microcode[] = {
@@ -114,7 +113,7 @@
 	return R128_READ(R128_CLOCK_CNTL_DATA);
 }

-#if 0
+#if R128_FIFO_DEBUG
 static void r128_status( drm_r128_private_t *dev_priv )
 {
 	printk( "GUI_STAT           = 0x%08x\n",
@@ -152,7 +151,9 @@
 		udelay( 1 );
 	}

+#if R128_FIFO_DEBUG
 	DRM_ERROR( "%s failed!\n", __FUNCTION__ );
+#endif
 	return -EBUSY;
 }

@@ -166,7 +167,9 @@
 		udelay( 1 );
 	}

+#if R128_FIFO_DEBUG
 	DRM_ERROR( "%s failed!\n", __FUNCTION__ );
+#endif
 	return -EBUSY;
 }

@@ -175,7 +178,7 @@
 	int i, ret;

 	ret = r128_do_wait_for_fifo( dev_priv, 64 );
-	if ( !ret ) return ret;
+	if ( ret < 0 ) return ret;

 	for ( i = 0 ; i < dev_priv->usec_timeout ; i++ ) {
 		if ( !(R128_READ( R128_GUI_STAT ) & R128_GUI_ACTIVE) ) {
@@ -185,7 +188,9 @@
 		udelay( 1 );
 	}

+#if R128_FIFO_DEBUG
 	DRM_ERROR( "%s failed!\n", __FUNCTION__ );
+#endif
 	return -EBUSY;
 }

@@ -241,7 +246,7 @@
 		udelay( 1 );
 	}

-#if 0
+#if R128_FIFO_DEBUG
 	DRM_ERROR( "failed!\n" );
 	r128_status( dev_priv );
 #endif
diff -ur xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/r128_drv.h xc.gh/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/r128_drv.h
--- xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/r128_drv.h	Tue Dec  5 11:57:26 2000
+++ xc.gh/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/r128_drv.h	Tue Feb 20 18:04:17 2001
@@ -388,11 +388,11 @@
 #define R128_BASE(reg)		((u32)(dev_priv->mmio->handle))
 #define R128_ADDR(reg)		(R128_BASE(reg) + reg)

-#define R128_DEREF(reg)		*(__volatile__ int *)R128_ADDR(reg)
+#define R128_DEREF(reg)		*(volatile u32 *)R128_ADDR(reg)
 #define R128_READ(reg)		R128_DEREF(reg)
 #define R128_WRITE(reg,val)	do { R128_DEREF(reg) = val; } while (0)

-#define R128_DEREF8(reg)	*(__volatile__ char *)R128_ADDR(reg)
+#define R128_DEREF8(reg)	*(volatile u8 *)R128_ADDR(reg)
 #define R128_READ8(reg)		R128_DEREF8(reg)
 #define R128_WRITE8(reg,val)	do { R128_DEREF8(reg) = val; } while (0)

diff -ur xc/programs/Xserver/hw/xfree86/os-support/linux/drm/xf86drmR128.c xc.gh/programs/Xserver/hw/xfree86/os-support/linux/drm/xf86drmR128.c
--- xc/programs/Xserver/hw/xfree86/os-support/linux/drm/xf86drmR128.c	Wed Dec 13 11:02:11 2000
+++ xc.gh/programs/Xserver/hw/xfree86/os-support/linux/drm/xf86drmR128.c	Tue Feb 20 23:44:14 2001
@@ -78,7 +78,7 @@
 #include "drm.h"

 #define R128_BUFFER_RETRY	32
-#define R128_IDLE_RETRY		16
+#define R128_IDLE_RETRY		32


 int drmR128InitCCE( int fd, drmR128Init *info )
@@ -154,8 +154,11 @@

    ret = ioctl( fd, DRM_IOCTL_R128_CCE_STOP, &stop );

-   if ( ret && errno != EBUSY )
+   if ( ret == 0 ) {
+      return 0;
+   } else if ( errno != EBUSY ) {
       return -errno;
+   }

    stop.flush = 0;

@@ -163,8 +166,11 @@
       ret = ioctl( fd, DRM_IOCTL_R128_CCE_STOP, &stop );
    } while ( ret && errno == EBUSY && i++ < R128_IDLE_RETRY );

-   if ( ret && errno != EBUSY )
+   if ( ret == 0 ) {
+      return 0;
+   } else if ( errno != EBUSY ) {
       return -errno;
+   }

    stop.idle = 0;