Thanks Michel,
I *did* say I saw very new to this...
on Sun, Jul 30, 2000, Michel Dnzer wrote:
Iain Sandoe wrote:
[...]
Before building, you should have copied xc/config/cf/{xf86site,host}.def
Then edit the newly created host.def - you probably only want to build the
server and drivers, and choose the drivers you want.
Oh-oh.
This was a step missing from the instructions :-(
Maybe I complied a lot more than necessary (and hence the time)...
Would I need to build all the apps once (so that they are compatible?).
After that, I suppose, I just rebuild the driver when the rsync changes...
For DRI, you may have to edit even more files in config/cf/, AFAIK DRI is only
built on i386 by default.
Do I also need to enable different support in the kernel?
(e.g. /dev/agpart support ?)
(there's been a fair amount about different fb stuff flying around...)
(I have ATI{mach64,r128}/IMSTT support enabled by default - since these are
the cards I have).
Iain.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michel D�nzer <hidden> Date: 2000-07-31 07:50:48
Iain Sandoe wrote:
quoted
Before building, you should have copied xc/config/cf/{xf86site,host}.def
Then edit the newly created host.def - you probably only want to build the
server and drivers, and choose the drivers you want.
Oh-oh.
This was a step missing from the instructions :-(
Maybe I complied a lot more than necessary (and hence the time)...
Probably.
Would I need to build all the apps once (so that they are compatible?).
Not absolutely. Servers and clients should be compatible at any version each
(apart from a few issues, of course ;)
After that, I suppose, I just rebuild the driver when the rsync changes...
Yep, make -C xc/programs/Xserver should do. (And copying the modules to the
ModulePath again)
quoted
For DRI, you may have to edit even more files in config/cf/, AFAIK DRI is
only built on i386 by default.
Do I also need to enable different support in the kernel?
(e.g. /dev/agpart support ?)
That would be good, but AFAIK there's no such thing for our hardware yet.
You'll have to go to
xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel and do make -f
Makefile.linux (won't build out of the box - I've added '#include
<asm/pgtable.h> to drmP.h and changed the function in r128_dma.c containing
i386 assembly to just call mb() - anyone knows if this makes sense?) and then
modprobe r128.o
(I have ATI{mach64,r128}/IMSTT support enabled by default - since these are
the cards I have).
Only the r128 is even theoretically supported by DRI ATM.
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/
From: Michel D�nzer <hidden> Date: 2000-07-31 08:47:35
Steffen Haeuser wrote:
quoted
quoted
Do I also need to enable different support in the kernel?
(e.g. /dev/agpart support ?)
quoted
That would be good, but AFAIK there's no such thing for our hardware yet.
Exactly this is AFAIK currently the problem as to 3D Hardware support...
the /dev/agpart support...
agpgart was required _for r128 DRI_ until some time ago. It's possible that
it's still needed by the driver in X 4.0.1 but definitely not in the latest
DRI CVS.
a solution might be to use GLX instead of DRI ... after all since 4.0 Beta X
Server Driver there *is* support for GLX in the LinuxPPC X Server...
Yep, and DRI adds hardware acceleration to it.
quoted
You'll have to go to
xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel and do make -f
Makefile.linux (won't build out of the box - I've added '#include
<asm/pgtable.h> to drmP.h and changed the function in r128_dma.c containing
i386 assembly to just call mb() - anyone knows if this makes sense?) and
then modprobe r128.o
Hmmm... what sort of ASM is this ?
It's for flushing write combining buffers AFAIR, thus I thought an mb() should
do on PPC.
Is this the only reason why agpart is not supported on Mac yet, some lines
of ASM ?
This is not about agpgart at all but about the DRM (direct rendering manager,
the kernel part of DRI) kernel module.
(Well, AFAIK it is not even confirmed if this AGPart thing works with PCI,
but AFAIK it was said that it "should").
PCI is not AGP, thus I don't think agpgart can work on PCI. There's also PCI
GART, but there isn't PPC support for it either yet.
The most clever thing probably would be to do a GLX Driver (which does not
require this AGPart thing...). Of course all also depends if Chipset
information is available.
To do such a driver should be possible in 3-4 weeks at most... I know of
what I am speaking as before Hyperion existed people of our company did the
3D Drivers for the Amiga 3D Boards, and I know how long THEY took for a 3D
Driver... (and before someone asks: No, these people are 100% busy with game
coding now... no time for drivers...).
I doubt it would be as easy on Linux - much more complexity to deal with than
on AmigaOS :)
Michel
--
Hark! What rock through yonder window breaks?
______________________________________________________________________________
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/
From: Michel D�nzer <hidden> Date: 2000-07-31 09:03:14
Steffen Haeuser wrote:
quoted
agpgart was required _for r128 DRI_ until some time ago. It's possible that
it's still needed by the driver in X 4.0.1 but definitely not in the latest
DRI CVS.
That is really good news :) If anyone had the chance to try it out, please
tell so...
Hold on, I will :)
if this works, we might even take some of you guys into the Sin Beta Tester
programs, if I remember right, we still need a handful of testers (but I
have to check with the guy doing the Betatester issues in our company...).
I for one wouldn't say no...
Driver Coding normally has not that much to do with the OS... :)
The main work is to find out how this Chip works, and then duplicate the
functionality of an API by using the Chip Registers (and some of those
sometimes do things in a *really cruel way*... some years ago I had to do
some stuff on the old Virge chip...
this was nasty...) The difficult is usually the register setup... not the
interface to the OS...
AFAIK the specs for Rage128 aren't publicly available, but there's working
code in DRI - I'm convinced it will be far more easier to get it working than
write something new from scratch.
Michel
--
UNIX is like Sex:
If you don't know it, you don't miss it. But if you know it, you'll need it.
______________________________________________________________________________
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/
For DRI, you may have to edit even more files in config/cf/, AFAIK DRI is
only built on i386 by default.
Do I also need to enable different support in the kernel?
(e.g. /dev/agpart support ?)
That would be good, but AFAIK there's no such thing for our hardware yet.
Exactly this is AFAIK currently the problem as to 3D Hardware support...
the /dev/agpart support... a solution might be to use GLX instead of
DRI ... after all since 4.0 Beta X Server Driver there *is* support for GLX
in the LinuxPPC X Server...
You'll have to go to
xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel and do make -f
Makefile.linux (won't build out of the box - I've added '#include
<asm/pgtable.h> to drmP.h and changed the function in r128_dma.c containing
i386 assembly to just call mb() - anyone knows if this makes sense?) and then
modprobe r128.o
Hmmm... what sort of ASM is this ? Is this the only reason why agpart is not
supported on Mac yet, some lines of ASM ? (Well, AFAIK it is not even
confirmed
if this AGPart thing works with PCI, but AFAIK it was said that it "should").
quoted
(I have ATI{mach64,r128}/IMSTT support enabled by default - since these are
the cards I have).
Only the r128 is even theoretically supported by DRI ATM.
I think a lot people confuse 2D Hardware Accelerated with 3D Hardware
Accelerated
Support. There *is* already 2D Hardware Acceleration for LinuxPPC, but not
3D...
The most clever thing probably would be to do a GLX Driver (which does not
require
this AGPart thing...). Of course all also depends if Chipset information is
available.
To do such a driver should be possible in 3-4 weeks at most... I know of what
I am speaking
as before Hyperion existed people of our company did the 3D Drivers for the
Amiga
3D Boards, and I know how long THEY took for a 3D Driver... (and before
someone
asks: No, these people are 100% busy with game coding now... no time for
drivers...).
Steffen
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
agpgart was required _for r128 DRI_ until some time ago. It's possible that
it's still needed by the driver in X 4.0.1 but definitely not in the latest
DRI CVS.
That is really good news :) If anyone had the chance to try it out, please
tell so...
if this works, we might even take some of you guys into the Sin Beta Tester
programs,
if I remember right, we still need a handful of testers (but I have to check
with
the guy doing the Betatester issues in our company...).
It's for flushing write combining buffers AFAIR, thus I thought an mb()
should
do on PPC.
Yeah, think you should be right here... :)
quoted
(Well, AFAIK it is not even confirmed if this AGPart thing works with PCI,
but AFAIK it was said that it "should").
PCI is not AGP, thus I don't think agpgart can work on PCI. There's also PCI
GART, but there isn't PPC support for it either yet.
Well, the author of AGPart was cited that he "thinks it should work on PCI
too".
I cannot comment further on it. But if DRI does not require it any longer,
anyways,
seems this is no longer an issue :)
I doubt it would be as easy on Linux - much more complexity to deal with than
on AmigaOS :)
Driver Coding normally has not that much to do with the OS... :)
The main work is to find out how this Chip works, and then duplicate the
functionality
of an API by using the Chip Registers (and some of those sometimes do things
in a
*really cruel way*... some years ago I had to do some stuff on the old Virge
chip...
this was nasty...) The difficult is usually the register setup... not the
interface
to the OS...
Steffen
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
That is really good news :) If anyone had the chance to try it out, please
tell so...
Hold on, I will :)
Great :)
quoted
if this works, we might even take some of you guys into the Sin Beta Tester
programs, if I remember right, we still need a handful of testers (but I
have to check with the guy doing the Betatester issues in our company...).
I for one wouldn't say no...
Hehehe, who would...
AFAIK the specs for Rage128 aren't publicly available, but there's working
code in DRI - I'm convinced it will be far more easier to get it working than
write something new from scratch.
On Mon, 31 Jul 2000, Michel [iso-8859-1] Dδnzer wrote:
Steffen Haeuser wrote:
quoted
quoted
quoted
Do I also need to enable different support in the kernel?
(e.g. /dev/agpart support ?)
quoted
That would be good, but AFAIK there's no such thing for our hardware yet.
Exactly this is AFAIK currently the problem as to 3D Hardware support...
the /dev/agpart support...
agpgart was required _for r128 DRI_ until some time ago. It's possible that
it's still needed by the driver in X 4.0.1 but definitely not in the latest
DRI CVS.
If i remember corectly 4.0.1 doesn't need agpgart but i fear that 3d
performance is far worst without it.
quoted
quoted
You'll have to go to
xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel and do make -f
Makefile.linux (won't build out of the box - I've added '#include
<asm/pgtable.h> to drmP.h and changed the function in r128_dma.c containing
i386 assembly to just call mb() - anyone knows if this makes sense?) and
then modprobe r128.o
Hmmm... what sort of ASM is this ?
It's for flushing write combining buffers AFAIR, thus I thought an mb() should
do on PPC.
The mb() should be enough in r128_dma.c (we might not need it at all though
but it shouldn't hurt). The R128_WRITE/R128_READ macros in r128_drv.h will
need to do byteswapping also i imagine.
The writes to the CCE ring buffer might be a problem also you might need
to do different swaps depending on where the buffer lives (host memory or
in the framebuffer) since the framebuffer writes get swapped depending on
the current depth. (voodoo3 has this problem)
The drm modules need some asm code as well, look at my patches in
dri.sourceforge.net (patch_id 100488,100568) the code is almost a copy
from the glibc sources (i know next to nothing about ppc asm) but they
work well with my voodoo3.
Also note that the DRI drivers don't get build by default in PPC
you have to #define BuildXF86DRI YES in xf config files *AND*
patch xc/lib/GL/mesa/src/drv/Imakefile to enable the dri drivers
to build under ppc.
Unfortunately i don't have an r128 card so i can't do anything here :(
Kostas Gewrgiou
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/