From: Michel D�nzer <hidden> Date: 2000-08-04 15:03:51
[For the linuxppc-dev people: this is about the DRI CVS trunk]
Kostas Gewrgiou wrote:
quoted
GL clients even seem to attempt direct rendering now, however I get one of
two different errors every time:
Error: Rage 128 timed out... exiting
Error: Could not submit packet... exiting
From what i see the problem is probably in the R128_READ/WRITE macros in
r128_drv.h you need byteswapping functions there (and memory barriers as
usual).
That did it, thanks! I changed those macros to use the same inline functions
which are used for MMIO_{IN,OUT} on PPC, and here we go!
The remaining problems are:
16 bit doesn't work neither with fbdev (colors completely off - does aty128fb
still use 15 bit in fact?) nor without (at least the grey tones are right
there - wrong endianness?)
At 32 bit, it flickers badly on my Pismo, probably because it only has 8 megs
of VRAM. (These messages appear in the log:
(EE) r128(0): Unable to reserve depth buffer
(EE) r128(0): Unable to reserve texture space in frame buffer
) Curious how it works out for people with more...
About performance: It's much better than software rendering (at least for big
windows) of course, however not too fast with lots of polygons. AGP GART would
definitely be a good thing I guess (Ben: hint, hint :)
Still, big kudos to the DRI team for a great work!
Michel
--
Sometimes you have to stride boldly up to life,
look it straight in the eye, and say "huh?"
______________________________________________________________________________
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-08-04 17:03:17
Michel Dänzer wrote:
16 bit doesn't work neither with fbdev (colors completely off - does
aty128fb still use 15 bit in fact?)
fbset -i reveals that it does.
Is anyone actively maintaining aty128fb or should I try to fix that as well as
the panning? Looking at the X r128 driver, it shouldn't be too hard.
Michel
--
Coming to you live from a finite point in the space-time continuum!
______________________________________________________________________________
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-08-05 14:35:41
Benjamin Herrenschmidt wrote:
[about aty128fb setting the RAMDAC to 15 bit for depth 16]
quoted
fbset -i reveals that it does.
Is anyone actively maintaining aty128fb or should I try to fix that as
well as the panning? Looking at the X r128 driver, it shouldn't be too
hard.
Brad Douglas, but he doesn't have a PPC machine.
Okay, I'll contact him, thanks.
My priority is to get 16 bit working, panning isn't so important for me
because only one mode works on the Pismo anyway.
Unfortunately, I don't have time over the weekend, but I'm cooking up a patch
X 4.0.1 -> DRI CVS which I'm sending to the people involved.
Michel
--
I'm so hungry, I could almost eat health food.
______________________________________________________________________________
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/
On Fri, 4 Aug 2000, Michel [iso-8859-1] Dδnzer wrote:
[For the linuxppc-dev people: this is about the DRI CVS trunk]
Kostas Gewrgiou wrote:
quoted
quoted
GL clients even seem to attempt direct rendering now, however I get one of
two different errors every time:
Error: Rage 128 timed out... exiting
Error: Could not submit packet... exiting
From what i see the problem is probably in the R128_READ/WRITE macros in
r128_drv.h you need byteswapping functions there (and memory barriers as
usual).
That did it, thanks! I changed those macros to use the same inline functions
which are used for MMIO_{IN,OUT} on PPC, and here we go!
Great news :)
The remaining problems are:
16 bit doesn't work neither with fbdev (colors completely off - does aty128fb
still use 15 bit in fact?) nor without (at least the grey tones are right
there - wrong endianness?)
Yes aty128fb still doesn't support 16 bit, you could run the r128 driver
without fbdev to get 16 bits, but the code to switch the framebuffer to do
byteswapping is missing so the colors will be wrong (easy to add though).
At 32 bit, it flickers badly on my Pismo, probably because it only has 8 megs
of VRAM. (These messages appear in the log:
(EE) r128(0): Unable to reserve depth buffer
(EE) r128(0): Unable to reserve texture space in frame buffer
) Curious how it works out for people with more...
Not enough memory for all the buffers indeed, you could try with a lower
res (if prismo allows that) to save some memory.
About performance: It's much better than software rendering (at least for big
windows) of course, however not too fast with lots of polygons. AGP GART would
definitely be a good thing I guess (Ben: hint, hint :)
Do you have any numbers from gears, glquake etc ??
Kostas
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Benjamin Herrenschmidt <hidden> Date: 2000-08-05 18:43:51
quoted
At 32 bit, it flickers badly on my Pismo, probably because it only has
8 megs
quoted
of VRAM. (These messages appear in the log:
(EE) r128(0): Unable to reserve depth buffer
(EE) r128(0): Unable to reserve texture space in frame buffer
) Curious how it works out for people with more...
Not enough memory for all the buffers indeed, you could try with a lower
res (if prismo allows that) to save some memory.
The Pismo allows that by scaling the LCD, but I don't think code for that
is implemented in the XFree r128 driver (I didn't check lately).
Ben.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
About performance: It's much better than software rendering (at least for big
windows) of course, however not too fast with lots of polygons. AGP GART would
definitely be a good thing I guess (Ben: hint, hint :)
Do you have any numbers from gears, glquake etc ??
Is someone working on the AGP GART module for PPC Linux? Without that,
you're stuck with PIO mode which can be slower than software rendering.
Again, I'd love to help you guys out. Do you have patches we could look
at?
-- Gareth
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michel D�nzer <hidden> Date: 2000-08-07 07:08:01
Benjamin Herrenschmidt wrote:
quoted
quoted
At 32 bit, it flickers badly on my Pismo, probably because it only has
8 megs
quoted
of VRAM. (These messages appear in the log:
(EE) r128(0): Unable to reserve depth buffer
(EE) r128(0): Unable to reserve texture space in frame buffer
) Curious how it works out for people with more...
Not enough memory for all the buffers indeed, you could try with a lower
res (if prismo allows that) to save some memory.
The Pismo allows that by scaling the LCD, but I don't think code for that
is implemented in the XFree r128 driver (I didn't check lately).
No it doesn't work, neither with aty128fb. Would that be hard to implement?
Michel
--
If the box says `Windows 95 or better'', it should run on Linux, right?
______________________________________________________________________________
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-08-07 07:14:10
Kostas Gewrgiou wrote:
quoted
The remaining problems are:
16 bit doesn't work neither with fbdev (colors completely off - does
aty128fb still use 15 bit in fact?) nor without (at least the grey tones
are right there - wrong endianness?)
Yes aty128fb still doesn't support 16 bit, you could run the r128 driver
without fbdev to get 16 bits, but the code to switch the framebuffer to do
byteswapping is missing so the colors will be wrong
Yep, that's the second thing I was referring to.
(easy to add though).
Where and how?
quoted
About performance: It's much better than software rendering (at least for
big windows) of course, however not too fast with lots of polygons. AGP
GART would definitely be a good thing I guess (Ben: hint, hint :)
Do you have any numbers from gears, glquake etc ??
The numbers are very varying and not too high yet. AGP GART should change
that.
Michel
--
Tax the rich.
______________________________________________________________________________
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/
On Mon, 7 Aug 2000, Michel [iso-8859-1] Dδnzer wrote:
Kostas Gewrgiou wrote:
quoted
quoted
The remaining problems are:
16 bit doesn't work neither with fbdev (colors completely off - does
aty128fb still use 15 bit in fact?) nor without (at least the grey tones
are right there - wrong endianness?)
Yes aty128fb still doesn't support 16 bit, you could run the r128 driver
without fbdev to get 16 bits, but the code to switch the framebuffer to do
byteswapping is missing so the colors will be wrong
Yep, that's the second thing I was referring to.
quoted
(easy to add though).
Where and how?
Somewhere in R128ModeInit (or the functions that get called from it) will
do fine i think.
About how now look at the following code from aty128fb that does the same
thing.
config = aty_ld_le32(CONFIG_CNTL) & ~3;
#if defined(__BIG_ENDIAN)
if (par->crtc.bpp >= 24)
config |= 2; /* make aperture do 32 byte swapping */
else if (par->crtc.bpp > 8)
config |= 1; /* make aperture do 16 byte swapping */
#endif
aty_st_le32(CONFIG_CNTL, config);
Kostas
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Sven Goethel <hidden> Date: 2000-08-07 19:51:34
Dear r128/ppc developers,
I do follow your discussion for some days with a lot of
euphorism. I want to try hardware acceleration with my powerbook,
XF401+DRI for the GL4Java development.
Just a few questions:
- which kernel ? (I currently use 2.4.0-test5)
- XF4.0.1 ?
- When and/or where can I get the working r128 linux kernel
sources for ppc - they seemed not to be included in the current CVS
tree.
I only get a LOCK_PREFIX unknown ...
Thanxs a lot for your engagement and time.
Yours, Sven
--
mailto:sgoethel@jausoft.com
www : http://www.jausoft.com ; pgp: http://www.jausoft.com/gpg/
voice : +49-521-2399440, +49-170-2115963; fax: +49-521-2399442
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michel D�nzer <hidden> Date: 2000-08-08 08:46:51
Sven Goethel wrote:
- which kernel ? (I currently use 2.4.0-test5)
That should be fine, at least it works for me with test4 and test6 :)
- XF4.0.1 ?
Maybe. I've got it working using the DRI CVS trunk, but the differences
against X4.0.1 are minor.
- When and/or where can I get the working r128 linux kernel
sources for ppc - they seemed not to be included in the current
CVS tree.
I only get a LOCK_PREFIX unknown ...
Apply the patch I have posted to the linuxppc-dev list yesterday. I can send
it to you privately if you can't get it for some reason.
Michel
--
The computer revolution is over. The computers won.
______________________________________________________________________________
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-08-08 08:51:15
Kostas Gewrgiou wrote:
quoted
quoted
[...] you could run the r128 driver without fbdev to get 16 bits, but
the code to switch the framebuffer to do byteswapping is missing so the
colors will be wron (easy to add though).
Where and how?
Somewhere in R128ModeInit (or the functions that get called from it) will
do fine i think.
I'll be trying in R128{Save,Restore}Crtc... , adding a config field to the
...Save... struct for the CONFIG_CNTL register. Does that make sense?
About how now look at the following code from aty128fb that does the same
thing.
config = aty_ld_le32(CONFIG_CNTL) & ~3;
#if defined(__BIG_ENDIAN)
if (par->crtc.bpp >= 24)
config |= 2; /* make aperture do 32 byte swapping */
else if (par->crtc.bpp > 8)
config |= 1; /* make aperture do 16 byte swapping */
#endif
aty_st_le32(CONFIG_CNTL, config);
Thanks, that code also caught my eye this morning on the train :)
Michel
--
Why drink & drive when you can smoke and fly???
______________________________________________________________________________
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/