asm statement in include/asm not ansi conform

asm statement in include/asm not ansi conform

[Marc Dietrich]

Hi,

I just compiled XFree from dri.sourceforge.net, which uses the "-ansi"
option for compiling. Problem is, that this fails on some "asm"
instructions in e.g. include/asm-ppc/processor.h. I'm not very firm with
C but is it posible to replace this with __asm__ ? I compiled X without
-ansi and it seems to work. Just for the case other applications also
fail on this.

Greetings

Marc

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

Re: asm statement in include/asm not ansi conform

[Michel Dänzer]

Marc Dietrich wrote:

> I just compiled XFree from dri.sourceforge.net, which uses the "-ansi"
> option for compiling.

Is that defined in xc/config/cf/host.def? It's always a good idea to tweak
that file before an X build.


> Problem is, that this fails on some "asm" instructions in e.g.
> include/asm-ppc/processor.h. I'm not very firm with C but is it posible to
> replace this with __asm__ ? I compiled X without -ansi and it seems to work.

So the DRI is working for you? Cool, we are two now then ;)


Michel


--
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86 and the DRI project

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

Re: asm statement in include/asm not ansi conform

[Marc Dietrich]

Hello Michel,

after some testing dri works now. On startup X says "dri enabled" and
glinfo shows many supported GL functions. But at least when running
"gears" for example, I get no accelaration at all. Still 60 frames per
second - same as with software rendering. I also have a P-III/500 box with
Rage128 (AGP) witch produces 400 frames! Glxinfo says something like "RGB
error" and breaks.

Maybe it's better at your site?

Marc

On Wed, 30 Aug 2000, Michel Dänzer wrote:

> Marc Dietrich wrote:
>
> > I just compiled XFree from dri.sourceforge.net, which uses the "-ansi"
> > option for compiling.
>
> Is that defined in xc/config/cf/host.def? It's always a good idea to tweak
> that file before an X build.
>
>
> > Problem is, that this fails on some "asm" instructions in e.g.
> > include/asm-ppc/processor.h. I'm not very firm with C but is it posible to
> > replace this with __asm__ ? I compiled X without -ansi and it seems to work.
>
> So the DRI is working for you? Cool, we are two now then ;)
>
>

Marc Dietrich                marc.dietrich@physik.uni-giessen.de


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

Re: asm statement in include/asm not ansi conform

[Michel Dänzer]

Marc Dietrich wrote:

> after some testing dri works now. On startup X says "dri enabled" and
> glinfo shows many supported GL functions. But at least when running
> "gears" for example, I get no accelaration at all. Still 60 frames per
> second - same as with software rendering.

For me, gears gives even less FPS on startup with DRI than with software
rendering ;) What happens when you maximize the window?

A few possibilities to find out if you are really using direct rendering:

- set LIBGL_DEBUG=verbose
- run a program with lots of textured triangles (Quake, fire, ...)
- test, compare, test, ...


> I also have a P-III/500 box with Rage128 (AGP) witch produces 400 frames!

DRI currently only runs in PIO mode as we don't have any GART driver yet.

Anyway, this is a nice preview of what we could expect with AGP GART :)


> Glxinfo says something like "RGB error" and breaks.

Hmm, never tried it.


Michel


--
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86 and the DRI project

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

Re: asm statement in include/asm not ansi conform

[Benjamin Herrenschmidt]

>after some testing dri works now. On startup X says "dri enabled" and
>glinfo shows many supported GL functions. But at least when running
>"gears" for example, I get no accelaration at all. Still 60 frames per
>second - same as with software rendering. I also have a P-III/500 box with
>Rage128 (AGP) witch produces 400 frames! Glxinfo says something like "RGB
>error" and breaks.

There's no support for the AGP bus mastering on PowerMac yet. I've been
running into trouble implementing that due to differences between what
the linux /dev/agpgart driver expect an AGP chipset to do, and what
Apple's UniNorth can actually do.

