Intel Q9450 vs Phenom 9850 - ATI HD3870 X2

Quote:

---

Originally Posted by JumpingJack

.... , only in a few cases can you see this really be a problem

---

Here is my theory :D

An that case can happen in games too. So why are we focusing on high resolution benchmarks? When your are at low resoultions and the prefetcher works well, the Core Architecture will always give you a bunch more FPS then an AMD thats why you will get higher average Frames, in fact there is no focusing on low fps. You wont see the results of the, i will name it, "latency hole" of a C2Q. :D

First you have to know that a gpu bound situation doesnt exclude a cpu bound situation.

So when your are at high resolutions a graphic card is like a frame limiter and there is more focusing on the low FPS, so where there are more latency holes, frames will drop much more then with a K10 and you will might get an better average score with the K10 because the better high fps score of a Core2Q are simply cutted off .

Thats what happend on the review of overclockersclub and World of Conflict, they used a graphic card which ran very early into a gpu bound situation and showed that a Phenom performed better at the cpu bound situations. By taking a better graphic card just forwards such a scenario to a higher resolutions.

Again: thats not always the case and in fact a very rare scenario, depending on the game and how its written. Jack provided us with very good Data has perfectly shown this and i realy appreciate his work.

And Jack, ist there a program which limits the frames software wise? Maybe you can check out my theory.. Thanks alot.

I believe the strange results which showed Phenom beating much faster QX9770 systems on the Overclockers club review were caused by a rather annoying BIOS bug on the X38/X48 based boards. Basically the PCI-E 2.0 sometimes does not allocate full bandwidth to a PCI-E 2.0 card.
There is a thread on this forum here.
Basically the fixed BIOSes Improve performance of PCI-E 2.0 cards which use a lot of the bandwidth
Core2 is much better than Phenom at the same clock and most Core2's are faster clocks than Phenoms so this whole debate is a non issue.
John

Quote:

---

Originally Posted by JohnZS

I believe the strange results which showed Phenom beating much faster QX9770 systems on the Overclockers club review were caused by a rather annoying BIOS bug on the X38/X48 based boards. Basically the PCI-E 2.0 sometimes does not allocate full bandwidth to a PCI-E 2.0 card.
There is a thread on this forum here.
Basically the fixed BIOSes Improve performance of PCI-E 2.0 cards which use a lot of the bandwidth

---

If this proves true, then... maybe there's more to test, Jack. Don't you have a X38 board?

Quote:

---

Originally Posted by gosh

Do you have any test comparing AMD and Intel on high res and/or advanced settings using fast video cards?

---

I will soon...with phase change no less...I'm going to do the Intel system with a QX9770 and the AMD with a 9950BE...both systems will be tested with a 9800GX2 and then 4870X2 Crossfire...I have no doubt that the Intel system will destroy the AMD...I will use my 42 inch 1080p TV which has resolution of 1920x1080...Maybe after that, I will borrow my brother's Apple 30 incher to test 2560x1600 as well.

Quote:

---

Originally Posted by ACE76

I will soon...with phase change no less...I'm going to do the Intel system with a QX9770 and the AMD with a 9950BE...both systems will be tested with a 9800GX2 and then 4870X2 Crossfire...I have no doubt that the Intel system will destroy the AMD...I will use my 42 inch 1080p TV which has resolution of 1920x1080...Maybe after that, I will borrow my brother's Apple 30 incher to test 2560x1600 as well.

---

woot, keep us updated on that. :yepp:

Quote:

---

Originally Posted by demonkevy666

334 > 200

& not ?

200 = 200

gosh, said you can't clock AMD's L3 cache thats not true

Me and charged3800z24 both have gotten our 2.4ghz NB which is L3 cache speed.

---

=___________________________________________=

Quote:

---

Originally Posted by Boschwanza

Here is my theory :D

An that case can happen in games too. So why are we focusing on high resolution benchmarks? When your are at low resoultions and the prefetcher works well, the Core Architecture will always give you a bunch more FPS then an AMD thats why you will get higher average Frames, in fact there is no focusing on low fps. You wont see the results of the, i will name it, "latency hole" of a C2Q. :D

First you have to know that a gpu bound situation doesnt exclude a cpu bound situation.

So when your are at high resolutions a graphic card is like a frame limiter and there is more focusing on the low FPS, so where there are more latency holes, frames will drop much more then with a K10 and you will might get an better average score with the K10 because the better high fps score of a Core2Q are simply cutted off .

Thats what happend on the review of overclockersclub and World of Conflict, they used a graphic card which ran very early into a gpu bound situation and showed that a Phenom performed better at the cpu bound situations. By taking a better graphic card just forwards such a scenario to a higher resolutions.

Again: thats not always the case and in fact a very rare scenario, depending on the game and how its written. Jack provided us with very good Data has perfectly shown this and i realy appreciate his work.

And Jack, ist there a program which limits the frames software wise? Maybe you can check out my theory.. Thanks alot.

---

This is where research and study pay off :) I will respectfully disagree and provide a rationale for my reasoning. Please take the time to read, I am wordy here.... but am using your post as a hook to provide more detail. I address your points at some point :)

Here is an example. First, a screen shot from the ATI demo toy shop:

http://forum.xcpus.com/gallery/d/745..._1600x1200.jpg

The image above was taken at 1600x1200 resolution. Next the wireframes overlaid for the same scene but one at 1600x1200 and another at 1280x1024:
http://forum.xcpus.com/gallery/d/744..._wireframe.jpg

1600x1200
http://forum.xcpus.com/gallery/d/745..._1600x1200.jpg

Study these two scenes carefully ... look at the trash cans for example... look at the eves along the walls, and the rain drops hitting the pavement. Take a game for example, increase the resolution makes the overall scene look better in terms of sharpness, but it does not change the 'blockiness' of the characters, objects, or world. Changing the resolution did not change a) the number of vertices (and consquently the number of polygons) and b) did not change the number of objects (such as rain drops, trashcans, etc).

The toy shop scene is quite educational ... and I chose it because it was the quick and easy way i knew off the top of my head to generate a wireframe rendition (I knew at one time how to do it in games too :) )... nonetheless, increasing resolution does not change the 3D complexity of the vertices, but does of the textures and the total number of pixels that make up the frame. Second point to note is the total number of raindrops do not change, just their visual acuity, run the demo yourself (if you have an ATI card), watch it study it... if you want to change resolution, edit the sushi.ini file and change it there.

This is a good example because the CPU is responsible for various things, creating objects, calculating AI, translating objects based on the trajectory of physics, the colliding rain drops on the pavement etc. However, changing the resolution of a game does not change the loading that will be placed on CPU as it will still calculate the same number of rain drops, it will still calculate their respective position in space regardless... same in a game, changing the resolution does not affect the particles generated (unless you change the particles and physics options -- I always run my CPU test benches with the physics and particles at max :)) or the number of bad guys in the game (the AI of which is CPU duty), etc etc.

Thus, resolution is irrelevant to the CPU -- only the objects, physics, and trajectory in 3D space matter. What does matter to the CPU is the state of the GPU ... i.e. is the GPU ready to take the next chunk of commands.

In fact AMD even did a presentation on this particular demo, the rain was the CPU limiter (due to so many drops I suspect coupled with the fact they use a Pentium 4 3.2 GHz :) ) http://ati.amd.com/developer/eurogra...onFestival.pdf. However, all things being the same -- the rain drops, in this case, will be the same in terms of number/density regardless if the resolution is 1024x768, 1280x1024, 1600x1200 or 1920x1200, the CPU will still be loaded with the same calculation burden.

Therefore, low resolution or high resolution, evaluating the CPU for executing the portion of gaming code specific to the CPU is not the issue. The nVidia article I linked up was very clear when looking for bottlenecks ... change the parametrics that affect the visual rendering and if the FPS varies with that change, the bottleneck resides inside the GPU pipeline somewhere. Conversely, if it does not change then the bottleneck resides on the host processor (in this case the CPU).

As such, the ability of the CPU to complete it's task is just the complexity of the code it is responsible for.... nothing more nothing less.

The GPU/CPU gambut are two different processors providing two different processing functions, where one result depends upon the other.... the GPU cannot render it's frame unless the CPU has finished providing the information for that frame, conversely the CPU cannot send a frame of information to the GPU until the GPU has finished it's prior obligation and will be ready to receive that information.

Last time I went to nVidia's technical documentation.... so let's turn to AMD instead, they describe in detail how the CPU and GPU work together in this document: http://developer.amd.com/gpu_assets/...ation_v1.2.pdf
Jump to the section 4.2 Host Programming Model Description where AMD (ATI) describes the CPU as the host controller. They discuss two methods by which the CPU interacts with the GPU, one is via writing directly to the GPU command buffer which is located in the VRAM on the graphics card, the other is to share a section of system memory (that both the CPU and GPU access). The GPU always reads, the CPU always writes -- it is a one way street. Let's consider the latter, the pull model.

The GPU sets the write pointer when it retrieves a section of the ring buffer, the CPU then reads the write pointer to know where to send the command packet, once sent it sets the read pointer that the GPU will then use for the next block of commands, and so forth and so on. The CPU / GPU do this via the graphics driver which rides beneath the directx api (the API programmers use as the universal launguage so they do not need to program to different architectures, hence API).

Now follow what happens, if the CPU does not finish in time to provide the next read pointer to the GPU what does the GPU do .. re-read the same block in the ring buffer? Nope, it waits until the correct pointer is set. Conversely, what happens if the GPU is late to the buffer and the CPU picks the same write pointer as before ... does it over write? Nope, it waits.... this is sorta that syncing thing that Gosh keeps going on about, except it has nothing to do with threading the processor but everything to do with the processor completing it's refresh of the frame correctly and timely.

When two competing computational resources must handshake, there is never the possibility that they always mate up temporally to complete the tasks at hand... and the only way to determine if one is bottlenecking the other is to vary the workload on one and observe the output.

