3D accel on PPC

3D accel on PPC

[Timothy A. Seufert]

Has anybody made progress in getting 3D acceleration to work on PPC?

I *thought* I saw a message a few days ago about XF 4.x DRI work
being done to make R128 3D accel run on PPC, and I know Kostas
Gewgriou (hope I spelled that right Kostas ;) was doing work some
time ago on 3Dfx Glide.  But I can't seem to find much of anything in
the mailing list archives.

Basically, if anybody out there has accelerated GL running (or close
to running) on either R128 or Voodoo3 hardware, I'm very interested
in helping you debug and test it.

   Tim Seufert

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

Re: 3D accel on PPC

[Michel Dänzer]

"Timothy A. Seufert" wrote:

> I *thought* I saw a message a few days ago about XF 4.x DRI work
> being done to make R128 3D accel run on PPC,

XF 4.0.1 will include DRI support for Rage128. However, it needs agpgart to
work, so no luck on PPC yet :(


Michel


--
I believe the technical term is "Oops!"
______________________________________________________________________________
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86, Team *AMIGA*, AUGS

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

Re: 3D accel on PPC

[Benjamin Herrenschmidt]

On Mon, Jun 19, 2000, Michel Dänzer <daenzerm@student.ethz.ch> wrote:

>
>XF 4.0.1 will include DRI support for Rage128. However, it needs agpgart to
>work, so no luck on PPC yet :(

Their implementation is not able to work at all without an AGP GART ?
That's brain-dead ! what about all the 3D PCI cards out there ? And all
the machines that simply don't have a working AGP ? AGP should be an
optimisation, not a requirement !

I have all the details (I think) to implement support for the Uni-N GART
in the new Core99 macs, I'll give this a try one of these days. But that
would be plain stupid not to support "classical" operations via PCI.

Ben.


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

Re: 3D accel on PPC

[Michel Dänzer]

Benjamin Herrenschmidt wrote:
>
> On Mon, Jun 19, 2000, Michel Dänzer <daenzerm@student.ethz.ch> wrote:
>
> >
> >XF 4.0.1 will include DRI support for Rage128. However, it needs agpgart to
> >work, so no luck on PPC yet :(
>
> Their implementation is not able to work at all without an AGP GART ?
> That's brain-dead !

Hmm... looking at recent changes in the DRI ati-4-0-1 branch, I spotted the
following:

- Added minimal PCI support (PIO only with no VBs)
  - Autodetect PCI cards -- selets CCE PIO mode and disables VBs
  - Kernel module will now build without AGP support (for PCI cards only)

Is this good news? If yes, let's hope it'll be in 4.0.1 ...


> what about all the 3D PCI cards out there ? And all the machines that simply
> don't have a working AGP ? AGP should be an optimisation, not a requirement!

Of course, but we are living in an x86 centric world *sigh*


> I have all the details (I think) to implement support for the Uni-N GART
> in the new Core99 macs, I'll give this a try one of these days.

Cool! What about the DRM module, any idea if it works?


Michel


--
Pauli's exclusive, Heisenberg's uncertain, and Schroedinger just waves.
______________________________________________________________________________
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86, Team *AMIGA*, AUGS

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

Re: 3D accel on PPC

[Kostas Gewrgiou]

On Sun, 18 Jun 2000, Timothy A. Seufert wrote:

>
> Has anybody made progress in getting 3D acceleration to work on PPC?
>
> I *thought* I saw a message a few days ago about XF 4.x DRI work
> being done to make R128 3D accel run on PPC, and I know Kostas
> Gewgriou (hope I spelled that right Kostas ;)

  Close, Georgiou is the correct one actually

> was doing work some
> time ago on 3Dfx Glide.  But I can't seem to find much of anything in
> the mailing list archives.
>

  The dri cvs tree (dri.sourceforge.net) has support for r128 and
xf 4.0.1 will include it as well. About PPC support now i don't
think that it will work out of the box (it might be easy to fix it
though).

I've send some time ago a couple of patches in dri
(not yet included in the tree, but you can get them from
http://sourceforge.net/patch/?group_id=387) that will let
you build the drm modules and XF/DRI. Since i know next to
nothing about ppc asm there are probably errors there, but
my voodoo3 was running fine with them ;P

What is holding back ppc voodoo3 in xfree right now
is PIO support, i tried to use tdfxfb to get away from
this but there a problems there as well (the xserver
needs a 2*vramsize mapping in the framebuffer but fbdev
can't do this unless i patch tdfxfb to think that its
vram is 2*realsize, Geert any ideas how we can get away
from this ?)


> Basically, if anybody out there has accelerated GL running (or close
> to running) on either R128 or Voodoo3 hardware, I'm very interested
> in helping you debug and test it.
>

  If you are willing to live with hardlocks/crashes etc i can send you
what i have for the voodoo3, GL (glide) works but i am missing some
byteswaps in texture transfers(?) in glide so the engince locks badly
and often :(


>    Tim Seufert
>

 Kostas


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

Re: 3D accel on PPC

[Geert Uytterhoeven]

On Mon, 19 Jun 2000, Kostas Gewrgiou wrote:
> What is holding back ppc voodoo3 in xfree right now
> is PIO support, i tried to use tdfxfb to get away from
> this but there a problems there as well (the xserver
> needs a 2*vramsize mapping in the framebuffer but fbdev
> can't do this unless i patch tdfxfb to think that its
> vram is 2*realsize, Geert any ideas how we can get away
> from this ?)

Why do they want 2*vramsize? Is the extra space where no RAM is used for
something different? Can they map something there?

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: 3D accel on PPC

[Kostas Gewrgiou]

On Tue, 20 Jun 2000, Geert Uytterhoeven wrote:

> On Mon, 19 Jun 2000, Kostas Gewrgiou wrote:
> > What is holding back ppc voodoo3 in xfree right now
> > is PIO support, i tried to use tdfxfb to get away from
> > this but there a problems there as well (the xserver
> > needs a 2*vramsize mapping in the framebuffer but fbdev
> > can't do this unless i patch tdfxfb to think that its
> > vram is 2*realsize, Geert any ideas how we can get away
> > from this ?)
>
> Why do they want 2*vramsize? Is the extra space where no RAM is used for
> something different? Can they map something there?
>

 In voodoo you can setup one part of the framebuffer as tiled memory,
access to this tiled memory needs more address space thats why a
mapping of 2*ram is needed.

  Kostas


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

Re: [linux-fbdev] Re: 3D accel on PPC

[Geert Uytterhoeven]

On Tue, 20 Jun 2000, Kostas Gewrgiou wrote:
> On Tue, 20 Jun 2000, Geert Uytterhoeven wrote:
> > On Mon, 19 Jun 2000, Kostas Gewrgiou wrote:
> > > What is holding back ppc voodoo3 in xfree right now
> > > is PIO support, i tried to use tdfxfb to get away from
> > > this but there a problems there as well (the xserver
> > > needs a 2*vramsize mapping in the framebuffer but fbdev
> > > can't do this unless i patch tdfxfb to think that its
> > > vram is 2*realsize, Geert any ideas how we can get away
> > > from this ?)
> >
> > Why do they want 2*vramsize? Is the extra space where no RAM is used for
> > something different? Can they map something there?
>
>  In voodoo you can setup one part of the framebuffer as tiled memory,
> access to this tiled memory needs more address space thats why a
> mapping of 2*ram is needed.

IC.

Is this tiled memory needed for a specific video mode, or is it independent of
the video mode? In the former case, set smem_len to 2*ram when switching to
that specific video mode; in the latter case, add an ioctl() to switch between
normal and tiled video mode, taking care of smem_len as well.

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/