I plan (this week-end) to look more closely at the r128 DRI code to see
how it uses the AGP and possibly implement a pmac-specific driver (at
least for now. Once I have working code, I can try to get the existing /
dev/agpgart driver redesigned).

Ben.


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

Re: asm statement in include/asm not ansi conform

[Marc Dietrich]

On Thu, 31 Aug 2000, Benjamin Herrenschmidt wrote:

> There's no support for the AGP bus mastering on PowerMac yet. I've been
> running into trouble implementing that due to differences between what
> the linux /dev/agpgart driver expect an AGP chipset to do, and what
> Apple's UniNorth can actually do.
>
> I plan (this week-end) to look more closely at the r128 DRI code to see
> how it uses the AGP and possibly implement a pmac-specific driver (at
> least for now. Once I have working code, I can try to get the existing /
> dev/agpgart driver redesigned).

I fear this won't help much in my case (with b&w G3). Anyway there's still
a lot to do. DRI is very unstable and it seems that some functions are
missing.

Thanks for your great work

Marc

---
Marc Dietrich                marc.dietrich@physik.uni-giessen.de


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

Re: asm statement in include/asm not ansi conform

[Timothy A. Seufert]

Hey Michel,

I have DRI working too, on a B&W G3 500 MHz with a 100 MHz R128.
Thanks for getting it to work!

I do have one non-DRI problem.  The r128 module for XF4 has some
problems initializing my variant of the Rage 128 correctly.  Here's
the relevant part of the startup log:

==================================================================
(II) Loading sub module "fbdevhw"
(II) LoadModule: "fbdevhw"
(II) Loading /usr/XF86-DRI/lib/modules/linux/libfbdevhw.a
(II) Module fbdevhw: vendor="The XFree86 Project"
         compiled for 4.0.1, module version = 0.0.1
         ABI class: XFree86 Video Driver, version 0.2
(--) r128(0): Chipset: "ATI Rage 128 RE (PCI)" (ChipID = 0x5245)
(--) r128(0): Linear framebuffer at 0x84000000
(--) r128(0): MMIO registers at 0x80900000
(--) r128(0): BIOS at 0x80920000
(--) r128(0): VideoRAM: 16384 kByte (128-bit SDR SGRAM 1:1)
(**) r128(0): Forced into PCI-only mode
(II) r128(0): PLL parameters: rf=18432 rd=45949 min=-2143223788 max=2088639352;
xclk=0
(==) r128(0): Using gamma correction (1.0, 1.0, 1.0)
(II) r128(0): Monitor0: Using hsync range of  30.00- 95.00 kHz
(II) r128(0): Monitor0: Using vrefresh range of  48.00-160.00 Hz
(II) r128(0): Clock range: -2143223.79 to -588442.96 MHz
(WW) r128(0): Mode "640x350" deleted (bad mode clock/interlace/doublescan)
(WW) r128(0): Mode "640x400" deleted (bad mode clock/interlace/doublescan)
(WW) r128(0): Mode "720x400" deleted (bad mode clock/interlace/doublescan)

[lots of mode deletes snipped]

(WW) r128(0): Mode "1856x1392" deleted (bad mode clock/interlace/doublescan)
(WW) r128(0): Mode "1920x1440" deleted (bad mode clock/interlace/doublescan)
(WW) r128(0): Mode "1920x1440" deleted (bad mode clock/interlace/doublescan)
(WW) r128(0): Mode pool is empty
(--) r128(0): Virtual size is 1024x768 (pitch 1024)
(**) r128(0): Built-in mode "current": 78.7 MHz, 60.0 kHz, 75.0 Hz
(==) r128(0): DPI set to (75, 75)
==================================================================


I'm using fbdev instead of vga as you had set up the example config
file, but the misdetection of the clock and subsequent deletion of
all the modes happens either way.  The only difference is that with
fbdev it appears to default back to a built-in 1024x768 mode, so that
the X server can actually start; in vga mode it just aborts due to
not having any valid modes.

