matroxfb, speed and compatibility + PATCH

Petr Vandrovec Ing. VTEI (VANDROVE@vc.cvut.cz)
Mon, 4 Jan 1999 20:23:33 MET-1

Hello everyone,
I just catch up to linux-kernel (last message I have recieved yet is
from Jan 3, 19:22) and I see that there are some problems...
I do not understand, why most of these peoples did not contact me,
but this is not a big problem, except that Linus have probably something
more important to read and is now a bit angry...
So, first to the compatibility. Matroxfb should work together with
XF86_SVGA 3.3.2 and 3.3.3 (on ia32), with Millennium I, Millennium II,
Mystique, Mystique 220 and any G200 (Mystique, Millennium or Marvel).
Tested (by me) is Millenium G200 together with XF3.3.3, Millenium I with
XF3.3.2 and 3.3.3, and Millenium II with XF3.3.2 (with latest driver from
vger). During autumn (October), I have borrowed Mystique - it worked in
combination Mystique - XF3.3.2. I have no access to another hardware, so
G100 does not work - I'm not sure why, but it simple does not. Because of
Matrox REFUSED to release data sheets for G100 and G200 to me (it happened
during September with reference that XF team received some papers under
NDA), driver is written AS IS and I can make it better only by reports
from users which have 'non working' hardware.
Driver MUST do complete initialization because of it supports multihead
and have to work on non-ia32 architectures. But because of programming is
not revealed, it is written as is. Because of this there is an option
(video=matrox:noinit), which disables initialization done by driver. In this
case, BIOS (VideoBIOS) is responsible to enable memory refresh and must
program appropriate values to memory configuration registers and to
MCLK and GCLK (memory interface and graphics engine clocks) It should cure
some problems, I hope, but because of I have not got any reply to this
hint, I do not know.
I do not know, why new driver should be slower than old under X. Sorry,
I do not see that problem here.
Last version (1.8) also supports SVGALib - but you must start program
from text mode console (in VGA compatible mode; because of SVGALib is not
aware about Matrox and access it as stupid simple IBM VGA, 640x480x16 or
320x400x256 max.). I've tested sdoom with Millennium I and Millennium G200
in this configuration. There is problem that SVGALib does not restore
screen after exit (I think that this happens because of /dev/vcsa cannot
be mmapped, but I'm not sure). If you switch from one console to another,
everything is fine and screen is restored correctly (still, sdoom and some
SVGALib examples as test programs).
There are compatibility problems on Alpha and on PReP PowerPC. Alpha
problem is worse, because AFAIK linear framebuffer is not available through
normal memory accessing instructions, so logo painting code oopses. I have
had one report from early December that someone managed it to work as
module together with tgafb.
On PReP there is problem that (at least my) firmware initialize only first
video adapter - and because of Millenium I (my test card for PPC) requires
specific initialization - I have to plug both Millenium I and a Cirrus in
that box and use special kernel loader (preploader) which assigns MMIO
addresses to all devices. Except that, addresses in PCI information structure
are addresses seen from PCI side and not from CPU side - you have to
add 0xC0000000 to obtained address before calling ioremap; or better,
add _ISA_MEM_BASE (0xD0000000) and skip call to ioremap (and iounmap).
I do not know when I finish integration with PPC and Alpha - ia32 speed
problems looks like showstopper for Linus.
Now, speed. Unfortunately, I have to confirm, that x11perftest running
on XF86_SVGA shows performance difference when running on the top of
matroxfb. Difference depends on whether matroxfb was loaded with
'noinit' or not. If you load it with noinit, performance is same as
(sometime (much) better than) without matroxfb, if you load it without
noinit, performance is better for (probably unaccelerated) tests, like
Dot, 1x1 Rectangle (on same speed as matroxfb noinit). Unfortunately, some
accelerated tests are slower, worstest is 500x500 rectangle - only 18%
of nofb or noinit... Other tests are 97-102% of nofb value, so almost
same (I run x11perf with repeat=2 time=1 due to time limits). Full report
is available at
ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/matrox.speed.

I'm including patch which I'm posting separate to Linus - it defaults
to noinit, so there should not be more problems with SGRAM/SDRAM detection.
It is probably best solution as I'm not aware how to distinguish between
SDRAM and SGRAM - except reading BIOS info - if someone is aware, please
share this with me, I know nothing about this topic except diagrams and
tables from MGA1064SG manual.

In short:
1600x1200x8bpp, G200 + PII/350
XF86_SVGA XF86_FBDEV
without | matroxfb | matroxfb | matroxfb
matroxfb | -noinit | +noinit | -noinit
Dot 3810000 + 7% + 7% + 24% (fbdev is 24% faster :-) )
Rect1x1 1090000 0 0 +124%
Rect500x500 10100 - 82% * + 1% - 95%
500x500opaque stippled rectangle
1800 + 1% + 1% - 88%
500x500tiled rectangle, 161x145 tile
129 +126% +126% +126% **
500x500tiled rectangle, 216x208 tile
143 +217% +214% +193% **