In this case, it is easiest to simply vary the load on the GPU by changing the resolution ... the CPU will complete it's assigned workload within the same amount of time regardless of resolution so it will either give it's result to a ready GPU or have to wait for the GPU to become ready ... so simply changing resolution boils down to a simple observation, does the FPS vary if yes then GPU limited, if the FPS does not vary then CPU limited.

Now, the efficiency and capability of the CPU architecturally is a different question all together, but if one wants to compare the ability of a CPU to complete the gaming code for the CPU specifically, then you must observe it unhindered by the GPU ... i.e. lowest resolutions.

Now, in a follow up post, i will demonstrate to you how this is working with some other simple observations..... before I do, think carefully about the hypothesis...

If I run a game sequence at very low resolution then again at very high resolution, should I see a load change on the CPU since it will need to wait on the GPU? Hmmmm food for thought.

(Ohhhh.... I don't buy into the latency argument one second, rather in so far as how it might affect the CPU performance .. but not the ability to feed the command buffer... here is why ... lets make this easy, 100 FPS. At this frame rate it is taking the entire system 1/100 of a second to produce a frame, that 0.01 seconds.... latency on the order we are discussing is a few hundred nanoseconds... compare that .... 0.01 seconds to say 200 nanoseconds or 0.0000002 seconds ... it is a blink, it not even a blurb in the grand scheme of the time spent in computation, it has no effect. In terms of the Overclocker clubs data, they always run GPU limited in their games, from what I have read of their data sets -- as such, any CPU related conclusion based on their gaming data is bunk, meaningless take it all with a grain of salt ... my personal thought is that Intel's PCIe implementation sux coupled with the fact that 2 or 3 frames out 30 or 40 is almost in the noise).


Jack

Ok, to demonstrate that the CPU can indeed be waiting on the GPU I ran the following experiment.

I ran the Lost Planet Performance script in two regimes, the first was at 1920x1200 with everything maxed out, and one GPU on the 4870 turned off (you can select this as an option in the lost planet setup screens), I then repeated the same run but at 640x480 with everything turned down to minimum and both GPUs turned on. In the former case I am demonstrating the GPU limited scenario and in the second case the CPU limited scenario)... during the runs I use Everest's logging utility to log the total CPU utilization as well as each individual core.

In the case of high res, max everything, the CPU should be waiting on the GPU on average, hence the total utilization should be lower compared to the low resolution case... these are the results:

(PARDON the TYPO's I am not gonna regenerate the plot) ;)
http://forum.xcpus.com/gallery/d/745...tilziation.JPG

For those interested if LP is a multithreaded game, here is the utilization core for core for the same run:
http://forum.xcpus.com/gallery/d/746..._multicore.JPG

Quick answer.. gotta go to work :(

Jack, i never said high resolutions will gives a bunch of more CPU utilization then high ress (if i got you right). My intention was do clear out that a Intel Core CPU will always give you a lot more overall fps in low res just because of their power when l2 cache and prefetchers does it best. And that this higher Frames will cuted off in high Ress just because the Card acts like a framelimiter and allows you to focus more on the low FPS.

To get away from the resoultion :

Lets take a game where the sweet spot is around 60 FPS (min FPS around 30 max FPS around 90). The AMD will max out the graphic card to around 60 FPS an Intel will go up to 90. Enable Vsync to 60 FPS and the overall higher FPS over 60 will be cutted off. So there is more focusing on the low FPS. Run the game with different CPUs (or Platform) and lets see which handle the critical situations better.

Quote:

---

Originally Posted by Boschwanza

Quick answer.. gotta go to work :(

Jack, i never said high resolutions will gives a bunch of more CPU utilization then high ress (if i got you right). My intention was do clear out that a Intel Core CPU will always give you a lot more overall fps in low res just because of their power when l2 cache and prefetchers does it best. And that this higher Frames will cuted off in high Ress just because the Card acts like a framelimiter and allows you to focus more on the low FPS.

To get away from the resoultion :

Lets take a game where the sweet spot is around 60 FPS (min FPS around 30 max FPS around 90). The AMD will max out the graphic card to around 60 FPS an Intel will go up to 90. Enable Vsync to 60 FPS and the overall higher FPS over 60 will be cutted off. So there is more focusing on the low FPS. Run the game with different CPUs (or Platform) and lets see which handle the critical situations better.

---

No I understood what you mean, I simply just disagree -- in that, resolution has nothing to do with it ... those prefetchers work just the same on the same code and load ... the CPU will crunch through the code as fast as it can unless it waits on the GPU, if that is the case then the CPU stalls - waiting. Low resolutions simply allow you to observe the CPU performance free of any GPU bottlenecks.

This is why you see the utilization drop for the high res case ... the CPU is simply waiting for the GPU most of the time on average.

Nonetheless, your response was a well thought out post and gave me a chance to bounce off some details.

EDIT: Your second point is a good experiment, check the CPU utitilization on the Phenom vs the Intel quad by artificially capping the FPS ... interesting idea... not sure if we will see a good signal, but might as well check nonetheless.

EDIT2: Completely unrelated -- but I am extra disappointed by the performance of the 4870 X2 in Lost Planet ... (it rocks on most everything else), but I took out my favorite gaming bench to study this stuff.... :( I read through AMD's 8.7 release notes, where they claim a 1.7x improvement in LP for x-fire, but this is not a good 4870 X2 ready driver... need to wait for 8.8.

jack

http://http.download.nvidia.com/deve...orialNotes.pdf

This is probably the best paper to read (much a rehash of a link posted earlier) ... it goes through the history of the GPU as it developed and the slow migration of all rendering calculations moving off the CPU (early 1990s) to the GPU (2004).

It also goes into detail the relative functions of each computational resource, and makes very dramatic points about avoiding accessing GPU resources during rendering (i.e. the CPU should wait until the GPU is done) :) ....

Quote:

---

As power and programmability increase in modern
GPUs, so does the complexity of extracting every bit
of performance out of the machine. Whether your
goal is to improve the performance of a slow
application, or look for areas where you can improve
image quality “for free”, a deep understanding of the
inner workings of the graphics pipeline is required.
As the GPU pipeline continues to evolve in the
coming years, the fundamental ideas of optimization
will still apply: first identify the bottleneck, by varying
the load or computational power of each of the units;
then systematically attack those bottlenecks with an
understanding of the behavior of the various units in
the pipeline.

---

This was written by an nVidia engineer. Interesting, even nVidia suggest varying the resolution, texture aliasing to identify bottlenecks.

jack

Quote:

---

Originally Posted by Boschwanza

Give me an Intel Rig and i sure will ;). And again the FSB does not limit bandwidth wise, it all depends on the prefetcher and how well its actually working.

---

The benchmark doesn't appear to be limited by the FSB, memory latency or cache size since the 2.4GHz/2MB L2/800MHz FSB E4600 beats the 2.33GHz/4M L2/1333MHz FSB E6550.

Quote:

---

"Wrong" Data in the Cache (simplyfied) -> accessing memory -> high latency -> bad coherency -> bad performance ;)

---

This isn't a prefetcher issue, it's an issue within the core itself. The Core 2 has some problems with data that isn't aligned to a nice power of 2 value, causing it to take far longer to load than if the data was aligned. Even if the Core 2 had an IMC, it wouldn't help at all.

Quote:

---

Originally Posted by accord99

The benchmark doesn't appear to be limited by the FSB, memory latency or cache size since the 2.4GHz/2MB L2/800MHz FSB E4600 beats the 2.33GHz/4M L2/1333MHz FSB E6550.

---

I never said that, again: FSBs physical latency stays always the same for an Intel Core no matter how large cache or fast the FSB is. :confused: The lines, soldered on the board, provide a fixed latency, which the FSB protocol has to respect. Thats the weak point in my point of view. If the prefetcher catches the wrong data the whole Cache (no matter what size) is pollutet with sensless Data and a very very long access (through all the PCB layers) to the memory is necessary. In this Case the great advantage of the Core architecture (getting the data fast and very close to the processing unit) has turned upside down.

Jack, i just made a quick test with CoH and a 1950Pro, unfortunatly i cannot go higher with the resolution due to a 19 TFT


First shows Resolution 1280*1024 CPU settings max GPU setting max.
Second shows Resolution 800*600 CPU settings max GPU Settings low


http://www.abload.de/img/cputestxro.jpg

I have alot more Action on Core 3 with higher GPU Setting :confused: I'm confused :shrug:. Maybe you can check this out. Besides can you give me a script or program which records the cpu utilization ?

I´ll try to get more data later

Jack, I'm tending to believe that your thoughts about Intel's PCI-Express 2.0 controller are correct.
When I did the testing for the Asus Striker II Extreme ( nFORCE 790i ) review I found out something weird.
On GPU Limited scenarios, the Striker II Extreme was getting higher framerates ( minimum, average and maximum ), about 2fps higher than the ones on Intel chipsets ( P35, P45, X48 ) [ all tests done with a single card ].
Then I turned the tables and set some CPU Limited settings with some games and saw the Striker lagging behind ( just a tad ), which is "reasonable" since "computationally" clock-per-clock the nVIDIA chipsets have been slower than Intel's ( however the nFORCE 790i did a good job closing this gap ).
So... in GPU Limited tests ( PCI-Express 2.0 Controller can be/become a factor here ) the nFORCE 790i proved to be faster than Intel ( ~2fps advantage )
in CPU Limited tests ( PCI-Express 2.0 Controller not playing a part due to low GPU usage, low load, etc ) the Intel chipsets were faster than the nFORCE 790i.

All tests were done with the PCI-Express frequency at 100MHz on all boards.

dang this thread has gone a lot longer than i thought

good info JumpingJack

so all that -> amd is better at high res has nothing to do with the cpus itself, rather with the way how the different vendors implement the pcie 2.0 bus/controller.

Quote:

---

Originally Posted by Hornet331

so all that -> amd is better at high res has nothing to do with the cpus itself, rather with the way how the different vendors implement the pcie 2.0 bus/controller.

---

Which has been addressed in BIOS updates for X38/X48 boards as discussed here (the BIOSes idiscussed in the thread are BETA's fresh from ASUS and in most cases are not released....yet but will be soon, however there are links in the thread to the BIOSes).
John

I have done the CoH test again recording the utilization with everest.

Phenom 2.5 GHz / ATI 1950Pro / 2 Gigabyte Ram @ 1000 MHz

http://www.abload.de/img/cohhri.jpg

So resolution changes about nothing in terms of CPU utilization at least for CoHOF. I think the small differences are within measurement tolerances. I will try Call of Duty next.

Call of Duty 4

I have choosen the Mission where are you heading to the ship in the ocean b/c its very script based.

http://www.abload.de/img/callofdutyznh.jpg

Call of Duty acts like Jack says, cpu utilization decreases while resolution goes up. There is something odd, during the intro sequence to the mission at 640*480 there is almost no utilization (7%) if you turn to 1280*1024 this suddenly turns to about 25 % i re run this test a couple of times giving me exact the same results in every run.

World in Conflict Next

World in Conflict

http://www.abload.de/img/wicvew.jpg

This is quite interesting, during the atomic bomb attack and the bomber raid the CPU Utilization is increasing .

Edit:

Just played around a bit with WiC comparing "very high" settings with 1280*1024 and 800*600

http://www.abload.de/img/wic28u1.jpg

Well, its hard to draw an exact conclusion. During the bomber incoming i gained the most fps in 800*600 in comparision to 1280*1024, so in this particular case, Jack is right. But when the real action starts (atomic bomb & bombing raid) somehow the utilization increases so there has to be more calculation or whatever. I gotta think about this "issue". So far good night :yawn2:

Quote:

---

Originally Posted by JumpingJack

Changing the resolution did not change a) the number of vertices (and consquently the number of polygons) and b) did not change the number of objects (such as rain drops, trashcans, etc).