For comparison, this is what I get with a mainline 4.0.1 tree with
Ani Joshi's replacement drivers for PPC (no DRI support of course):

==================================================================
(II) Loading sub module "fbdevhw"
(II) LoadModule: "fbdevhw"
(II) Loading /usr/X11R6/lib/modules/linux/libfbdevhw.a
(II) Module fbdevhw: vendor="The XFree86 Project"
         compiled for 4.0.1, module version = 0.0.1
         ABI class: XFree86 Video Driver, version 0.2
(--) r128(0): Chipset: "ATI Rage 128 RE (PCI)" (ChipID = 0x5245)
(--) r128(0): Linear framebuffer at 0x84000000
(--) r128(0): MMIO registers at 0x80900000
(--) r128(0): BIOS at 0x80920000
(--) r128(0): VideoRAM: 16384 kByte (128-bit SDR SGRAM 1:1)
(II) r128(0): PLL parameters: rf=2950 rd=50 min=12500 max=25000; xclk=10001
(==) r128(0): Using gamma correction (1.0, 1.0, 1.0)
(II) r128(0): Monitor0: Using hsync range of  30.00- 95.00 kHz
(II) r128(0): Monitor0: Using vrefresh range of  48.00-160.00 Hz
(II) r128(0): Clock range:  12.50 to 250.00 MHz
(WW) r128(0): Mode "1600x1200" deleted (hsync out of range)
(WW) r128(0): Mode "1792x1344" deleted (bad mode clock/interlace/doublescan)
(WW) r128(0): Mode "1856x1392" deleted (bad mode clock/interlace/doublescan)
(WW) r128(0): Mode "1920x1440" deleted (bad mode clock/interlace/doublescan)
(--) r128(0): Virtual size is 1280x960 (pitch 1280)
(**) r128(0): Default mode "1280x960": 148.5 MHz, 85.9 kHz, 85.0 Hz
(==) r128(0): DPI set to (75, 75)
==================================================================

This could be something as simple as an endianness problem, but I
don't have the time at the moment to track down where in the code
this probing is being done.

I have checked out a copy of the PPC branch of the DRI CVS tree, so
if you need me to test with different things just let me know.

   Tim Seufert

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

Re: asm statement in include/asm not ansi conform

[Michel Dänzer]

Marc Dietrich wrote:
>
> On Thu, 31 Aug 2000, Benjamin Herrenschmidt wrote:
>
> > There's no support for the AGP bus mastering on PowerMac yet. I've been
> > running into trouble implementing that due to differences between what
> > the linux /dev/agpgart driver expect an AGP chipset to do, and what
> > Apple's UniNorth can actually do.
> >
> > I plan (this week-end) to look more closely at the r128 DRI code to see
> > how it uses the AGP and possibly implement a pmac-specific driver (at
> > least for now. Once I have working code, I can try to get the existing /
> > dev/agpgart driver redesigned).
>
> I fear this won't help much in my case (with b&w G3). Anyway there's still
> a lot to do. DRI is very unstable and it seems that some functions are
> missing.

It has been very stable for me so far, I suspect we have different definitions
for "stable". About the missing stuff (and any problems), please post to
dri-devel@lists.sourceforge.net or submit bugs to the DRI project at
SourceForge. I'm not currently aware of any major bug, so I don't really know
what to do :)


Michel


--
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86 and The DRI Project

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

Re: asm statement in include/asm not ansi conform

[Benjamin Herrenschmidt]

>
>I fear this won't help much in my case (with b&w G3). Anyway there's still
>a lot to do. DRI is very unstable and it seems that some functions are
>missing.
>
>Thanks for your great work

Yes, it may help. AFAIK, the R128 also supports a "PCI GART" and I do
intend to make sure my driver can handle those too (since supporting a
PCI GART involves pretty much the same thing as supporting the Uni-N AGP
GART).

