The Power of ID?
- Thread starter jasonjlee
- Start date
Jerry Cornelius
Newcomer
Q3 ran on my TNT 1.
Chalnoth said:Actually, from what I've been reading, the shadows are going to make it much more GPU limited than the previous engines (The same goes for the new Unreal engine...though they've also added a lot of CPU-intensive tasks to bring the CPU requirements up as well), with approximately 2-3 passes over the entire scene per light source.
Just based on the fact that games cannot easily scale how much processing needs to be done on the CPU, good engines will always try to not put too much pressure on the CPU.
Oh, and Hammer will be a beast in processing power, particularly for programs compiled for itI just hope that AMD has the foresight to include support for DDR400 and DDR II in the initial release...anything less would be a serious mistake.
Carmack needs to make his games more cpu-dependent than he's been used to else offering SMP options for his software will seem mainly an exercise in futility (sure doesn't help the current Q3 very much--if at all.)
Instead, as Carmack has indicated that he prefers nVidia products as his build baseline, it seems to me he's doing a sort of "ass backwards" cpu dependency which does nothing to scale his software with faster/additional cpus.
nVidia chips have always been abundantly cpu dependent. The nv25s are certainly no exception. In most of the testing I've done I see 100% cpu monopolization by the nVidia GPU. Want your Geforce 4 Ti4600 to run faster? Well, throw it a more powerful cpu and you'll get it....
While Carmack is throwing most of his code at the GPU, the nVidia GPU in turn is throwing much of its work to the cpu. So in an "ass backwards" kind of way, Carmack's code is very much cpu dependent--without the benefits of scaling, however. That's why I think he needs to write more of his code directly to the cpu than he presently does.
DDR 400 will most likely be stillborn, as few DRAM manufacturers will actually make a JEDEC-spec'ed DDR 400 (just as few of them now make JEDEC-compliant PC2700--apart from Crucial, I don't know of anyone else who does.) DDR II most likely will not be in wide circulation until mid-'03 to mid '04 (your guess is as good as mine), so there's absolutely no rush at all to manufacture a Hammer with a DDRII ram controller right now (what would they even test it with, for gosh sakes?)
Secondly, there will be as much as a 25% improvement in latency between the DDR 333 controlled by Hammer and the DDR 333 currently controlled by off-cpu memory control chips. This means that Hammers will run quite a bit better under DDR 333 than current cpus will run with it.
Third, as Hammer of course will receive periodic refreshes for MHz ramps and revisions, AMD can easily put in a newer memory controller as time goes on--but when the time is right. Believe me--DDR 400 versus DDR 333 in Hammer systems will produce very little performance gain (and this is assuming companies actually jump on the "DDR 400" bandwagon in the first place), and DDRII is completely useless at present and will likely be so for at least another year.
Doomtrooper said:Nagorak said:
Quake 3 had support for the low end ?? Hardly...and yes those early engines came with software renders, Unreal did too...this was also when my company was in its prime and 3D acceleration was just starting to get attention...the excuse for software now is moot.
I intenionally ran two demo computers in the display room with Quake 2 running on a Voodoo 2 and the other running on a S3 Trio in software...lets just say people didn't take too long to make up their mind.
I'm willing to bet you are wrong, as the most popular request we had when I ran my company was I need better 3Dmarks or I want to run Quake 2/Unreal in 3D mode
Well we're not going into how many people would never even play Q3 or Unreal to want to upgrade, if it had such low compatibility with crappy hardware. I never said Q2 ran great in software (never tried it honestly) nor that Q3 ran great on a TNT2. I was simply pointing out that id with Doom3 is doing the exact same thing they have done with previous games.
It's ridiculous to think they'd suddenly abandon the low end completely. And while they technically "could", the repercussions for doing so would far outweigh the minute benefits of it, such that they'd never actually do it.
Having played on a rig with dual processors and then the same rig with only, one, it's a world of difference. You don't get higher peak frame rate, you get higher low framerates. I can definately feel the difference.
As for utilizing CPUs in an SMP configuration, well the data set for calculating shadow volumes on models, to me seems really nicely divisible. So having two processes on each CPU churning out shadow volumes should make a significant difference. This is just one of many uses, but this should be a fair speed boost in CPU limited situations.
I figure the amount of CPU power that's going to be used for Doom 3 will be quite high. The physics, AI and sound alone are going to be a handful. Not to mention graphics calculations.
Carmack stated in the past that he could have had the CPU do more and make it run like 5% faster but running the code using TnL etc on the GPU was slightly slower on the top end systems but freed the processor up allowing it to crunch the AI and physics data.
So.. er... Im sure Carmack has explored relying on the CPU more already and found it to be a bad idea in the long term.
So.. er... Im sure Carmack has explored relying on the CPU more already and found it to be a bad idea in the long term.
Saem said:
Just out of curiosity, on the dual rig where you got a better minimum frame rate but no increase in the maximum frame rates, to what would you attribute this? A ceiling in fill rate or cpu?
I agree with you that Doom 3 will probably be more cpu-dependent than Q3, but it will be interesting to see how much proportionately. Main requirement for good scaling with SMP is being multithreaded--and I think Q3 has about 1 thread....but when a lot of your code is written to the GPU being multithreaded has no meaning.
misae said:
Never think that what a single programmer does is ever "right" because there are no "rights and wrongs," only "proficient and poor"...
Lots of programmers are proficient, still more of them are poor programmers. But of those who are proficient I think it's a mistake to say one is "right" where the other is "wrong." Programmers have their own inimitable styles, but the bottom line for all of them is proficiency.For instance, programs that are typically more cpu dependent than GPU dependent--such as UT, for instance--ought to scale far better than programs which are GPU dependent primarily, like Q3. That's why generally Q3 is considered a much better benchmark for evaluating among videocards (if we assent they are equal in OpenGL drivers) than programs like UT. Whereas programs like UT show little performance difference when testing comparable videocards on the same cpu, programs like Q3 will show marked differences among videocards running on the same cpu.
Carmack does write to the GPU moreso than other programmers--like Sweeny for instance--and my comments weren't made to suggest that what he was doing was "wrong" in any sense. It's just that to scale with multiple processors well you need multithreaded applications, and Q3 really doesn't have but a single thread (I think.) Of course, when writing to the GPU being multithreaded does you no good.
Maybe the idea of use the HW T&L is not only free the CPU to do other things.
-Now you have a single place to concentrate your development efforts.
-The performance will be more predictable.
-Upgrades are easier/cheaper, concentrate mainly in the GPU (hw T&L and fillrate).
-People with slower CPUs will have a much better experience. It means a larger audience.
-Now you have a single place to concentrate your development efforts.
-The performance will be more predictable.
-Upgrades are easier/cheaper, concentrate mainly in the GPU (hw T&L and fillrate).
-People with slower CPUs will have a much better experience. It means a larger audience.
What will make it more or less CPU dependent is the number of polygons.
For example see the 3Dmark2001 car chase Pure HW T&L:
-with "low" detail it has up to 170kpolygons and will be GPU limited.
-with "high" detail it has up to 350kpolygons and is CPU limited (scalle nicelly with CPUs faster then 500MHz).
The point is at some point the CPU has a lot of work to push/drive the GPU without adding much more detail and decreasing the quality of the experience.
The use of "low" polycount with Doom3 was probably a technical decision to keep the CPU more free.
For example see the 3Dmark2001 car chase Pure HW T&L:
-with "low" detail it has up to 170kpolygons and will be GPU limited.
-with "high" detail it has up to 350kpolygons and is CPU limited (scalle nicelly with CPUs faster then 500MHz).
The point is at some point the CPU has a lot of work to push/drive the GPU without adding much more detail and decreasing the quality of the experience.
The use of "low" polycount with Doom3 was probably a technical decision to keep the CPU more free.
I really think programmers should start moving all graphics calculations to the GPU (or VPU ) and making their programs GPU limited. Isn't that the whole point of these new programmable GPUs to make it so they can do more graphics work?
In my opinion the CPU should be reserved for AI, physics and so forth, no graphics whatsoever outside of what it has to do to set the calculations up for the card.
Also: this approach should make for a better gaming experience in general. Since graphics cards are designed from the ground up for gaming whereas CPUs are multipurpose, it only makes sense that a specialized part will do the job better and faster. Anyway, now that we have $300+ graphics cards, it'd be nice to be able to get away with a $100 or less CPU.
) and making their programs GPU limited. Isn't that the whole point of these new programmable GPUs to make it so they can do more graphics work?In my opinion the CPU should be reserved for AI, physics and so forth, no graphics whatsoever outside of what it has to do to set the calculations up for the card.
Also: this approach should make for a better gaming experience in general. Since graphics cards are designed from the ground up for gaming whereas CPUs are multipurpose, it only makes sense that a specialized part will do the job better and faster. Anyway, now that we have $300+ graphics cards, it'd be nice to be able to get away with a $100 or less CPU.
I'm pretty sure it was the CPU. The two CPUs were Celeron 333@501 with a Radeon. I'm pretty sure the CPUs were the limiting factor, I didn't get much slow down with a large number of people on the screen. I was playing the Q3F mod at this point.
Quake 3 has more than one thread -it might be processes under Linux. The UI, physics, graphics and sound and so on are all different threads, that can for a good amount execute independently and not block each other.
Well unless we're talking about the P10, which I believe generates the shadow volumes on board and alleviates a lot of work from the CPU, multithreading the CPUs protion of the graphics work would be benifical, seeing as the data set would be easily divisble.
Nagorak said:
A list would be nice. Both because it would be illustrative, and because I could make sure I wasn't forgetting somthing when doing my back-of-the-envelope estimations.
Also: this approach should make for a better gaming experience in general. Since graphics cards are designed from the ground up for gaming whereas CPUs are multipurpose, it only makes sense that a specialized part will do the job better and faster. Anyway, now that we have $300+ graphics cards, it'd be nice to be able to get away with a $100 or less CPU.
You do. An AthlonXP 1800+ is $79 on pricewatch....
$300 would easily buy motherboard, CPU and half a GB of memory. The gfx-card part of the PC has really skyrocketed, relatively speaking.
Entropy
Similar threads
- Locked