---

I must admit that I didn’t know that games was done like that. I thought that it was possible to set the viewable area and this wasn’t static and that the area increased a bit for higher resolution (don’t to much gaming..). If the area used for paint objects don’t increase with higher resolution then the burden for the processer obviously isn’t changed (only more detail will add work but not that much I think). These game programmers may not be as good as you think they are because that was a bit off. That would also mean that the game might not look as good on 30” as lower resolutions if textures etc is stretched and of course it looks worse on low res.

About the FSB and speed so what I have noticed is that this isn’t change for long streams of data. But if same amount of data is sent in small pieces and different directions then it gets slower. And that could be one explanation why performance isn’t changed as much modifying the FSB clock or how it is done. If the viewable area is the same then it would be easier to control the data sent to the gpu and that could make it easier to send the whole wireframe (all dots in the 3d space) in one transaction (or few transactions). And then send the commands needed for inform how to paint.

Is it possible to test Race Driver Grid?

Quote:

---

Originally Posted by RunawayPrisoner

Uhm... basically, I'm wondering why on the QX9650, there was always 2% of the time that fps was between 25 to 40. If you look at the screenshots again, on the QX9650, although fps is sky rocketting, 2% is always between 25 to 40. On the Phenom system, upon overclocking to 3GHz, it's always over 40. And minimum was at 45.

---

Is FEAR single threaded?

Testing a game that is using more threads (more memory, more details) will probably find if AMD doesn’t slow down as much.

Jack

wow long post.

A couple of questions....

Using your example scenario where the cpu writes data pointer to memory and the gpu takes this data to further process it.
Assuming the gpu is slower getting the data from memory than the cpu is writing.

You said:
Conversely, what happens if the GPU is late to the buffer and the CPU picks the same write pointer as before ... does it over write? Nope, it waits....


Doesnt this mean that when the CPU waits that the particular task which writes the data to memory is idle during that short period of time?
Wouldnt it mean that overall in such case you should see a slight drop in CPU utilization?

You said:
If I run a game sequence at very low resolution then again at very high resolution, should I see a load change on the CPU since it will need to wait on the GPU? Hmmmm food for thought.

I guess yes see above.

Some other thoughts:
CPU limited in this case would probably mean that the CPU calculations are not fast enough producing results for the task which writes the result into memory.

Also dont underestimate changing resolution on the gfx as well as detail level does affect GPU performance. So in worst case you could drift from an GPU bound to an CPU bound case. e.g. GPU is just a little quicker in reading the CPU data where the GPU operates at low resolution.
When resolution is suddenly set to high the GPU cannot grab the new memory data as quick as before because it is suddenly framebuffer bandwidth limited and now the CPU provides the data quicker than the GPU can process it.

Quote:

---

Originally Posted by gosh

Is FEAR single threaded?

Testing a game that is using more threads (more memory, more details) will probably find if AMD doesn’t slow down as much.

---

Yes, fear is single threaded. I will test it for you.


jack

Quote:

---

Originally Posted by Boschwanza

I have done the CoH test again recording the utilization with everest.

Phenom 2.5 GHz / ATI 1950Pro / 2 Gigabyte Ram @ 1000 MHz

http://www.abload.de/img/cohhri.jpg

So resolution changes about nothing in terms of CPU utilization at least for CoHOF. I think the small differences are within measurement tolerances. I will try Call of Duty next.

Call of Duty 4

I have choosen the Mission where are you heading to the ship in the ocean b/c its very script based.

http://www.abload.de/img/callofdutyznh.jpg

Call of Duty acts like Jack says, cpu utilization decreases while resolution goes up. There is something odd, during the intro sequence to the mission at 640*480 there is almost no utilization (7%) if you turn to 1280*1024 this suddenly turns to about 25 % i re run this test a couple of times giving me exact the same results in every run.

World in Conflict Next

World in Conflict

http://www.abload.de/img/wicvew.jpg

This is quite interesting, during the atomic bomb attack and the bomber raid the CPU Utilization is increasing .

Edit:

Just played around a bit with WiC comparing "very high" settings with 1280*1024 and 800*600

http://www.abload.de/img/wic28u1.jpg

Well, its hard to draw an exact conclusion. During the bomber incoming i gained the most fps in 800*600 in comparision to 1280*1024, so in this particular case, Jack is right. But when the real action starts (atomic bomb & bombing raid) somehow the utilization increases so there has to be more calculation or whatever. I gotta think about this "issue". So far good night :yawn2:

---

First, and foremost, thanks for taking the time to do this... data is always, always welcome :) ....

Yeah, there are cases in your runs where it is evident. At these lower resolutions, it is harder to see any effects... though the 1950 should throttle more than what I suspect...

I will repeat the very gross extremes I did with the 4870 X2 on the phenom and publish those as well.

Hey -- how are you benching COD4?

EDIT: Also, I just tested WIC -- and getting interesting results -- on CPU utilization. Did you use presets to set the high vs low?

Quote:

---

Originally Posted by xPliziT

Jack

wow long post.

A couple of questions....

Using your example scenario where the cpu writes data pointer to memory and the gpu takes this data to further process it.
Assuming the gpu is slower getting the data from memory than the cpu is writing.

You said:
Conversely, what happens if the GPU is late to the buffer and the CPU picks the same write pointer as before ... does it over write? Nope, it waits....


Doesnt this mean that when the CPU waits that the particular task which writes the data to memory is idle during that short period of time?
Wouldnt it mean that overall in such case you should see a slight drop in CPU utilization?

---

The answer is yes, which is why I forced the extreme situations in the Lost Planet case. As I argued above, increasing the resolution is a burden on the GPU not the CPU. As such, the scenarios is that if the CPU waits it stalls and does nothing, this should translate into lower CPU utilization ... but you gotta push it. Some of the data posted by Boschwanza shows the same effect, in other cases not .. but he correctly points out that it may be due to the limitation he has on the overall resolution.

Quote:

---

CPU limited in this case would probably mean that the CPU calculations are not fast enough producing results for the task which writes the result into memory.

Also dont underestimate changing resolution on the gfx as well as detail level does affect GPU performance. So in worst case you could drift from an GPU bound to an CPU bound case. e.g. GPU is just a little quicker in reading the CPU data where the GPU operates at low resolution.
When resolution is suddenly set to high the GPU cannot grab the new memory data as quick as before because it is suddenly framebuffer bandwidth limited and now the CPU provides the data quicker than the GPU can process it.

---

Yeah... the details in the PDF from nVidia is a good, layman's general outline of how the GPU and CPU subsystems work... in their bottlnecking flow chart they pretty much outline what various parametrics affect the GPU loading.

Workload affecting the GPU
- Resolution
- Aliasing
- Filtering
- Vertex size
- Vertex code/instructions

The workloads that affect the CPU are not enumerated, but you can gather from other resources, even the link Gosh posted related to how the WIC development went...

Things that change the workload on the CPU
- Objects (bad guys, rain drops)
- Physics (particles)
- Character AIs

I have other papers, I will see if I can link up publically available PDFs of them, much of the stuff I get is not available online or if it is requires a subscription...

Here is one: http://www.digra.org:8080/Plone/dl/db/06278.34239.pdf

The general flow of a gaming program can be done as follows

1. Start of the frame
2. Poll the input devices
3. Calculate the physics for objects
4. Calculate the AI
5. Sound decomposition
6. Write frame information
7 repeat until exit

Each of a multitude of steps can be split into separate threads depending on the circumstance. For example, calculating the 3D translation of a falling rock can be done independent of establish the next motion of AI for a bad guy. Single threaded each segment must be carried out in order, and all segments must be complete before sending info to the command buffer for rendering...

Multithreading this can speed things up tremendously... this is why you see Lost Planet, for example, scale so well... UT3 scales to 3 cores very nicely, the 4th doesn't add much.

Quote:

---

Originally Posted by gosh