Ben.


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

Re: asm statement in include/asm not ansi conform

[Michel Dänzer]

"Timothy A. Seufert" wrote:

> (II) r128(0): PLL parameters: rf=18432 rd=45949 min=-2143223788
> max=2088639352; xclk=0
> (==) r128(0): Using gamma correction (1.0, 1.0, 1.0)
> (II) r128(0): Monitor0: Using hsync range of  30.00- 95.00 kHz
> (II) r128(0): Monitor0: Using vrefresh range of  48.00-160.00 Hz
> (II) r128(0): Clock range: -2143223.79 to -588442.96 MHz

The PLL and clock values are bogus. You could try overriding the clock values
in XF86Config.


> For comparison, this is what I get with a mainline 4.0.1 tree with
> Ani Joshi's replacement drivers for PPC (no DRI support of course):

[snip]

> I have checked out a copy of the PPC branch of the DRI CVS tree, so
> if you need me to test with different things just let me know.

Just putting Ani's r128 (or the whole xfree86) directory into the DRI tree
should work, as the changes in the DRI branch are mostly outside the 2D
driver. Please let me know if there are problems.


Michel


--
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86 and The DRI Project


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

Re: asm statement in include/asm not ansi conform

[Benjamin Herrenschmidt]

>
>The PLL and clock values are bogus. You could try overriding the clock values
>in XF86Config.

Maybe the DRI tree doesn't contain the PLL probe code for PPC ?


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

Re: asm statement in include/asm not ansi conform

[Michel Dänzer]

Benjamin Herrenschmidt wrote:
>
> >
> >The PLL and clock values are bogus. You could try overriding the clock
> > values in XF86Config.
>
> Maybe the DRI tree doesn't contain the PLL probe code for PPC ?

Not maybe ;)

(When) Will that code be submitted to XFree86 BTW?


Michel


--
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86 and The DRI Project

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

Re: asm statement in include/asm not ansi conform

[Hendricks, Kevin]

Hi,

>> Maybe the DRI tree doesn't contain the PLL probe code for PPC ?
>
>Not maybe ;)
>
>(When) Will that code be submitted to XFree86 BTW?

I submitted that patch to Brad and Anthony so that it would make it into
the official kernel trees and made and posted an XF86 4 patch to the
mailing lists awhile back but but it does not seem to have made it into all
XF86 trees.

I can probably dig up that patch on my home machine and send it to the
mailing list again if anyone wants it.

Kevin

--
Kevin B. Hendricks, Associate Professor of Operations and Information
Technology
Richard Ivey School of Business, University of Western Ontario
London, Ontario  N6A-3K7  CANADA
khendricks@ivey.uwo.ca, (519) 661-3874, fax: 519-661-3959


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

Re: asm statement in include/asm not ansi conform

[Benjamin Herrenschmidt]

>Not maybe ;)
>
>(When) Will that code be submitted to XFree86 BTW?

When someone finally decide to implement code that checks if we have or
not a PC BIOS from which we can read the values. It's on my (long)
todolist, I was more or less hoping that Kostas would do it before me,
especially since I don't have an x86 card to test with.

Ben.


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

Re: asm statement in include/asm not ansi conform

[Benjamin Herrenschmidt]

>I submitted that patch to Brad and Anthony so that it would make it into
>the official kernel trees and made and posted an XF86 4 patch to the
>mailing lists awhile back but but it does not seem to have made it into all
>XF86 trees.
>
>I can probably dig up that patch on my home machine and send it to the
>mailing list again if anyone wants it.

The patch have long been in the PPC RPMs produced by Howarth and Franz.
It was not merged in the main tree since we wanted to actually check if
there's an x86 card there with a valid BIOS ROM image, and no-one found
the time to do it.

Ben.


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

Re: asm statement in include/asm not ansi conform

[Hendricks, Kevin]

Hi,

