G400 & KX-133 Wierdness...

[Neubi]

Hi!

Please read the messages which I wrote to JohnT at this topic:
http://forums.murc.ws/ubb/Forum5/HTML/008493.html

It's possible that it helps also for your problem.

Neubi

------------------

[Damien Green]

Also look at the topic I posted - K7A, G400 Max and AGP speed problem , Tom's hardware guide for this Motherboard helped me and Nuno.



[This message has been edited by Damien Green (edited 03 May 2000).]

[ID]

G400 & KX-133 Wierdness...

Hi all,

I've run into some confusing issues running a G400 Max on a KX133 Athlon Motherboard (Abit KA7). I've been through a wide variety of drivers for the VIA AGP and the G400 (see below), and apart from slight variances in the performance figures the behaviour of all drivers is the same.

Basically the system is stable and appears to be working correctly. Test applications are 3D Mark 2000, Final Reality 1.01 and the G400 Tech Demo. Any of these applications can be run indefinitely and do not exhibit any problems (apart from being slower than they were when using an AMD-750 chipset board with the same hardware).

Forcing the system to use 1x, 2x or 4x AGP transfers using the "AGPFlags" Matrox driver registry hack appears to work correctly (as far as can be seen with WCPUID), and does not affect stability. Without forcing an AGP speed the system fails to boot 1 in 10 times (cold or warm boot) displaying a green stripe at the top of the display when Windows first tries to display the desktop (Win98) or a scrambled display (Win2000). If the AGP speed is forced then this does not occur (in Win98, I'm not sure how to force the AGP speed in Win2000). In all failure cases, rebooting the machine solves the problem. As far as I can understand, forcing the AGP speed via the "AGPFlags" registry setting, disables an AGP test that the Matrox driver does on initialisation. It appears as if this test sometimes (1 in 10 times) crashes the machine. Apart from the 1 in 10 failure to boot the machine never locks up or crashes once it has booted correctly.

This would all be OK(ish) if it weren't for the fact that the G400 exhibits much slower performance on the VIA KX133 chipset motherboard than it does on the AMD 'IronGate' 750 chipset motherboard. On closer investigation, it appears as if the cause of this slowdown is a dramatically reduced 3D bus transfer speed.

One of the items benchmarked by Final Reality are bus transfers speed for 2D and 3D graphics. Typically (ie. on non KX133 motherboards) the 2D and 3D bus transfer speeds are very close (as would be expected) and change with changes in the AGP speed. However, on the KX133 motherboard (an Abit KA7), the 3D bus transfer rate is constant at ~50Mb/s regardless of the AGP speed. The 2D bus transfer however changes with the AGP speed and is ~290Mb/s and ~235Mb/s for 4x and 2x AGP respectively. On the AMD chipset motherboard (an MSI-6167), the 2D and 3D bus transfer speeds are at ~230Mb/s (with 2x AGP forced). So it would appear that the slow 3D bus transfer is responsible for the reduced performance of the G400 on the KX133 motherboard. On Windows 2000 both the 2D and 3D bus transfer speeds are ~50Mb/s (AGP is detected and said to be working).

Just to make sure that I haven't missed anything, can somebody else with a G400 and a KX133 Athlon board please run the Final Reality benchmark and post their results for the bus transfer tests.

My conclusions thus far:

1) It's not a Power Supply issue. Everything works correctly (apart from the slow bus transfers). In addition, the same Power Supply used in conjunction with a AMD chipset motherboard enables much higher bus transfer speeds.
2) It's not an electrical incompatibility with the AGP slot, as the 2D bus transfer speeds appear to be correct (under Win98).
3) It's not an IRQ issue. The G400 is on it's own IRQ (IRQ 10). No IRQs in the system are shared.
4) It's not a configuration issue. The same behaviour is exhibited with all driver combinations, whether the G400 is the only card in the system or not, and whether or not a clean install of the operating system is done. Also changing settings in the BIOS do not affect this behaviour.
5) It is not a RAM issue. Changing the RAM for PC100 RAM running at 100Mhz has the same results. The same PC100 RAM when running on the AMD chipset motherboard does not exhibit this behaviour.
6) It appears to be a Matrox driver issue.