I must admit that I didn’t know that games was done like that. I thought that it was possible to set the viewable area and this wasn’t static and that the area increased a bit for higher resolution (don’t to much gaming..). If the area used for paint objects don’t increase with higher resolution then the burden for the processer obviously isn’t changed (only more detail will add work but not that much I think). These game programmers may not be as good as you think they are because that was a bit off. That would also mean that the game might not look as good on 30” as lower resolutions if textures etc is stretched and of course it looks worse on low res.

About the FSB and speed so what I have noticed is that this isn’t change for long streams of data. But if same amount of data is sent in small pieces and different directions then it gets slower. And that could be one explanation why performance isn’t changed as much modifying the FSB clock or how it is done. If the viewable area is the same then it would be easier to control the data sent to the gpu and that could make it easier to send the whole wireframe (all dots in the 3d space) in one transaction (or few transactions). And then send the commands needed for inform how to paint.

Is it possible to test Race Driver Grid?

---

Gosh -- Race Driver Grid is a hard game (at the moment) to test for a few reasons. This is not to say I won't, it will just take me some time.

First reason -- I just bought a copy of the retail, so i will want to use that instead of the demo I downloaded. This is more representative.

Second reason -- RDG does not have a way to reproducibly recreate the 'action' to make a good reproducible run. I really wish they would have put an 'instant replay save' feature into the game or some way to record a lap around the track. So far, all reviewers are using FRAPs to evaluate RDG by lapping once around the track.

Ok, so really two reasons... what I mean by this is that I will do it, but it will take a day or two to figure out a way to get a reproducible bench system going on this game. At which time I will produce a CPU stressing experiment like I did above.

On the large packet vs small packet --- this is true ... latency is the time between the initiation of a request for a packet to the actual receipt of that packet... like priming a pump, once the stream comes it comes. Several small packets, and request generate more accumulative latency than a large single block of data in one request.


jack

Jack, lots of good info, thanks.

But we need more controlled tests before we can jump to conclusions:

1. Don't use games to check CPU usage. You have no idea what games do when it comes to code, and things like sound, network code, and other libraries used may use more CPU cycles than desired, at unpredictable times. To avoid this, I think it would be best to do this comparison in something such as 3dmark (vantage or 06). I will do such tests as soon as I find the time.

2. Issue of texture fetches cannot be ignored at higher resolutions, and its a known problem with low-memory video cards: take a 4870 and chop its memory in half, do you think CPU and bus efficiency won't effect performance at 640 res vs 1600 res? Much like running at a higher res vs lower res, wouldn't you agree?

3. The graph you present which compares CPU utilization at different resolutions is flawed: the complexity introduced with dual-gpu solutions negatively impacts CPU performance. Its best to stick to one GPU for both tests to minimize number the number of variables



@Boschwanza,

If you want to do these comparisons, try setting the affinity of the game's thread to only one core. This might present more predictable results.


Other than that, interesting discussion!

Quote:

---

Originally Posted by ahmad

Jack, lots of good info, thanks.

But we need more controlled tests before we can jump to conclusions:

1. Don't use games to check CPU usage. You have no idea what games do when it comes to code, and things like sound, network code, and other libraries used may use more CPU cycles than desired, at unpredictable times. To avoid this, I think it would be best to do this comparison in something such as 3dmark (vantage or 06). I will do such tests as soon as I find the time.

2. Issue of texture fetches cannot be ignored at higher resolutions, and its a known problem with low-memory video cards: take a 4870 and chop its memory in half, do you think CPU and bus efficiency won't effect performance at 640 res vs 1600 res? Much like running at a higher res vs lower res, wouldn't you agree?

3. The graph you present which compares CPU utilization at different resolutions is flawed: the complexity introduced with dual-gpu solutions negatively impacts CPU performance. Its best to stick to one GPU for both tests to minimize number the number of variables



@Boschwanza,

If you want to do these comparisons, try setting the affinity of the game's thread to only one core. This might present more predictable results.


Other than that, interesting discussion!

---

:) .....
On point 1 ... what I want is a gross check of the concepts. I.e. the premise is that for low load on the GPU, the CPU is free to run amuck, as such it should show max utilization for that load (i.e. very high). At high GPU loads (bottleneck), then the CPU will stall waiting on the GPU, and utilization will go down. It is not intended to be systematically decomposing the code. Just testing the bottlneck theory.

On point 2 ... which is why I put in a 1 Gig mem card.... the most interesting article is here: http://www.yougamers.com/articles/13...ly_need-page2/ Texture thrashing is not a big deal, for most games with 512, it appears to be enough for the most part. However, the recent release of the 4870 X2 (which I promptly refitted my baseline builds with for this very reason), two reviews show one game thrashing the memory at ubber high res for the 512 Meg cards ... all the others appear to be no issues:
http://www.anandtech.com/video/showdoc.aspx?i=3372&p=9
http://www.guru3d.com/article/radeon...w-crossfire/11
Race Car Driver GRID is able to fill the 512 Meg cards at 2560x1600 as seen by the precipitous drop in FPS going from 1920x1200 to 2560x1600. Other than that, it would appear most games are fitting into memory ok...

However, I have noticed some games are very poor at precaching the textures (Doom 3 on some user generated level does not precache all the textures, for example -- somewhere in the thread I make mention of an experiment to observe the phenomena) ... when I do observe it I will make sure I point that out -- so far in the bits shown around here, I have not seen any texture thrashing that would screw with the results.


3. Again, the test was to show that when the GPU becomes the bottleneck then the CPU stalls as such the utilization goes down (the CPU sits around doing nothing), it was not a flawed test... it demonstrated the effect very nicely.

jack

Quote:

---

Originally Posted by Boschwanza

I never said that, again: FSBs physical latency stays always the same for an Intel Core no matter how large cache or fast the FSB is. :confused: The lines, soldered on the board, provide a fixed latency, which the FSB protocol has to respect. Thats the weak point in my point of view. If the prefetcher catches the wrong data the whole Cache (no matter what size) is pollutet with sensless Data and a very very long access (through all the PCB layers) to the memory is necessary. In this Case the great advantage of the Core architecture (getting the data fast and very close to the processing unit) has turned upside down.

Jack, i just made a quick test with CoH and a 1950Pro, unfortunatly i cannot go higher with the resolution due to a 19 TFT


First shows Resolution 1280*1024 CPU settings max GPU setting max.
Second shows Resolution 800*600 CPU settings max GPU Settings low


http://www.abload.de/img/cputestxro.jpg

I have alot more Action on Core 3 with higher GPU Setting :confused: I'm confused :shrug:. Maybe you can check this out. Besides can you give me a script or program which records the cpu utilization ?

I´ll try to get more data later

---

It is interesting to see how the different cores behave with respect to thread scheduling :) this, though, is a function of the OS ... run it a few more times and you will likely see that change to different cores depending.

Some Apps can force an affinity to a particular core, try running FEAR and see where it forces the single thread ... then run SuperPI (as a counter example) and see how the cores are utilized.

Jack

Ok, so for those entering the thread on this page or just starting to follow the conversation -- this post is referenced to a post a page or two back. What I did was used the very extreme case of ultra low resolution and ultra high resolution conditions to force a GPU bottleneck and demonstrated the CPU utilization in the case that the CPU was stalled by waiting on the GPU. That run (again, two pages back) was done on a QX9650 clocked at 2.5 GHz using the latest 4870 X2 graphics card, details of the observation were written into the graph.

Essentially, I am working the experiment with this particular game engine to show that two competing resources affect each other differently, by varying the load on one and observing the response on the other.

This post is simply the Phenom 9850 clocked at 2.5 Ghz version of the same experiment on Lost Planet. I try to box out the regions of interest with an explanation of what is what. Pardon the typo's...

http://forum.xcpus.com/gallery/d/746...tilization.JPG

Is it possible to focus testing on low FPS? If there are games out there that have accurate testing showing MIN FPS?
The thing that Boschwanza wrote could explain all these data

Quote:

---

Originally Posted by Boschwanza

So when your are at high resolutions a graphic card is like a frame limiter and there is more focusing on the low FPS, so where there are more latency holes, frames will drop much more then with a K10 and you will might get an better average score with the K10 because the better high fps score of a Core2Q are simply cutted off .

---

If the differences in grid compared to Intel are small then it would be almost impossible to draw any conclusions if there isn’t any way to do exact the same test. If the difference is larger that it could probably be done anyway.
But one thing that could be tested is to test one game and try to get as low FPS as possible. Select parts of games where you know that the game could slow down or lag and test that part to se how low you can go with each platform.

The test in FEAR when memory was at 1067 and processors was clocked to 3.0 GHz. Min FPS was at 48 and Intel had 40. Was this random or it is the same every time?
It would be interesting to se the MIN FPS score if you clock Intel to 3.6 GHz or more

Quote:

---

Originally Posted by gosh

Is FEAR single threaded?

Testing a game that is using more threads (more memory, more details) will probably find if AMD doesn’t slow down as much.

---

With me on FEAR my minimum FPS is 58FPS. @ maximum resolution my monitor can take (1680*1050) 4XFSAA 16XAF and Soft Shaddows.
John

Is it possible to test only MIN FPS on crysis?

The test that i linked to in the first message the difference was larger on MIN FPS compared to MAX

Game: Crysis
Settings: 1280x1024, 1xAA/1xAF, DX9 everything HIGH
Q9450 = Min FPS 22.46, Max FPS 61.71, Avg 41.96
Phenom 9850 = Min FPS 29.82, Max FPS 63.20, Avg 47.89

EDIT: Checked the documents from Jack and it seems hard to do any with min there (results differs, better min on higher res..).

I am doing some testing.
Results shall be ready to get published in the evening.

Quote:

---

Originally Posted by BenchZowner

I am doing some testing.
Results shall be ready to get published in the evening.

---