* speed for this operation (1800/s) is same as for (unaccelerated) 'opaque
stippled rectangle'. It is possible that there is some misdetection in
XFree code caused by clearing 'SGRAM' flag in capabilities of device (could
someone with 'true' SDRAM G200 test difference between 500x500 rectangle
and 500x500 opaque stippled rectangle (without matroxfb))
** this is probably caused by MTRR settings

Also, DO NOT enable both vesafb and matroxfb unless you have VESA2.0
non-matrox device in computer together with matroxfb. It cannot do anything
good except that you can have black or corrupted screen because of both
vesafb and matroxfb competes over one hardware (possibly together with
vgacon; but you should not use switch `video=vc:X-Y' if matroxfb is
your primary display - matroxfb is able to take over vgacon, but is
not able to share device with matroxfb. It is impossible with current API
and I think that there is no reason for it. (there is call to switch to
console, but there is no call that VT is releasing console; so it is not
possible to return hardware to vgacon acceptable state on modeswitch;
and, eventualy, this fast switching from (for example) 1024x768x32bpp ->
-> 640x400xText -> 1048x480xText (set by SVGATextMode) can destroy monitor)).
And, as general rule, if you have matroxfb and you have problems with it,
try 'video=matrox:noinit'. I hope that it solves most of problems. You
can specify 'noinit' in multihead configuration too, first 'head' will
not be initialized, other will be initialized from scratch, so no
problem should occur (it should work on non-intel too).

So, sorry for this long letter, ... Also sorry if there are not so easy
understandable sentences, I'm not so good in English and I'm writting
this letter for two hours now, together with hacking PPC, ncpfs and
'real' work. But I hope that this can clear some problems which are
occuring with matroxfb.
Best regards,
Petr Vandrovec
vandrove@vc.cvut.cz

Last minute: linux-kernel #3099, Jan 3, 23:22, just arrived...
I have to thank to Gerd Knorr for his accelerated fbcon server for
matrox. I did not test it yet (could you send me a patch... thanks),
but I hope that it will help me in my work...
I think that your problem with S3 is that S3 decodes whole 64MB,
thus using 0xF8000000 - 0xFFFFFFFF. Could you try to set S3 base to
(for example) 0xE0000000 (insert some code into PCI initialization,
basically pciwritelong(pcifinddevice(...), 0x10, 0xE0000000) - or
pcibioswritelong(bus,dev,fn,0x10,0xE0000000)).

P.S.: I also found that XF86_SVGA disables 'no_pci_retry' on my device
(with or without matroxfb) without any such command in XF86Config. Is
it feature or bug? It is SMP board based on 440BX and neither Video BIOS
nor Win95 driver disables it.

P.P.S.: Here is a promised patch; you can revert to old behavior by
'video=matrox:init', it is for 2.2.0-pre4, but should also work for
vger and anything after 2.1.132-pre3.

--- linux/drivers/video/matroxfb.c.old Mon Dec 21 23:48:04 1998
+++ linux/drivers/video/matroxfb.c Mon Jan 4 20:13:26 1999
@@ -2,9 +2,9 @@
*
* Hardware accelerated Matrox Millennium I, II, Mystique and G200
*
- * (c) 1998 Petr Vandrovec <vandrove@vc.cvut.cz>
+ * (c) 1998,1999 Petr Vandrovec <vandrove@vc.cvut.cz>
*
- * Version: 1.8 1998/12/11
+ * Version: 1.9 1999/01/04
*
* MTRR stuff: 1998 Tom Rini <tmrini@ntplx.net>
*
@@ -4841,7 +4841,7 @@
static int no_pci_retry = 0; /* "matrox:nopciretry" */
static int novga = 0; /* "matrox:novga" */
static int nobios = 0; /* "matrox:nobios" */
-static int noinit = 0; /* "matrox:noinit" */
+static int noinit = 1; /* "matrox:init" */
static int inverse = 0; /* "matrox:inverse" */
static int hwcursor = 1; /* "matrox:nohwcursor" */
static int blink = 1; /* "matrox:noblink" */

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/