Anybody got any thoughts on this?

Thanks

Ian Dean

Configurations:

Drivers used (Win 98):

VIA AGP 3.59 (Win 98)
VIA 4-in-1 4.17 (Win 98 - AGP only)
VIA AGP 4.00 (Win 98)
VIA 4-in-1 4.20 (Win 98 - AGP only)
Matrox PowerDesk 5.30 (Win 98)
Matrox PowerDesk 5.41 (Win 98)
Matrox PowerDesk 5.52 (Win 98)

Drivers used (Win 2000):
VIA chipset INF hack (Win 2000)
Matrox PowerDesk 5.03 (Win 2000)

Hardware Configuration:

Athlon approved 300W PSU
AMD Athlon 800 @ 800Mhz
256Mb PC133 SDRAM @ 133Mhz
128Mb PC100 SDRAM @ 100Mhz
Abit KA7 (RM & RK BIOS)
Matrox G400 Max
Matrox Rainbow Runner G-Series
Creative SBLive! 1024
Adaptec 2940U SCSI controller
Databook ISA PCMCIA controller

[CannyOne]

Hi Ian,

I'd say it's a combination of the VIA AGP drivers and the Matrox G400 Drivers. My scores in FR are approximately the same as your, with an EPoX EP-7KXA board and a Matrox G400Max.

That means, even though I hate to really bother people, I'm going to have to begin making a "pest" of myself. In this case both with VIA and Matrox. I've been suspecting this, but I couldn't get my MSI 6195 to work. So I couldn't come to any solid conclusions. I just know that performance isn't as good as with the Asus K7M that was only partially functional.

[anid]

Canny, be sure to check out the thread "K7A, G400 Max and AGP speed problem" and read the Tom's Hardware article linked in it before you go complaining to Via and Matrox to much. If the chipset is reporting incorrect identifiers it is a BIOS issue on the mobo makers part - these identifiers are provided by registers 3 and 4 of device 0 and 1 in BIOS. Via does not program these registers, nor can Matrox do anything about what the OS thinks is there (outside of their own hardware). If anything, complain to Abit and Epox first.

edit: I said "If the chipset is reporting incorrect identifiers...", it would have been better to say "If the BIOS is incorrectly reporting the chipset", which from the sound of the article @Tom's is what is happening.

------------------
"I wrestled with reality for 27 years and I'm happy to say I finally won out over it."

[This message has been edited by anid (edited 04 May 2000).]

[ID]

Hi all,

The AGP is recognised by both Windows 98 and Windows 2000 and outside of the Matrox driver appears to be working correctly. To tell the truth, I don't really care whether AGP works in Windows 2000. I only use this OS for (Windows CE) development. Every test shows that the AGP hardware is recognised and working correctly under Windows 98, so chipset identifiers are not relevant in this case. The problem that I have (in Windows 98) is that the AGP speed is not consistent across 2D and 3D. If the AGP didn't work then there is no way that I could get bus transfer speeds of ~290Mb/s in 2D.

The Matrox driver writers need to look at what they do in the 2D section of the Windows 98 driver to make the AGP work with the KX133 and apply this same logic to the 3D section of the Windows 98 driver (and all sections of the Windows 2000 driver).

I can't see what the VIA AGP driver writers could do to fix things, as they have no way of telling whether the AGP transfers are being done for 2D or 3D graphics.

But anyway, thanks "CannyOne", now that you've confirmed that I'm not the only one with this problem, I will begin to pester Matrox. It would be interesting if *anyone* is able to achieve full speed 3D bus transfers with the G400 and KX133 (please use Final Reality, as this is the only benchmark I am aware of that measures these figures).