If you are doing ANY benching on X38/X48 based boards be sure to grab the latest available BIOS either from the thread I linked or from the manufacturers otherwise you will have the X38/X48 PCI-E 2.0 disadvantage at high res/high FSAA.
John

Quote:

---

Originally Posted by JohnZS

If you are doing ANY benching on X38/X48 based boards be sure to grab the latest available BIOS either from the thread I linked or from the manufacturers otherwise you will have the X38/X48 PCI-E 2.0 disadvantage at high res/high FSAA.
John

---

As far as I know/remember, the BIOSes addressed a "bug" with the 9800GX2, not exactly a PCI-Express 2.0 BUS issue or bandwidth related issue.
Doesn't even matter, since I'm running the latest BETA's on every board.

I'm thinking of starting some tests with the Striker II Extreme though, because of the "thing" that I noticed during its review ( check my previous post ).

Just found sometihn interesting. Intel makes a game contest to find the best threaded game. There are plenty of demos available maybe we can choose one of the and check them out on a intel and AMD platform.

http://softwarecontests.intel.com/ga...hp?entryid=157

Quote:

---

Originally Posted by BenchZowner

As far as I know/remember, the BIOSes addressed a "bug" with the 9800GX2, not exactly a PCI-Express 2.0 BUS issue or bandwidth related issue.
Doesn't even matter, since I'm running the latest BETA's on every board.

I'm thinking of starting some tests with the Striker II Extreme though, because of the "thing" that I noticed during its review ( check my previous post ).

---

I look forward to your results :D

John

Quote:

---

Originally Posted by demonkevy666

gosh, said you can't clock AMD's L3 cache thats not true

---

Interesting! There was another discussion talking about how bad AMD was and they said that the L3 cache (or just cache) was so slow and that it wasn’t possible to overclock the L3 cache. None in that discussion said anything other. If it is possible so very good :)

Quote:

---

Originally Posted by gosh

Interesting! There was another discussion talking about how bad AMD was and they said that the L3 cache (or just cache) was so slow and that it wasn’t possible to overclock the L3 cache. None in that discussion said anything other. If it is possible so very good :)

---

Gosh ... where was this discussion? (I don't get into every thread) This is just ludicrous.

Quote:

---

Originally Posted by gosh

Is it possible to focus testing on low FPS? If there are games out there that have accurate testing showing MIN FPS?
The thing that Boschwanza wrote could explain all these data

---

Jack gave an excellent rebuttal to Boschwanza's "theory." Video cards are frame limiters at higher resolution but CPUs will always go through data at the same speed, no matter what the resolution. At higher resolution, the CPU is waiting for the GPU, thus CPU utilization drops, which is shown in the task manager.

It makes perfect sense to me, keep up the good work Jack!

Quote:

---

Originally Posted by Clairvoyant129

Jack gave an excellent rebuttal to Boschwanza's "theory." Video cards are frame limiters at higher resolution but CPUs will always go through data at the same speed, no matter what the resolution. At higher resolution, the CPU is waiting for the GPU, thus CPU utilization drops, which is shown in the task manager.

It makes perfect sense to me, keep up the good work Jack!

---

I wouldnt say there is just "black and white" and that simple, i mean it will depend on the game.

Call of Duty 4 and Lost Planet act exactly how Jack descriped. CoH gave me the same Utilization no matter what resolution and WiC its mixed, while there is not much action Utilization decreases with higher resolution but on the heavy stuff processor load increases.

There is one thing we have to take care about a GPU bounded situation wont exclude a CPU bounded situation.

Quote:

---

Originally Posted by JumpingJack

Gosh ... where was this discussion? (I don't get into every thread) This is just ludicrous.

---

Not in this forum and this was in another language .
What I was told there was that the frequency of the L3 cache was locked and couldn’t be changed. The discussion was about how good i7 (Nehalem) was because (one of the reasoon) the L3 cache was so much faster and was running at the same frequency as the processor.

For games it should be some speed to gain clocking L3.

Quote:

---

Originally Posted by Boschwanza

This is quite interesting, during the atomic bomb attack and the bomber raid the CPU Utilization is increasing .

---

Is smoke etc done with vertex data?
If some type of graphics has some sort of knowledge on the resolution it could be that the processor needs to calculate more on higher resolutions. Don't know this, just one speculation

Quote:

---

Originally Posted by gosh

Is smoke etc done with vertex data?
If some type of graphics has some sort of knowledge on the resolution it could be that the processor needs to calculate more on higher resolutions. Don't know this, just one speculation

---

Yes, volumetric smoke gets vertexes, shaded, and made translucent just like any other 3D object.

Download the Toy Shop demo, and run at different resolutions and look at the smoke generated from the chimney's, press W to see the wire frame ... the number of vertexes does not change... this is fixed by the 3D model framework. At least this is what I have been able to gather in my reading.

http://developer.download.nvidia.com...gems3_ch30.pdf some interesting details.

EDIT: Here is a very interesting one: http://www.iam.unibe.ch/publikatione...le/at_download discussing 'threading' fluid simulations for 3D rendering... the work load here is on the CPU.

Quote:

---

Originally Posted by gosh

Not in this forum and this was in another language .
What I was told there was that the frequency of the L3 cache was locked and couldn’t be changed. The discussion was about how good i7 (Nehalem) was because (one of the reasoon) the L3 cache was so much faster and was running at the same frequency as the processor.

For games it should be some speed to gain clocking L3.

---

Send them here, I will straighten them out... i have had my northbridge clocked as high as 2.6 Ghz.

Quote:

---

Originally Posted by gosh

Is smoke etc done with vertex data?
If some type of graphics has some sort of knowledge on the resolution it could be that the processor needs to calculate more on higher resolutions. Don't know this, just one speculation

---

What I think happened here is that in stead of just changing resolution and GPU related load settings, he simply used presets to change between high settings and low settings.

Games for the past 1 or 2 generations give options for physics, particle debris, and smoke/shadows ... these are usually CPU duties.

I can run an experiment to verify. But those bombing runs, in low settings, do not throw up debris ... at high settings it is covered with debris.

By the way, Jack, which drivers are you using for your HD4870X2's? I have heard that reviews use 8.520.2?

Quote:

---

Originally Posted by RunawayPrisoner

By the way, Jack, which drivers are you using for your HD4870X2's? I have heard that reviews use 8.520.2?

---

I updated to 8.8 shortly after they were released. No change in WIC, but Lost Planet sees a nice bump, about 15-20 FPS, HL2-lost coast also showed some gain. I will redo the 3DMark @ 2.5 GHz on each and post them.

3DMark06@default values 4870X2 with Shipped drivers (scores generated were also posted earlier in this thread)

Phenom 9850 2.5 GHz Score = 13297
http://forum.xcpus.com/gallery/d/736...X2_default.JPG
QX9650 2.5 GHz Score = 14471
http://forum.xcpus.com/gallery/d/737...X2_default.JPG

3DMark06 @ default values 4870X2 Catalyst 8.8 August Release
Phenom 9850 @ 2.5 GHz Score = 13400
http://forum.xcpus.com/gallery/d/747...0X2_CAT8_8.JPG

QX9650@2.5 GHz Score = 14820
http://forum.xcpus.com/gallery/d/747...0X2_CAT8_8.JPG
Jack

Quote:

---

Originally Posted by JumpingJack

What I think happened here is that in stead of just changing resolution and GPU related load settings, he simply used presets to change between high settings and low settings.

---

Thats why i did the test again using the exact same presets for WiC "very high" and just change the Resolution to address differences.

Again

http://www.abload.de/img/wic28u1.jpg

Will do some more tests this weekend.

Quote:

---

Originally Posted by Boschwanza

Thats why i did the test again using the exact same presets for WiC "very high" and just change the Resolution to address differences.

Again

http://www.abload.de/img/wic28u1.jpg

Will do some more tests this weekend.

---

That's with Anti-Aliasing and Anisotropic Filtering enabled or disabled ?

Enabled, both 4x

Jack can you test CoHOF and fix the display to 60Hz? Found out CoHOF always enables V-Sync and the sweet spot is around 60 FPS (@all max details 8*AA) so it just would be perfect for a comparision. 8800GTX and 4870 would be nice.

Jack have you ever tested the Phenom with increased northbridge (L3) frequency? I've always wondered what the impact of increased NB/L3 frequency is on Phenom but no sites have really tested this. I'd like to see how Phenom @ 2.5GHz core / 2.4GHz NB performs compared to the NB @ 2GHz.

Have been reading some game programming (very little) the last couple of days checking how it is done. What strikes me is that how little the performance of the game depends on the processor. If you can run the game on 640x480 then the processor is ok. How high (resolution) you can go depends on the video card.
There seems to be very few (if any) settings in games that will add work for the processor that are resolution dependent. AI and physics, detail etc will probably add work for it, haven’t read about that. But it should be the same for all resolutions.

Games don’t seem to use take advantage of higher resolutions for increasing the game experience for the player.

If the game is using threads then one single core processor should degrade performance but apart from that it’s the video card that decides game performance. Faster processors will of course increase FPS on low res but you will not go below min FPS on 640x480 because the processor isn’t enough on higher resolutions. If you go lower then it depends on the video card or something else, not the processor.

All this talk about what type of processor you need for gaming seems to just be fictional.

Quote:

---

Originally Posted by gosh

Have been reading some game programming (very little) the last couple of days checking how it is done. What strikes me is that how little the performance of the game depends on the processor. If you can run the game on 640x480 then the processor is ok. How high (resolution) you can go depends on the video card.
There seems to be very few (if any) settings in games that will add work for the processor that are resolution dependent. AI and physics, detail etc will probably add work for it, haven’t read about that. But it should be the same for all resolutions.

Games don’t seem to use take advantage of higher resolutions for increasing the game experience for the player.

If the game is using threads then one single core processor should degrade performance but apart from that it’s the video card that decides game performance. Faster processors will of course increase FPS on low res but you will not go below min FPS on 640x480 because the processor isn’t enough on higher resolutions. If you go lower then it depends on the video card or something else, not the processor.

All this talk about what type of processor you need for gaming seems to just be fictional.

---

wow, just wow....
people where telling you for 15 pages that cpus mostly dont matter for highres gaming... and you where the one that refused to listen... people where bombarding you with facts... and now all of a sudden you came to the same conculsion, after "reading something about game programing", what people where telling you from left and right and what already is a well known fact...

i spare to say what this makes you look like...

Quote:

---

Originally Posted by Hornet331

wow, just wow....

---

But why are most gamers using intel then? And why do they overclock?
The processor doesn't matter but the communication between processor and hardware, memory speed does matter when it comes to min fps.
I admit that I thought that was some logics in what you read every ware that you need faster processors.
When you develop normal programs you try to use the whole screen and calculate how much it is possible to display, didn’t think that this was any different for game programmers. What I have seen among those is that type of programming today is very simple.

Quote:

---

Originally Posted by Hornet331

i spare to say what this makes you look like...

---

It’s enough for me to write in this language and I think it makes me look like… ;)
You know, I don't care :)

In case you didn't read it correctly but the HL2 tests are wrong.

It's not 300 fps with the AMD and 295 fps with the Intel CPU.

9850 → 123.26 fps
Q9450 → 100.97 fps

Quote:

---

Originally Posted by Hornet331

wow, just wow....
people where telling you for 15 pages that cpus mostly dont matter for highres gaming... and you where the one that refused to listen... people where bombarding you with facts... and now all of a sudden you came to the same conculsion, after "reading something about game programing", what people where telling you from left and right and what already is a well known fact...

i spare to say what this makes you look like...

---

Hold on :) .... I applaud what he has done. He took the initiative to spend some energy to learn, rethink what he knows, and put that new knowledge to good use.