> When someone finally decide to implement code that checks if we have or
> not a PC BIOS from which we can read the values. It's on my (long)
> todolist, I was more or less hoping that Kostas would do it before me,
> especially since I don't have an x86 card to test with.

As I remember things, the xf4 code does do a simple check to see if there is a
bios present.  I once enabled this code and found out on my B+W G3 machine, it
passed that bios test but read completely bogus values (even if you converted
the data for endian issues) whereas on my G4, it completely failed the simple
bios check that was present.

Without a real xf86 card with a bios present to play with, there is really no
way to try and devise a better test.  Even if a bios is present, wouldn't OF
still do the initialization?

I think we should submit it as is and ifdef it to powerpc and forget about it
until we find out what is up.

By the way, either way, the values calculated by that code should be fine (as
long as the main code clock rate is 2950) whether intialized by OF or an actual
bios so no real harm should be done (certainly better than their hardcoded
values used now).

My 2 cents.

Kevin

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

Re: asm statement in include/asm not ansi conform

[Benjamin Herrenschmidt]

>As I remember things, the xf4 code does do a simple check to see if
there is a
>bios present.  I once enabled this code and found out on my B+W G3
machine, it
>passed that bios test but read completely bogus values (even if you converted
>the data for endian issues) whereas on my G4, it completely failed the simple
>bios check that was present.

Yes, we need a better check since OF code also begins with aa55. It looks
like on the newer machines, the ATI card ROM doesn't contain the OF code
but older cards did.

>Without a real xf86 card with a bios present to play with, there is really no
>way to try and devise a better test.  Even if a bios is present, wouldn't OF
>still do the initialization?

I don't think OF will do anything but assign base addresses.

>I think we should submit it as is and ifdef it to powerpc and forget about it
>until we find out what is up.
>
>By the way, either way, the values calculated by that code should be fine (as
>long as the main code clock rate is 2950) whether intialized by OF or an
>actual
>bios so no real harm should be done (certainly better than their hardcoded
>values used now).

There is at least one r128 based PCI card for Mac that uses a different
clock rate. I think we should (for the future at least) add code to
aty128fb to recongnize it and return proper values from a private ioctl.
That wouldn't help users not using aty128fb, but on Macs, I beleive those
will be rare.

Ben.


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

Re: asm statement in include/asm not ansi conform

[Geert Uytterhoeven]

On Fri, 1 Sep 2000, Benjamin Herrenschmidt wrote:
> >Without a real xf86 card with a bios present to play with, there is really no
> >way to try and devise a better test.  Even if a bios is present, wouldn't OF
> >still do the initialization?
>
> I don't think OF will do anything but assign base addresses.

And even that depends on the OF. Not all versions assign all base addresses
for `unrecognized' cards.

Let's hope the kernel will do soon :-)

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: asm statement in include/asm not ansi conform

[Michel Dänzer]

Benjamin Herrenschmidt wrote:

> There is at least one r128 based PCI card for Mac that uses a different
> clock rate. I think we should (for the future at least) add code to
> aty128fb to recongnize it and return proper values from a private ioctl.
> That wouldn't help users not using aty128fb, but on Macs, I beleive those
> will be rare.

Only if 16 bit works properly in aty128fb (I have it working in console, still
wrong colors with X, patch sent to Brad Douglas), otherwise people who want to
use DRI are forced not to use it with X.


Michel


--
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86 and The DRI Project

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

Re: asm statement in include/asm not ansi conform

[Timothy A. Seufert]

At 1:44 PM +0200 9/1/00, Michel Dänzer wrote:

>Just putting Ani's r128 (or the whole xfree86) directory into the DRI tree
>should work, as the changes in the DRI branch are mostly outside the 2D
>driver. Please let me know if there are problems.

I did something similar -- merged the two versions of the 2D driver.
It worked.

I do find that I have to keep it at 16-bit at resolutions higher than
1024x768, otherwise there isn't enough memory for textures.


   Tim Seufert

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