Advertisement:

EPoX 8RGA+ Onboard Graphics

Join the community - in the OCAU Forums! Date  7th March 2003 Author  MCWB Editor  James "Agg" Rolfe Over the last couple of days I've been playing around with the onboard graphics on my EPoX 8RGA+, testing it with 3D Mark 2001SE. As most of you no doubt know, the 8RGA+ has onboard GeForce 4 MX video, with some of the system memory allocated to video memory. For general info about the 8RGA+, overclocking etc, please read and discuss in this thread. A few specifics to note: the onboard graphics only works when no AGP card is present. There are two VGA outputs though for those running two monitors, however if you want TV-out you’re out of luck, unless you can source one of those rare VGA-composite adapters. Let me detail the options in the BIOS specific for the onboard graphics on the 8RGA+. Frame Buffer Size: how much of the system memory you want to be allocated to video memory (128, 64, 32, 16, 8 or disabled). This works exactly the same as the amount of memory on your AGP card. 128 MB, 64 MB and 32 MB were compared in these tests, 3D Mark 2001SE can’t run with 16 MB apparantly. Onchip AGP Frequency: corresponds to core speed on an AGP card (100, 110, 120 or 130 MHz). All these options were compared. Other AGP-related options: AGP aperture: Was left at 128 MB throughout these tests AGP slot frequency: N/A for onboard graphics, left at 67 MHz. 8 X AGP: Enabled AGP Fast Writes: Enabled The 8RGA+ BIOS is virtually identical to that of the 8RDA+, apart from Vdd adjustment, onboard video options, logos etc, so you can refer to this thread for further information on that. The aim of this exercise was to find the optimum settings and configurations when using the onboard GF4 MX. Before we get into the tests, a little detail about my system: XP2100+ Tbred B capable of ~2508 MHz @ 2.0 V, cooled by Cathar’s LRWW block, a Honda heatercore and an Eheim 1250, with a chipset block made by pippin88 on the NB; EPoX 8RGA+ Revision 0.6; 2 X 256 MB Kingston PC3200 “ValueRAM” (Winbond BH-5 chips; see my other thread on the 8RGA+ for what it can do); 2 X 60 GB Maxtor ATA133 HDDs in RAID-0 on a Silicon Image ATA133 RAID controller. Settings used in the tests: Vdimm = 2.9 V throughout. This is the maximum possible on the 8RGA+ (without modding of course ;)) Vdd (chipset voltage) = 1.8 V throughout. I thought I’d use this rather than the more extreme 2.0 V because this is probably more realistic for most people, I really didn’t want to do all of this again at different Vdds! :D Memory timings were kept at 2-2-5-2 throughout, all test were run in a dual channel configuration and in sync with the FSB (100%) and CPU Interface was set to “Aggressive”. Benching was done in Windows XP SP1, with DirectX 8.1, and Detonator 41.13 drivers (the ones on the EPoX install CD). One thing I must add before we go on is that all the results here are the result of one 3D Mark run only. Therefore the results are subject to small variations in testing, even though identical Windows settings were used for each. Anything less than a few percent difference is most probably insignificant. Effect of Frame Buffer Size OK so the first thing I wanted to do was to see if the size of the Frame buffer size (the amount of system memory allocated to video memory) made a difference. I tested at 13 X 182 MHz, for reasons that will become obvious later. I compared performance with 128 MB, 64 MB and 32 MB shared memory, I also tried 16 MB but 3D Mark 2001SE had a hissy fit with me when I tried that. :p Results are as follows: Clearly at 13 X 182 MHz the frame buffer size is largely irrelevant when running 512 MB of RAM in total. I also ran 64 MB and 128 MB tests at many of the other FSBs, the 64 MB usually came out a few points ahead of 128 MB, but nothing really significant. The important thing to note is that if you’re running WinXP with only 256 MB of RAM and using the onboard graphics with 128 MB shared memory (which I only tried briefly), the system bogs down and swaps a lot, effectively having only 128 MB of system memory. I’d probably recommend using 64 MB, this is probably the best compromise between amount of shared memory and system memory for most situations, however 32 MB way work just fine as well. Effect of CPU speed and FSB The next thing I looked at was whether the onboard GF4 MX was CPU-limited or not, and if so, at what speed. I tested at 10.5 X 133 (XP1600+) 13 X 133 (XP2100+) and 16 X 133 (XP2600+). I then tested at 13 X 166 (2700+), to see what effect increasing the FSB would have. You can clearly see that going from 1.4 GHz to 2.1 GHz makes no difference. Performance of the onboard GF4 MX is therefore not CPU-limited, right down to XP1600+ speeds. This is not unsurprising, but what it does mean that if you’re using the integrated GF4 MX on this board you don’t need a scorchingly fast CPU. On the other hand, increasing the FSB from 133 to 166 gives a large boost in performance. Let’s investigate the effect of FSB a little more! :) Effect of FSB To do so I looked at the effect of FSB/multiplier combination at 2340 MHz, comfortably within my CPU’s limits. Here are the results: Three points: You can see that 3D Marks go up with increasing FSB, as we might suspect from the results in the first graph. This points to the onboard GF4 MX being limited by the memory bandwidth available to it. 3D Mark kicks back to the desktop at 11.5 X 204, and I get crazy corruption even in Windows at 12 X 212. This is strange, as I could run these settings perfectly with an AGP card present. Increasing the Vdd to 2.0 V makes no difference to this whatsoever. My personal feeling is that it could well be a heat problem, should slap an 80 W pelt on and see if it makes any difference! :D The point in 1. is not strictly correct, from a 180 to 187 MHz FSB there is a huge reduction in score, which increases slightly again once you raise the FSB to 195. I was extremely surprised at this, and to confirm it, I ran it again and again, with identical results. This is definitely something strange! A multiplier effect? I thought it may have been a multiplier issue going from 13 to 12.5 (something like the poor memory bandwidth under 9.5 on the 8RDA+), so I then tried whole multipliers 10 through 13, and got this: So it’s got nothing to do with the multiplier! :( Oh well at least we know! :D A FSB effect! Off to investigate the FSB side of things, where I found this: Now this is intriguing! :D I’d say there is a change in the chipset registers once you go over 182 MHz FSB. I’ve found a preliminary fix for this using WPCREDIT, see my post here for more details and discussion. It doesn’t solve everything, but it did give me a 12% increase in score. Effect of onboard AGP speed I also tested the effect of increasing the onchip AGP frequency (equivalent to overclocking the GPU core). Given the results with FSB frequency you can probably guess what’s going to happen, but here are the results anyway: 130 MHz is unstable even at 2.0 Vdd, freezing 3D Mark 2001SE. As suspected, given that memory bandwidth is the limiting factor, increasing the onchip AGP frequency gives no increase in performance. Summary and FAQs You can only use the onboard video when no AGP card is present. The board does have dual VGA outputs, but no TV-out. Increasing frame buffer size has no effect on performance in 3D Mark, however it may degrade performance if it leaves too little system memory available. 64 MB is probably the sweet spot here. CPU speed is unimportant, even a stock XP1600+ will run the onboard graphics fine. FSB is very important, 182 MHz is the max FSB for performance. I’m hoping to find the change that degrades performance for 183 MHz and up, obviously I’ll post it here if I find one! :) Onchip AGP speed is unimportant, it’s not a bottleneck. Clearly the ability to reach high FSBs is removed when using the onboard graphics. I could not get over 200 MHz FSB stable while using the onboard graphics even with 2.0 Vdd, however using an AGP card I have 3D Marked at 218 MHz dual channel and 225 MHz single channel. Clearly there is some sort of NB issue here, be it heat or inbuilt transfer limits, that limits the FSB used to less than 200 MHz. Any questions, comments or suggestions, feel free to contact me on the forums!

All original content copyright James Rolfe.
All rights reserved. No reproduction allowed without written permission.
Interested in advertising on OCAU? Contact us for info.