@ Gosh -- good job! This whole discussion has made me learn as well, I think overall it has been extra positive.

Jack

Quote:

---

Originally Posted by Extelleron

Jack have you ever tested the Phenom with increased northbridge (L3) frequency? I've always wondered what the impact of increased NB/L3 frequency is on Phenom but no sites have really tested this. I'd like to see how Phenom @ 2.5GHz core / 2.4GHz NB performs compared to the NB @ 2GHz.

---

yes but nothing systematically -- and never recorded the results, i would like to look at that, so i will produce a little data for the thread.

The closest I have come is a fairly decent comparision of a 9600 BE @ 2.3 Ghz and 1800 Mhz NB vs a 9850 @ 2.3 GHz and 2000 Mhz, I also did some latency meaurments using CPUID latency and Everest latency reports... I can try to pull that info up and post it relatively quickly.

Jack

Quote:

---

Originally Posted by Boschwanza

Jack can you test CoHOF and fix the display to 60Hz? Found out CoHOF always enables V-Sync and the sweet spot is around 60 FPS (@all max details 8*AA) so it just would be perfect for a comparision. 8800GTX and 4870 would be nice.

---

I am working on it.... hang tight. Just finished installing COH OP, this is darnedest most patched game in the history of gaming, everytime I started up the game -- You need a patch to continue, download?? WTF? Almost an infinite loop!

Quote:

---

Originally Posted by Extelleron

Jack have you ever tested the Phenom with increased northbridge (L3) frequency? I've always wondered what the impact of increased NB/L3 frequency is on Phenom but no sites have really tested this. I'd like to see how Phenom @ 2.5GHz core / 2.4GHz NB performs compared to the NB @ 2GHz.

---

Here you go... I did 1800, 2000, 2200, 2400 (2600 would not boot, though I have had it there before, not sure why at the moment). I ran 3DM06 and Everest memory benchmark and captured the screens. Again, I posted a link to the entire configuration of this system earlier in the thread... if you want me to re-link, let me know. This is done using a M3A32-MVP Deluxe board with DDR2-800 C4 RAM, a 4870 X2 with catalyst 8.8 drivers. 3DM06 was set to default, meaning 1280x1024.

Here are the screen shots.
http://forum.xcpus.com/gallery/d/747...B_3DMARK06.JPGhttp://forum.xcpus.com/gallery/d/748...B_3DMARK06.JPGhttp://forum.xcpus.com/gallery/d/748...B_3DMARK06.JPGhttp://forum.xcpus.com/gallery/d/748...B_3DMARK06.JPG

As one expects, the mem BW, L3 BW and latency track linearly with NB speed. 3DM06 score also tracks somewhat linearly, starting at 13232 for 1800 MHz NB and ending at 13553 for 2400 MHz NB speed.

What is interesting is the CPU score, it peaks at 2200 then starts down.... but I caution you on this... I need to repeat the run many many times to ensure that it is statistically valid... I have not done that.

I may spend some time collecting that information and write an article about the data...

Quote:

---

Originally Posted by JumpingJack

Hold on :) .... I applaud what he has done. He took the initiative to spend some energy to learn, rethink what he knows, and put that new knowledge to good use.

@ Gosh -- good job! This whole discussion has made me learn as well, I think overall it has been extra positive.

Jack

---

but why didn't he do that 2 months ago?
He based all his assumptions on that single forum posted comapring racedriver grid numbers. It would never come to my mind to say x processor beats y processor by only providing one sample of data...

as you know this is not the first forum he posted this, i think he doesn't expected to meet someone like you with a vast knowledge about cpus/silicon tech and the time and systems to give him real numbers.

For me his first post was a blunt attempt to start a flamefest, and i think even you saw it that way, when i look at the first page. ;)

anyways, with your help this topic turned way from a blunt flamefest to a very informative topic. :up:

Quote:

---

Originally Posted by gosh

But why are most gamers using intel then? And why do they overclock?
The processor doesn't matter but the communication between processor and hardware, memory speed does matter when it comes to min fps.

---

simple, most gamers also do other thing then gaming. For myself i run boinc, and intel is way faster in the projects i run then amd.

Also -> overclocking raises your min fps, thats why you see gamers overclock there systems.

Quote:

---

Originally Posted by Hornet331

but why didn't he do that 2 months ago?

---

Did you know how the processor works in games and how games are beeing developed?

Quote:

---

Originally Posted by Hornet331

He based all his assumptions on that single forum posted comapring racedriver grid numbers. It would never come to my mind to say x processor beats y processor by only providing one sample of data...

---

But facts and information that has been shown here seem to confirm that MIN FPS (maybe the lowest 1-3%) which would be the most important measurements on low res (640x480) is the most important test if you want to check how good the processor is for that game.
Single threaded games the processor is probably not any problem today. You can run ALL single threaded games on new processors. What matters is the video card.

Threaded games and the processor will be more important but all these average or max FPS is of no use if you want to test how the game behaves.

Quote:

---

Originally Posted by Hornet331

simple, most gamers also do other thing then gaming. For myself i run boinc, and intel is way faster in the projects i run then amd.

Also -> overclocking raises your min fps, thats why you see gamers overclock there systems.

---

OT
I am working with Visual Studio every day (developing analytical software for information stored in databases, both for servers and clients). When they test Visual Studio do you know how they test it? They test the compile time for ONE application. This is almost of no use to test how the good the processor is, very little.

If I am doing one release then there about 4 or 5 projects that need to be compiled, I don’t sit and wait for each to run one at the time. I have some addins in the environment that helps med writing code. I also run vmware and of corse there are a lot of databases. Think that over 90% of all applications done is using databases. One good flow when you write code is very important. Beeing able to work with other tasks if you do one long compilation is also good.

When there was single core processors out then the performance on how fast ONE application was would be important. Today in a multithreaded world and if you work professionally. The performance of ONE applications isn’t that important anymore. If you don’t take advantage of multithreading and are using applications that will need to some time to do work, then you are not working efficiently.

Quote:

---

Originally Posted by gosh

Did you know how the processor works in games and how games are beeing developed?

---

i have more then 10 year experience as a gamer with games and various systems, so yes i dare to say i know how a processor works and what it influcences in games. For the second point i dont care, since i only play them i dont need to know what development method the use, be it classical project menagment or another style.

Quote:

---

Originally Posted by gosh

But facts and information that has been shown here seem to confirm that MIN FPS (maybe the lowest 1-3%) which would be the most important measurements on low res (640x480) is the most important test if you want to check how good the processor is for that game.
Single threaded games the processor is probably not any problem today. You can run ALL single threaded games on new processors. What matters is the video card.

Threaded games and the processor will be more important but all these average or max FPS is of no use if you want to test how the game behaves.

---

you blow the min fps as factor way out of porpotion, yes as a gamer i know how importnat min fps is and in fast first person shooter fps decide about who is winning and who is loosing.

But min fps is ONE, i repeat ONE point, lets take jacks fear benchmark as example:

http://forum.xcpus.com/gallery/d/743...9850vs9650.JPG

http://www.xtremesystems.org/forums/...&postcount=281

The amd rig @ 3ghz has higher min fps but lower avrg fps, as gamer i'll take higher avarage fps over a seconed (or less) lower min fps.

Quote:

---

Originally Posted by Hornet331

The amd rig @ 3ghz has higher min fps but lower avrg fps, as gamer i'll take higher avarage fps over a seconed (or less) lower min fps.

---

Single threaded games should be better on Intel when it comes to MIN FPS also, it is a bit strange that AMD did win a MIN @ 3.0 GHz. If they are testing MIN for less time then one second then it would be more logical to see higher MIN because higher memory bandwidth ore something like that. One second for one processor is a very long time.

I did some reading about how they count FPS (min and max). It seems that every game counts frames in some relation to time in order to know how much they need to move parts. They have a game loop (some games anyway). If the game is single threaded it is also important for the reading of the mouse (how accurate that will be) and keyboard.

They don’t seem to count FPS in respect of delta between two frames and present that score. This can be a bit risky also because there are probably some things that could happen on the computer and there will be extra time between two frames, maybe textures will need to be reloaded etc. And then MIN FPS could less then 10 but that will not be a number that is important for the game play and it will be bad advertising for the game.

