Messages in this thread Patch in this message | | | From | "Petr Vandrovec Ing. VTEI" <> | Date | Mon, 4 Jan 1999 20:23:33 MET-1 | Subject | matroxfb, speed and compatibility + PATCH |
| |
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/
| |