From: Kostas Gewrgiou <redacted>
Subject: Re: Some issues to resolve with XFree 4.0 yet
quoted
You then asked me to look at getting it to work without using the FBDev. Given
my earlier patch which calculates XCLK using OF supplied values in the pll
registers, all you need to do to use it without FBDev is to simply comment out
the calls to vgaHWSave and vgaHWRestore in r128_driver.c.
You will also need to add code to switch the framebuffer in the right
endian for the depth and probably disable the int10 module.
Yes, you're right. The r128 driver is now working fine on my B&W G3 without
fbdev support in 8/15/16/24 bit depth so far, except one problem -- offb
console becomes blank screen on VT switch(I'm not using aty128fb). r128 driver
doesn't seem to restore the original state perfectly. But this isn't harmless
because I have running second and third head(with xinerama).
Thats a good question, right now they don't work at all under ppc for
drivers that don't switch vgahw to MMIO.
So I disabled all vgahw access to prevent seg. fault. I think Rage128
VGA register access is not necessary at least for powermacs.
quoted
I think the only outstanding issue on r128 is the damn flashing white square
when cursor images are changed. I have looked and looked at this but I can't
figure out why this is happening unless a big white square is someone's
idea of a transparent cursor! ;-)
This is strange, from what i see in the driver it hides the cursor before
loading the image so i can't imagine why you get the artifacts
Though I could be wrong, it may not be strange. R128LoadCursorImage()
starts display cursor immediately after the cursor image is written
to the frame buffer, but rage128 frame buffer write is always FIFO'ed
while CRTC write is never FIFO'ed. So it'll be possible to start display
cursor before the image write is complete.
In my case I commented out cursor ON/OFF code in R128LoadCursorImage()
since mid-level routine calls R128HideCursor/R128ShowCursor before and
after cursor image is loaded. I haven't seen this cursor flashing yet.
BTW, I noticed an interesting x11perf score. x11perf -scroll500 marked ~300/sec
for ATI Rage128RE connected to 66MHz bus on B&W G3 rev.1, but ~600/sec for an
old Matrox Millennium II to 33MHz bus, measured at 32bpp/24bit depth.
Regards,
Ryuichi Oikawa
roikawa@rr.iij4u.or.jp
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
On Tue, 28 Mar 2000, Ryuichi Oikawa wrote:
BTW, I noticed an interesting x11perf score. x11perf -scroll500 marked ~300/sec
for ATI Rage128RE connected to 66MHz bus on B&W G3 rev.1, but ~600/sec for an
old Matrox Millennium II to 33MHz bus, measured at 32bpp/24bit depth.
are you using the patch I posted last week? If not, then I suggest you
do. I fixed the improper load/stores in r128 and it shows a 200% increase
in almost all x11perf tests. example:
(jack howarth tested these on his g4/450 (rage 128pro?)):
before:
Scroll 500x500 pixels: 583.0/sec
after:
Scroll 500x500 pixels: 1060.0/sec
Ryuichi Oikawa
roikawa@rr.iij4u.or.jp
ani
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Hi Ani and Ryuichi,
are you using the patch I posted last week? If not, then I suggest you
do. I fixed the improper load/stores in r128 and it shows a 200% increase
in almost all x11perf tests.
Actually, you might want to try Gabriel Paubert's patch which simply
removes the "volatile" from the base_addr parameter. The incirrectly
specified volatile on the parameter (which really makes no sense if you
think about it ;-)) is what was causing all the problems with inefficiency.
Interestingly, with this patch you can actually save one extra instruction
over Ani's patch but either one is a big big improvement.
Kevin
----snip-here-for Gabriel_Paubert's_e-mail_with_patch----
Hi,
quoted
From comparing the performance of the XFree 4.0 r128 drivers across x86 and
ppc we noticed that the ppc version was much slower. The following patch
made a huge change in x11perf results (improivement). This is on a ppc
with glibc 2.1.3 and the latest gcc 2.95.2 from Franz Sirl.
Did I write the output constraint version incorrectly? Is this what you
expected the generated code to look like?
I have just made a test with suppressing the volatile in the parameter to
the regr/regw/regr16/regw16 macros and the code is even better (one
instruction less than with the memory clobber):
000003d4 <R128Blank>:
3d4: 81 43 00 f8 lwz r10,248(r3)
3d8: 81 6a 00 24 lwz r11,36(r10)
3dc: 39 20 00 54 li r9,84
3e0: 7c 09 5c 2c lwbrx r0,r9,r11
3e4: 7c 00 06 ac eieio
3e8: 60 00 04 00 ori r0,r0,1024
3ec: 7c 09 5d 2c stwbrx r0,r9,r11
3f0: 7c 00 06 ac eieio
3f4: 4e 80 00 20 blr
the diff is:--- r128_reg.h~ Sat Feb 26 06:38:43 2000
+++ r128_reg.h Fri Mar 24 23:47:31 2000
@@ -48,19 +48,19 @@
#if defined(__powerpc__)
-static inline void regw(volatile unsigned long base_addr, unsigned long
regindex, unsigned long regdata)
+static inline void regw(unsigned long base_addr, unsigned long regindex,
unsigned long regdata)
{
asm volatile ("stwbrx %1,%2,%3; eieio"
: "=m" (*(volatile unsigned *)(base_addr+regindex))
: "r" (regdata), "b" (regindex), "r" (base_addr));
}
-static inline void regw16(volatile unsigned long base_addr, unsigned long
regindex, unsigned short regdata)
+static inline void regw16(unsigned long base_addr, unsigned long regindex,
unsigned short regdata)
{
asm volatile ("sthbrx %0,%1,%2; eieio": : "r"(regdata), "b"(regindex),
"r"(base_addr));
}
-static inline unsigned long regr(volatile unsigned long base_addr,
unsigned long regindex)
+static inline unsigned long regr(unsigned long base_addr, unsigned long
regindex)
{
register unsigned long val;
asm volatile ("lwbrx %0,%1,%2; eieio"@@ -70,7 +70,7 @@
return(val);
}
-static inline unsigned short regr16(volatile unsigned long base_addr,
unsigned long regindex)
+static inline unsigned short regr16(unsigned long base_addr, unsigned long
regindex)
{
register unsigned short val;
asm volatile ("lhbrx %0,%1,%2; eieio": "=r"(val):"b"(regindex),
"r"(base_addr));
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/