It is possible to hook into DirectX and create one application like Fraps. I will try to do one application that does this when there is some time over here.

Quote:

---

Originally Posted by JumpingJack

Here you go... I did 1800, 2000, 2200, 2400 (2600 would not boot, though I have had it there before, not sure why at the moment). I ran 3DM06 and Everest memory benchmark and captured the screens. Again, I posted a link to the entire configuration of this system earlier in the thread... if you want me to re-link, let me know. This is done using a M3A32-MVP Deluxe board with DDR2-800 C4 RAM, a 4870 X2 with catalyst 8.8 drivers. 3DM06 was set to default, meaning 1280x1024.

Here are the screen shots.
http://forum.xcpus.com/gallery/d/747...B_3DMARK06.JPGhttp://forum.xcpus.com/gallery/d/748...B_3DMARK06.JPGhttp://forum.xcpus.com/gallery/d/748...B_3DMARK06.JPGhttp://forum.xcpus.com/gallery/d/748...B_3DMARK06.JPG

As one expects, the mem BW, L3 BW and latency track linearly with NB speed. 3DM06 score also tracks somewhat linearly, starting at 13232 for 1800 MHz NB and ending at 13553 for 2400 MHz NB speed.

What is interesting is the CPU score, it peaks at 2200 then starts down.... but I caution you on this... I need to repeat the run many many times to ensure that it is statistically valid... I have not done that.

I may spend some time collecting that information and write an article about the data...

---

Very interesting..... the memory performance rises very nicely, a 10ns reduction in latency + a nice increase in bandwidth just by increasing the NB speed 20%.

Can you run any gaming tests comparing 2.0GHz / 2.4GHz NB speeds?

I really wish review sites were as comprehensive as you :up:

If you look closely you can see for example that:
HDR Canyon flight goes from 85.8 to 88.1 fps

and so on, guess it should translate same way to normal games.

Did some testing with crysis at different NB speeds.

In an not GPU bound scenario you can see quite a bit performance gain.

pictures NB 2000MHz vs. 2400MHz. CPU at 3100MHz in both cases

And another strange thing.

I overclocked from 3100Mhz to 3316Mhz and my MIN FPS jumped from 20 FPS to 85 FPS???????????
Lol strange.

Edit: seems to be a windows issue. did every test after a fresh windows boot and wait 3 minutes. Repeated the tests without reboot later
And enabling the red dot in AOD gave me boost of min fps between 5-8 fps which is alot.

Quote:

---

Originally Posted by xPliziT

And another strange thing.

I overclocked from 3100Mhz to 3316Mhz and my MIN FPS jumped from 20 FPS to 85 FPS???????????
Lol strange.

---

I have checked different crysis results and the MIN FPS seems to be completely random :).

Guys dont look on that freakin min fps. I mean this can only be ONE Fps of an overall FPS around 1000 and more and just means nothing. If you want to focus on the "overall min fps" you have to provide a slide recorded all fps.

Quote:

---

Originally Posted by Boschwanza

Guys dont look on that freakin min fps. I mean this can only be ONE Fps of an overall FPS around 1000 and more and just means nothing. If you want to focus on the "overall min fps" you have to provide a slide recorded all fps.

---

I disagree to an extent, but not completely ... min FPS means everything as it will relate to the quality of game play. The limited sampling of 'game' scene, any time the min falls below a playable threshold is related to how much 'stutter' and pausing you have in a game.

It also is useful to look at when analyzing the architecture, some segments of the script will be GPU taxing, other CPU taxing, and others both ... how a system behaves at min is important if you want to understand how it responds as a whole.

Quote:

---

Originally Posted by Boschwanza

Guys dont look on that freakin min fps. I mean this can only be ONE Fps of an overall FPS around 1000 and more and just means nothing. If you want to focus on the "overall min fps" you have to provide a slide recorded all fps.

---

i already said that. :yepp:

absolute min fps is worthless, same as max fps, what really counts is the avg. fps.

If you record a certain duration, you could try to get the median min fps.

Quote:

---

Originally Posted by xPliziT

And another strange thing.

I overclocked from 3100Mhz to 3316Mhz and my MIN FPS jumped from 20 FPS to 85 FPS???????????
Lol strange.

Edit: seems to be a windows issue. did every test after a fresh windows boot and wait 3 minutes. Repeated the tests without reboot later
And enabling the red dot in AOD gave me boost of min fps between 5-8 fps which is alot.

---

Not really strange -- unless it is very reproducible, after running it 4 to 6 times, is each run consistently 85 FPS? If it is always 85 FPS, then i think that is strange.

Crysis CPU test is physics and debris heavy, which is why the CPU test blows a lot of stuff up ... where as the GPU test is just a flyby (rendering heavy). Watch the CPU script run several times, while the trace/pattern is the same, the way things fall apart is much different, and the debris pattern, quantity is different -- so some randomness is not unexpected.

Quote:

---

Originally Posted by gosh

I have checked different crysis results and the MIN FPS seems to be completely random :).

---

See my post reponse above, this is not completely unexpected.

Run UT3, using a self-sustaining bot match ... a useful benching utility is UT3bench (google it) ... if you do, ping me for instructions... damn thing is buggy and it won't do what you want it to do unless you do something special first :) This will show you some real random variability :)

Quote:

---

Originally Posted by Extelleron

Very interesting..... the memory performance rises very nicely, a 10ns reduction in latency + a nice increase in bandwidth just by increasing the NB speed 20%.

Can you run any gaming tests comparing 2.0GHz / 2.4GHz NB speeds?

I really wish review sites were as comprehensive as you :up:

---

I will repeat Xplitz info below.

Quote:

---

Originally Posted by Hornet331

i already said that. :yepp:

absolute min fps is worthless, same as max fps, what really counts is the avg. fps.

If you record a certain duration, you could try to get the median min fps.

---

Or just use V-Sync at 60 FPS/60Hz to limit overall high FPS to get a good average of all the median/low fps. Thats the way i would do that.

Quote:

---

Originally Posted by xPliziT

And another strange thing.

I overclocked from 3100Mhz to 3316Mhz and my MIN FPS jumped from 20 FPS to 85 FPS???????????
Lol strange.

Edit: seems to be a windows issue. did every test after a fresh windows boot and wait 3 minutes. Repeated the tests without reboot later
And enabling the red dot in AOD gave me boost of min fps between 5-8 fps which is alot.

---

What graphics card? And I cannot go over 3.0 GHz, could you redo a run a 3 GHz to check, I will post the same shortly.

EDIT: I think there might be a windows memory leak somewhere, after 4 or 5 runs through the benchmark, I had issues to.

here is a quick and dirty Phenom/Crysis clockspeed/NB speed study....

I used the benchnark tool found at Guru3D, the setup of the system has been documented elswhere, if you want a link to full system specs let me know (I posted that several pages back). In short, the data collected here was done on a Phenom 9850 BE + Asus M3AMVP-Deluxe + DDR2800 C4 + ATI Radeon 4870 X2 with catalyst 8.8 drivers (EDIT: oops, my bad... looks like the SPD is defaulting it to C5 on the DDR2). The benchmark was ran to focus on the CPU, 800x600, low quality settings. I ran at 2.5 GHz and NB of 2000 and 2400, then again at 3.0 GHz with NB of 2000 and 2400 MHz. The results (screen shots) and output are posted below:

9850BE@2.5 GHz, NB=2000 MHz ave = ~ 112-113 FPS
http://forum.xcpus.com/gallery/d/750...MHz_CRYSIS.JPG
9850BE@2.5 GHz, NB=2400 MHz ave = ~ 115 FPS
http://forum.xcpus.com/gallery/d/749...MHz_CRYSIS.JPG
9850BE@3.0 GHz, NB=2000 MHz ave = ~ 125 FPS
http://forum.xcpus.com/gallery/d/749...MHz_CRYSIS.JPG
9850BE@3.0 GHz NB = 2400 Mhz ave = ~ 128
http://forum.xcpus.com/gallery/d/749...MHz_CRYSIS.JPG

I have also attached the log/output below (this provides all the details that screen shots cannot capture).

For a 400 Mhz increase in NB speed, the increase in frame rate for this configuration is 2-3 FPS, the minimums are random, take note there is some texture loading occurring mid game as can be seen by the first run always being lower on the first loop. A 500 Mhz increase in core clock speed improves FPS by 10-15 FPS on average, gain in this configuration. Remember that this is running the GPU test in all low settings. I am looking into setting all the CPU related settings (physics quality and particle quality to high). Finally, a combination of 400 Mhz NB and 500 Mhz core clock will yield 15-16 FPS improvement which is > 10%.

I will turn my attention next to a 2.5 GHz clocked 9650 and 3.0 Ghz clock 9650....

Jack

