G400 Max highest overclocked speeds

[roadie]

I have a G400 Max at 165/220 with no extra cooling on (apart from a slot cooler which makes no difference. Whats the highest speed that the core and the memory can be clocked to with a larger heatsink and fan on the core and heatsinks on the ram? also how do you overclock the ramdac?

cheers

roadie

[CollegeManMan]

The highest overclock I could reach with my G400 MAX was 165/220, just like you. Then I added some home made ram-sinks. Now it can reach a blazing 166/222! Wow! Totally worth the five hours of hacksawing that old 486 heatsink :\

Hey, do you have any idea how to reach very high SYSPLL speeds? My core can run up to 175 mhz (just lapped and thermal pasted, nothing extreme). With a little extra cooling it could run at 177 mhz. That way, I could set a SYSPLL of 444, with divisors of 2.5 and 2.0, running the card at 177/222.

[roadie]

I have no idea what SYSPLL is, but another thing is triple buffering a good or a bad thing for performance and image quality?

[CollegeManMan]

The SYSPLL is the technical foundation for setting the clock speed of Matrox cards. The SYSPLL is set to a certain value, and the memory, core, and warp (I have no idea what the warp is) clocks are set by dividing that value. The Matrox tweak utility and Powerstrip let you overclock by percentages, it just leaves the term SYSPLL out of it. <a href="http://www.murc.ws/Utils/Mgat120b.zip">MGA Tweak</a> let you set the SYSPLL, the dividers, and load balancing variables.

I'm not sure why Matrox set up their cards like this, but it probably has to do with their "hidden specs" policy. They don't like to tell people what speed their cards operate at. Most people on this board can tell you that the G400 works at 125/166 and the MAX is at 150/200. At most, Matrox would tell you that the MAX is 20% faster than the vanilla, and never you mind how fast the vanilla is.

Triple buffering is an alternative to vsync. Vsync is supposed to match frame output to the monitors refresh rate, so there is no 'tearing'. Performance takes a big hit though. Triple buffering uses the video cards memory somehow to prevent tearing, and it has less of a performance hit than vsync. I don't use it, because I don't notice any tearing with vsync and triple buffering disabled. It could be because I don't run any stressful D3D apps.

[kjliew]

CollegeManMan,

SYSPLL has its own limit. When it exceeds its limit, it may not perform at the speed that it's supposed to be. That's how people get lower performance with high dividers. Any readings of SYSPLL over 500MHz may not be trustable. So you need to lower the dividers to get higher core/mem speed.

G400 specs is the only specs that "hints" on the limit of SYSPLL, it's 310MHz. The specs doesn't differentiate between vanilla and MAX version.

I don't think Matrox has "hidden specs" policy. At least, I am thankful for them to release registers level specs to the access of freelanced developers. Without this, MGATweak could never be possible. Matrox remains the only graphics company who has the guts to do so. S3 used to be one, but they are now history.

[Wombat]

Matrox has released enough specs for people to write decent Linux drivers. If they told us more, drivers would be better, but we can only dream.

[Zuofu]

V-sync is supposed to only hurt peformance in benchamarks when it renders fast enough to hit the referesh rate. V-sync will sync screen refreshes to monitor redraws (if it can). That just means your highest possible framerate = monitor refresh rate. If your monitor is set to 85 and you only get 40 fps, V-sync on or off shouldn't hurt performance. The reason why people think v-sync disabled is "faster" is because of the way games measure FPS...and number of frames drawn/total time in a timedemo. Lets say that at one point, the timedemo is very non-intensive (e.g. rendering a bare wall), and you get 110 fps for that short time. Well...if v-sync was enabled, you would get only 85 fps rendering the wall (if 85 was your referesh rate). This would hurt your average FPS, but it really won't affect gameplay..as maximum fps values are pointless (who cares about looking at a bare wall at 110 instead of 85 fps). The mimimum fps values are more important (they are the ones that you get in a hectic firefight).

[Brian R.]

Enabling vsynch will hurt you if you are on the slow end of the fps range. With vsynch enabled, you are only able to display multiples or fractions of the display refresh. Thus, if you are only able to redraw a scene at 30 fps with vsynch disabled (because of complexity), you would only be able to redraw it at 25 fps (75/3, or every third screen redraw) if your screen was set at 75 Hz refresh (with vsynch enabled). Other possibilities for fps at various refresh rates are worse than this example.

With vsynch enabled, you would be stuck (at this point in the game) with the 25 fps since the next multiple or fraction of 75 Hz is 50 Hz and you cannot render this hypothetical scene at this rate.

I realize the difference between 30 and 25 fps doesn't sound like much (poor example), but even in this case it is a 17% loss.

[This message has been edited by Brian R. (edited 09 August 2000).]

[Darin]

Brian,
Are you sure about that? Everything I've read concurs with what Zuofu stated (except that in some games vsync doesn't affect benchmarks because the timedemo command automatically disables vsync). My understanding is that with vsync enabled a frame sat in a frame buffer until a screen refresh, while the processor calculated the next frame. In your example of a constant 30 fps rendering capacity, and 75hz screen refresh, this would result in about half of the frames being on screen through two refreshes, and the remainder through three refreshes, but in the end the same number of frames would display, averaging 30fps. In the real world where rendering capacity fluctuates (a lot), a benchmark score (in the benchmarks that don't disable vsync) would be affected by vsync, as the max framerate would be capped by the screen refresh, affecting the average (as Zuofu pointed out), but we (or at least I) can't discern framerates above typical refresh rates.

I'm no expert on the inner workings of video cards, so anyone please correct me if I'm wrong, but this has been my understanding based on information I have seen in the past.

[This message has been edited by Darin (edited 09 August 2000).]

[Brian R.]

Darin

I don't think I'm toally disagreeing with him.

"V-sync will sync screen refreshes to monitor redraws (if it can). That just means your highest possible framerate = monitor refresh rate"

True, unless you happen to be able to do double the monitor refresh or something like that...Not likely. So, he and I agree. You won't be able to display greater than the screen refresh anyway.

"If your monitor is set to 85 and you only get 40 fps, V-sync on or off shouldn't hurt performance."

In this case, I disagree. With vsynch disabled, you get 40 fps. With vsynch enabled, you get 85/3 or one frame every three screen redraws which is around 28 fps on average.

You said:
"with vsync enabled a frame sat in a frame buffer until a screen refresh"

I don't think this is different than what is implied by my description. If you are able to redraw a scene 30 times a second, but are able to create a screen 75 times a second, then there is no way you are able to coincide your scene redraws with the screen redraws and you must suffer a penalty for the lack of timing. You will only draw 25 different screens during this time, not 30. Some sceens (scenes) will be displayed twice or three times while waiting for a "scene" redraw to complete.

Maybe you are misunderstanding me. I'm not saying that, in my example, you will get a smooth 25 frames per second displayed with vsynch enabled, they will be displayed one every 1/25th of a second, but the scene progression (if you are panning or something) will be choppy because you will get each frame reprecenting varying time intervals. If you sketch two one second time lines with one having notches every 1/75th of a second and one line having notches every 1/30th of a second, the scene redraws occuring at the 1/30th second marks will be displayed at the next 1/75th second mark and the next scene change will not be displayed until the 1/75th second mark after the scene is redrawn. I bet that will work out to be around 25 scene changes per second on average.

I will be the first to admit that I am not an expert in this area, however, this is the description I was given. Zuofu may be totally right and I may be partially wrong, but we don't completely disagree.


[This message has been edited by Brian R. (edited 09 August 2000).]

[Brian R.]

By the way, in answer to the post, I have had three MAXs. Without additional cooling, one would only oc to 210 MHz memory. The other two would oc to 240 MHz and 245 MHz memory, again, without additional cooling.

[Darin]

Brian,
First off, I want to make sure you understand I'm not trying to be argumentative, I just find this interesting and want to understand this (and I do enjoy an occasional debate). As I stated, I'm no expert on this, so I could easily be wrong, but if so I want to understand why.

I think we all agree that with vsync enabled, you will never have an fps that is higher than your refresh rate.

When you state "I bet that will work out to be around 25 scene changes per second on average" is where I disagree. In my understanding (in this scenerio), the average will still be 30fps (assuming no peaks that are above the refresh rate). I'll try to explain my understanding of what would happen in a timeline of monitor refreshes:

(this gets REALLY boring, so feel free to bail at any time!)

1. Work begins on rendering a frame. By the end of this refresh, frame is 2/5th rendered.

2. Still working, by end of this refresh, 4/5th of a frame is rendered.

3. Only 1/5th of the frame needs to be rendered, which will take 1/150th of a second. One refresh takes 1/75th of a second, so the frame is completely rendered 1/2 of the way through this refresh. It is not yet displayed, as it has to wait for a new refresh. Work begins on the next frame while this one sits in the frame buffer.

4. First frame is displayed. By the end of this refresh, the 2nd frame is 3/5th rendered (previous 1/5th for half of the last refresh, and another 2/5th for this one).

5. First frame still displayed, as next one not done yet. By end of this refresh, 2nd frame is exactly finished (previous 3/5 plus 2/5).

6. 2nd frame displayed. Work begins on 3rd frame, which is 2/5 complete by end of this refresh.

7. Back to refresh #2, etc. etc. etc.

So, if we repeat this loop, we can see that every other frame takes 3 refreshes (which correlates to 25fps), and the alternates in between take 2 refreshes (37.5 fps). If you run this out for 75 refreshes (one second), we will have rendered 30 frames, so it's the same 30fps average that the processor is capable of, not 25.

Now granted, it's not a perfect 30fps, as one frame is on screen for 2/75th of a second, and the alternate frames are on screen for 3/75th of a second, but in actual gameplay the fps is all over the place anyway. With vsync off in this scenario, every frame will either start at the beginning of a refresh and stop half way through it, or start halfway through a refresh and end at the end of a refresh (alternately), so ever third refresh will have the top half of the screen showing the previous screen, and the bottom half showing the next frame, which, theoretically, introduces tears in the image.

Of course, this is all just debate, and in real life you probably can't see a tear that only lasts 1/75th of a second that happens every 3/75th of a second, just like I can't see any lack of smoothness due to the display of frames alternating between happening every 2/75th of a second, and 3/75th of a second, and these concerns get even smaller when you start talking about the fact that most people use refreshes of 85hz or faster.

Personally, I have set my card to go to a 120hz refresh at 1024x768. I only use this resolution when play Q3A, as my desktop is usually at 11whatever by 8whatever. At 1024x768, my monitor can handle 140hz, so I don't really feel like I'm shortening it's life by doing so, especially considering the percentage of time it's at this resolution. This way, I minimize any delays from vsync (even though I'm sure I wouldn't notice them at 85hz anyway). Once you start getting into higher refreshes, the phosphor persistance adds a whole new element that makes all this a moot point anyway!

Another piece of info I'll throw out there: I always keep the fps display on in Q3A. It appears to update very quickly, as sometimes during lots of action the number changes so fast you can't read it (so I'd guess that it's calculating at least 10 times/sec). For some reason, it seems to hit a limit of 90fps when little or no action is going on in the field of view, but it doesn't show any tendancy to stick on perfect dividends of 120 (my refresh rate).

Again, I don't KNOW that this is all correct, just what I think is happening. Whether this is right or wrong, I expect no one will every mention vsync in these forums again

[Brian R.]

Your logic is good, IF the generation of the new frame can take place while the previous one sits in the frame buffer. I don't know the answer to this...

[roadie]

to brian r...

what program did you use to clock the memory so high? everyone that i have tried like powerstrip and matrox tweak utility 1.20 don't allow you to change the clock speed or the memory speed independently, they adjust them together

cheers

roadie

[Brian R.]

Roadie - I used Powerstrip. I just quoted the memory speed. The processor speed was increased proportionally. As you said, the memory and processor speed are locked together in that program. Sorry for the confusion. I'm just too lazy to calculate the processor speed.


[This message has been edited by Brian R. (edited 10 August 2000).]