I disabled bus-mastering just to see what would happen (I haven't had any reason to do this yet), and this reduces the 2D bus transfers to ~50Mb/s as well. So maybe this has something to do with the problem. Remember though that the board is capable of bus-mastering and AGP 4x, as the 2D bus transfer speeds show when bus-mastering is enabled.

This ~50Mb/s figure is really strange, as a PCI card (Voodoo2) gets a bus transfer score of ~110Mb/s. So the G400 appears to be running at half PCI speed in 3D. Definitely not good!

Thanks

Ian Dean


[This message has been edited by ID (edited 04 May 2000).]

[CannyOne]

The AGP for my system is also properly installed. Device Manager shows the "VIA Tech CPU to AGP Controller" as being identified. PCI List indicates that AGP 2X and sideband addressing are both currently enabled. But it also says the board isn't using, or capable of (not sure which!), AGP transfers or SBA. This is the point that leads me to suspect an issue with the chipset. The only thing I am sure of is that it is not an issue specific to the bios. Ian has an Abit and I have an Epox. The two bios are different, I'm sure.

What would be interesting is to determine whether or not people with a different video cards are having the same problem with the KX133 chipset. I'm tempted to get one of my friends to loan me his TNT2U for a couple of hours. This would at least allow me to narrow down the source of the issue. If NVidia chipset boards aren't having this problem. Maybe I shouldn't resist the urge to buy one of those new GTS boards!

[anid]

It may not be a chipset issue (with the identifiers), but if you wanna be safe Epox has released an up-dated Via driver that should work fine with any of the KX133 boards. There is a link to it on the SlotA.com site. All Epox has done is hack the inf file so it contains the incorrect identifiers, just as suggested at Tom's Hardware.

------------------
"I wrestled with reality for 27 years and I'm happy to say I finally won out over it."

[ID]

Hi all,

Some more information:

I did actually install the Epox chipset "patch" a few days ago, but that doesn't seem to make any difference unfortunately.

I had a G200 Marvel lying around so I thought I'd try that too. Same problem. The only difference is that the speeds are slower (looks like the G200 is running in 1x AGP). The G200 scores ~145Mb/s for 2D and ~35Mb/s for 3D in Final Reality.

This is very frustrating. If the drivers and AGP subsystem work correctly in 2D, why won't they work in 3D??? It really does sound like a Matrox driver bug to me.

"CannyOne", I'd like to hear what happens in your TNT test. I have to get this Matrox card working properly though, as I have not found any board that comes close to the Rainbow Runner's video capture/playback. I like the DualHead too much too.

Ian Dean

[anid]

Well, I still think it may be an issue in the chipset registers (fixable by BIOS update). There is a lot more there to AGP performance than just the identifiers. BUT - I don't have one of these boards, so can't test it, and don't know how significant the problem is with other cards. In other words, I know I could very likely be wrong. If anyone has wpcredit, what are the values for registers 40 and 41, bus 0, device 1, function 0? Knowing these and seeing what a few of the default AGP settings in the chipset are would put my mind at ease a bit. Although, it could be in the frame buffer too. I'm about to get one of these boards (Abit KA7) with a G400 for my folks, so I do have some personal interest in it.

------------------
"I wrestled with reality for 27 years and I'm happy to say I finally won out over it."

[Rob M.]

What is your AGP aperature set to? With my K7V if I set it to 256 I would get a noticeable performance decrease compared to 64 or 128.

Rob

[CannyOne]

Well, my one friend (with the TNT2U) is also an EverCrack addict. They came out with an expansion pack recently. So tearing him away from his computer, when he's not at work, would actually require physical force! So that possibility is out of the question.

I'm currently looking for anyone with a KX133 and a non-Matrox card to run the test. The reason I insist on doing this is it is the only way we can determine if it's a Matrox driver issue. Or if it's a Chipset driver issue, or I guess an issue with the programming of the registers. If nothing else I can try an experiment with a V3 3000, when I get that system back. Actually, Ian's test with the G200 strongly suggests the issue is related to the chipset. Since it returns results that are lower than those for his MAX, yet still show the same spread between the 2D and 3D scores.

Oh, BTW, I relieved myself of my GTS craving! I read "Dr Tom's" review. If he can't get excited about the GTS, because of the memory bandwidth issues. I have to wonder about it's market viability. But I do have a simple question. Do Ph.Ds have to take a course in "how to bore people to tears"??? I almost fell asleep by page 24 of his review. Had to skip to the end (page 29!) before I became mentally comatose.

[Nuno]

You may have a problem, but I wouldn´t trust Final reality at all. It was a Dx5 benchmark, for god sake. It says my G400 has a fill-rate of 24 Mpixels/sec...

Where exactly have you noticed the performance slowdown? D3D? Ogl? Or just FR?

Oh, and CannyOne, boring people to tears is something PhD´s excel at

[Paradizer]

Hi ID!
I got the same probs with my KA7/G400 MAX combo... But even less rates! After DLing Final Reality accoring to your post i saw that -> <u>2D: 171 and 3D: 44</u>
That really sux :-(
Bye the way, how do you force AGP 4x??? I tried the following:

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Servic es\Class\Display\0000\Settings\CPU]
"AGPFlags"="-2"

It doesn't work me! Another strange thing is, that PowerStrip shows that my VGA is only capable of AGP 1x and 2x NOT 4x! What the hell does that mean? In the diagnostics the 4x checkbox isn't just not checked it's completely disabled (grayed out)!
I've heard some rumors about some G400s which may only do 2x... Can this be true? My one (purchased in march) had the 1.5.22 bios... Should be new enough for 4x right???

Any solutions to the 4x prob? TIA!

____________________________________________

Hi anid!

I checked those values for you!

<u>Regs</u> <u>Values</u>
40h 48h
41h CDh

What's your conclusion seeing these?
Tell me more...


Best regards, Para

[CannyOne]

Ok Ian, I posted messages on a number of different forums to try and get someone with a KX133 board, that doesn't have a Matrox card, to run this test.

So far the only results have been a person who didn't have the VIA AGP drivers installed. His results, taken from Epox EP-7KXA, were:

2d bus xfer = 31.15
3d bus xfer = 45.84

Video = 1024 x768, essentially the same results for 1152x 864

600mHz @ 115 = 690mHz
ASUS V6600 deluxe AGP = 4x
Nothing tweaked special.

And another gentleman with the VIA AGP drivers installed reported this:

Asus K7V
Athlon 600
Asus 50x cdrom
Maxtor 13.6 7200rpm hard drive
sound blaster live
64 megs of Micron pc133 ram
Voodoo 3 Agp video card
I ran the test and hopefully I did it correct. These are the results

2D transfer rate test 116.32Mbytes/s R mark 3.70
3D trt 110.50Mbytes/s R mark 9.44

A larger sample of results would help greatly in drawing a firm conclusion. But the second set of scores does seem to indicate that there is an "issue" with the Matrox drivers. It's common knowledge that 3dfx's V3 line of video cards barely uses AGP. But his scores are roughly equivalent and he is using a KX133 board.

The conclusion that I'm trying to validate is "whether, or not, the VIA AGP drivers are the cause of the low scores. Or if it is indeed a Matrox driver related issue. Some here don't seem to understand how to use the "synthetic numbers" generated by a benchmark like this. They can only be used for comparing the same feature generated by the same test on different hardware. So I don't really care if "xxx" number of Mbytes/sec are being transfered or not. My concern is that if a system with an equivalent motherboard chipset and a different video card returns a set of numbers that have a certain proportion to each other. Why does my system return a set of numbers with a drastically different proportion? Ian just brought this to my attention that is all. Once I gather enough data to draw a firm conclusion. Then I'll take the matter up with Matrox. Of course by then Matrox may already have a solution available. I find it hard to believe they know "nothing" about this situation. VIA chipset motherboards are proliferating at a rapid pace. Therefore someone is bound to notice any deficiency in the combination of a Matrox card and this chipset.