Ok, here is the QX9650 clock experiment... like the Phenom above, I ran the same crysis run (3 runs of 3 loops demo's on the stock CPU bench, all at low settings). The configuration is as identical as I can get it -- but, of course, MB and CPU are different -- Asus Rampage Forumla + QX9650 + DDR2-800 C5 + 4870X2, details of the config have been linked previously.

QX9650@2.5 GHz ave = ~ 152-158
http://forum.xcpus.com/gallery/d/750...owsettings.JPG

QX9650@3.0 GHz ave = 177-183
http://forum.xcpus.com/gallery/d/750...owsettings.JPG

So for a 500 MHz increase in clock, the QX9650 gains roughly 25 FPS ...

125/112 for Phenom is roughly 1.116 or 11.6% scaling for Phenom 2.5G->3.0G (NOTE: Comparing stock NB frequencies)
177/152 for QX9650 is roughly 1.164 or 16.4% scaling for QX9650 2.5G->3.0G

This needs to be qualified under the understanding of the configuration, these results are not going to be indicative of every CPU/4870X2 as chipset, mem speed, etc. change this scaling as well ... not to mention we are forcing an odd environment by running everything at very low res and low settings.

As with the Phenom experiment above, I attach the raw log file output below.

Jack

Wow thanks for those. Very interesting.

Jack i am going to re test now with 3GHz.

I dont have a 3870x2 or 4870x2 so my results are hardly comparable. I still have a HD2900XT 1GB.

Since you have a Intel quad and willing to test with could you please test this program for me on your intel?
If you run it write down the GigaFlops indicated on top of the window.
First after the program runs and then click in the middle of the screen until you only see stripes and then note the gigaflops again.

Maybe running it at diferent speeds also to see the scaling.

Ok here are the 3GHz tests.
I also used the AOD red dot feature to see what effect it has.

First picture: 3GHz, NB 2 GHz, no AOD
second picture: 3GHz, NB 2GHz, AOD red dot
third picture: 3GHz, NB 2.4GHz, no AOD
fourth picture: 3GHz, NB 2.4GHz, AOD red dot

^^^^ We are pretty darn close :) .... nice job. Thanks. It's the reproducibility that I am always wanting to see. Seeing your run get within 1-2 FPS of my runs is good.

Yeah, will run the program for you shortly.

EDIT: Get warning -- application configuration is incorrect, try re-installing.

Jack

Oh you need visual c++ 8 runtime installed

Quote:

---

Originally Posted by xPliziT

Oh you need visual c++ 8 runtime installed

---

:) Ha.... I will download it and install it. I think I have it saved somewhere :)

Nope, downloaded and installed VC++ 2005 SP1 redistributable, and same error.

Quote:

---

Originally Posted by Boschwanza

Or just use V-Sync at 60 FPS/60Hz to limit overall high FPS to get a good average of all the median/low fps. Thats the way i would do that.

---

i dont like v-sync espeical with lcds, in most cases it increases input lag. :(

Quote:

---

Originally Posted by Hornet331

i dont like v-sync espeical with lcds, in most cases it increases input lag. :(

---

Yes, but for comparision of median low FPS its perfect. You dont have it to use anyway.

*still waiting for the CoHOF benchmarks* :(

Quote:

---

Originally Posted by Boschwanza

Yes, but for comparision of median low FPS its perfect. You dont have it to use anyway.

*still waiting for the CoHOF benchmarks* :(

---

:) Working on it....

Quote:

---

Originally Posted by JumpingJack

:) Working on it....

---

:stick:

Quote:

---

Originally Posted by Boschwanza

:stick:

---

Ok... the reason this has taken me so long is that COH:OP is a new game to the benchmarking suite -- COH opposing force (I have the original COH installed) installation was tricky ... aside from not installing over COH correctly, it also is the most patched game on the planet.

If I cannot get an identical install on each rig (the Phenom and QX9650), then I start over and make sure that everything is identical. After a few attempts, I had to wipe the original COH and install new and fresh.

What I did: This is the first in several runs -- feel free to request specific items. Also, all the runs here are geared toward a CPU perspective, I will also be doing high quality/high AA setting runs as well. The configuration has been linked previously in this thread, briefly Phenom 9850 @ 2.5 GHz (stock)/QX9650 @ 2.5 GHz, Asus boards are the M3A32-MPV deluxe/Maximus Formula (X38), DDR2-800 C5, 4870X2 with Cat 8.8, WD Raptor 150 Meg, Windows XP SP2 ....

The runs were done at two resolutions. First, 1280x1024, with all low setting except physics which was set to high (CPU duty) and effects density was set to high. Then I ran the same settings but at 1920x1200. These were done using the -novsync command line which disables the 60 FPS limit, I also ran with the Vsync on by removing the -novsync command line. Finally, I collected FRAPs for the 1920x1200 run....

Phenom 9850 @ 2.5 Ghz
1280x1024, all low physics high, effects density high
http://forum.xcpus.com/gallery/d/756..._1280x1024.JPG
1920x1200, all low physics high, effects density high
http://forum.xcpus.com/gallery/d/756..._1920x1200.JPG
1920x1200, all low physics high, effects density high -- VSYNC thus 60 FPS
http://forum.xcpus.com/gallery/d/756..._withVsync.JPG

QX9650 @ 2.5 GHz
1280x1024, all low physics high, effects density high
http://forum.xcpus.com/gallery/d/755..._1280x1024.JPG
1920x1200, all low physics high, effects density high
http://forum.xcpus.com/gallery/d/755..._1920x1280.JPG
1920x1200, all low physics high, effects density high -- VSYNC thus 60 FPS
http://forum.xcpus.com/gallery/d/755...0_vsync_on.JPG

Note: In a fit of exhaustive stupor .. I mislabeld the JPG filenames for the QX9650 1920x1200 runs, it is is 1200 not 1280 ..

Finally, the 4 fraps traces for the 1920x1200 runs -- NOTE: the above screen shots were not running fraps as fraps induces a few FPS hit, these were separate runs -- and were within 3-5 Ave FPS of what is shown above.
http://forum.xcpus.com/gallery/d/756...ps_compare.JPG

A few notes to make ....

* Though at low settings graphically, 1920x1200 is still CPU bound -- this was not the case for my 8800 GTX which started becoming GPU bound at these graphical settings at 1600x1200. Demonstrating the power of the 4870X2.

* COH: OP is not a great game to use as a bench in this case, it way favors Intel architecture ... so it is not a generalized representative statement of the population of games.

* The most important point: Either CPU is capable of supporting > 60 FPS in the capped (synced) regime ... as expected. The take away is that the CPU will not matter to the overall quality of game play for this particular game (and I have done enough to say that as a generalized statement as well).

I will be following up with CPU utilization and high quality settings too, stay tuned....

Jack

First of all thanks for this, but i have to add some critical points.

CoHOF has the great advantage that it shows you which option in the graphic setup affects graphic card, processor and system memory (simply scroll over the options) .

So far physics only affects the cpu, but there are several options which affects cpu and graphic as well, like shadows, water reflection, landcape details, model details, effect playback, effect density and object shifting.

So i would recommend to add this options to your benchmark. Again, thank you. (A run with all settings high and AA would be nice too )

Quote:

---

Originally Posted by Boschwanza

First of all thanks for this, but i have to add some critical points.

CoHOF has the great advantage that it shows you which option in the graphic setup affects graphic card, processor and system memory (simply scroll over the options) .

So far physics only affects the cpu, but there are several options which affects cpu and graphic as well, like shadows, water reflection, landcape details, model details, effect playback, effect density and object shifting.

So i would recommend to add this options to your benchmark. Again, thank you. (A run with all settings high and AA would be nice too )

---

Yeah, I knew of this and when designing the processor centric settings I experimented with each to find the ones that impacted the performance most when changing CPU speed.... those were the two biggies, everything else convolutes the CPU vs GPU which I was trying to separate out....

Nonetheless, the more interesting stuff for most people are the settings that make the game fun and full of eye candy... still working on that, I should have it in the next day or so.

Jack

Thx for the comparsion JumpingJack,

could you please add your comparsion for both processors running the mandelbrot program?

And btw. not quite sure but running with physics high might be a double sided sword since all those effects need to be rendered also.
Best would be with physics low i guess although it lowers cpu activity.

Thanks jack, interesting results :)

I didnt read all the thread, but have you compared phenom and c2q in crysis on demanding settings ? To see if the phenom's I/O performance thing is true etc ?


PS: Just as an side note, some reviews like [H], and a few other sites, utilizes "average minimum" FPS, not absolute min. Absolute min FPS is not very usefull, but avg min is, imo at least, by far the most important thing when buying an card.

Quote:

---

Originally Posted by Tonucci

PS: Just as an side note, some reviews like [H], and a few other sites, utilizes "average minimum" FPS, not absolute min. Absolute min FPS is not very usefull, but avg min is, imo at least, by far the most important thing when buying an card.

---

problem with that: what is avg min fps?

there is no general definition of that, for avg fps on the other hand there is, same goes for absolute max and min.

Quote:

---

Originally Posted by Hornet331

problem with that: what is avg min fps?

there is no general definition of that, for avg fps on the other hand there is, same goes for absolute max and min.

---

Thats true...no general definition. And I may have exaggerated a bit about its importance :D

I dont know how they calculate...I could not find an answer... but looking at graphs, like [H]'s apples-to-apples graphs, I can see how much time each card stays at very low FPS, or how many dips.

Its not accurate at all, but still is an better indication of overall smoothness than avg or max fps imo.

an card can spend half of the game below 20 FPS, but if it gets 400fps for a few minutes, the avg fps may be high. In this example, gameplay would be horrible, despite the high avg and max FPS.

Reviews can be misleading in that sense...so we have to look at the overall picture.

i dont want to de-rail this thread, but i felt like i had to explain myself, as I was very vague :)

Quote:

---

Originally Posted by Tonucci

an card can spend half of the game below 20 FPS, but if it gets 400fps for a few minutes, the avg fps may be high. In this example, gameplay would be horrible, despite the high avg and max FPS.

---

actually no, cause if a game spends most of the time at 20fps a few minutes won't increase the avarage fps dramatically.

Sample calculations for one minute:

20 FPS for 30 seconds, 100 FPS for 20 seconds, 400 FPS for 10 seconds
Average = (20 * 30 + 100 * 20 + 400 * 10) / 60 = 110 FPS

25 FPS for 30 seconds, 80 FPS for 20 seconds, 200 FPS for 10 seconds
Average = (25 * 30 + 80 * 20 + 200 * 10) / 60 = 72,5 FPS

20 FPS for 1 second, 100 FPS for 59 seconds
Average = (100 * 59 + 20) / 60 = ~99 FPS

Quote:

---

Originally Posted by Hornet331

actually no, cause if a game spends most of the time at 20fps a few minutes won't increase the avarage fps dramatically.

---

The example may not be accurate but i hope you got the point :)

Thanks for taking the time gosh, shows what I meant.