Sign in with
Sign up | Sign in
Your question

Is the GPU centric computer the future?

Tags:
  • CPUs
  • GPUs
  • Computer
  • Product
Last response: in CPUs
Share
March 8, 2002 8:16:14 PM

I was reading about the new Video card architectures and specs when it dawned on me that, perhaps, today's personal computer should be built around a GPU rather than a CPU! After all, both the GPU and the CPU are big 25+ million transistor devices fabrication using the latest >0.25 micron processes.

(1) Think about it, the kind of application that a typical home or office user runs does heavy duty processing only when dealing with graphics and sound processing. I mean if you take out 3D games, photo-editing, playing back compressed movies or sound files, and the like, all you are left with is the word processor, the spread sheet and perhaps the web browser. And even for these, if we can be assured that everything to do with displaying the GUI is taken care of, all you are left with is simple, not particularly intense computations that 386 or 030 level CPU power is quite sufficient for!

(2) Hence, I was force to question as to why the computer is still built around the CPU with a GPU on some graphics cad sitting multiple bridges away on the slow PCI bus to support it. Why not the other way around? Why not have a GPU in the Geforce4 class, build the whole architecture around it and throw the CPU out. Everything on the computer supports the video chip. 3D and 2D graphics will be blisteringly fast. The chip handles JPEG, MPEG, PNG, MP3 and other graphics/sound compression/decompression at the hardware level. It also, supports matrix manipulation, 3D transforms, 2D scaling and rotation, etc at the hardware level. On the rare occassion that general computing is required it has the supplementary instruction set of a 286 class CPU running at a decently high clock speed (compared to the 286 that is).

(3) Instead of having the a big, complex, general purpose CPU powerhouse like the Itanium or Hammer, why not have a powerful GPU as the core of the system and have the general purpose instructions given a paltry 1 million transistors, one instruction pipe, non-superscalar, attention as a supporting part of the graphics chip? Won't this put performance where it counts?

(4) Also, instead of having to upgrade the CPU and the video card to get better performance, the user simply upgrades the CGPU!

<P ID="edit"><FONT SIZE=-1><EM>Edited by dwight_looi on 03/08/02 05:21 PM.</EM></FONT></P>

More about : gpu centric computer future

March 8, 2002 8:27:06 PM

I got one word for you. “Physics”

If you want good games with realistic actions within them, you have to have a processor that can do these calculations for you.

All errors are undocumented features waiting to be discovered.
March 8, 2002 8:56:50 PM

Quote:

I got one word for you. “Physics”

Why can't a GPU be designed to also handle physics? Imagine it! That would be amazing. Unless you're designing a game or program that requires physics that doesn't apply in reality, the GPU can be integrated with the ability to execute certain physics algorthims.

In the future (like with T&L) a programmable Physics unit may be designed, but currently all games aim to apply realistic physics rather than custom game specific physics.

AMD technology + Intel technology = Intel/AMD Pentathlon IV; the <b>ULTIMATE</b> PC processor
Related resources
March 8, 2002 9:06:13 PM

however - a PC is powered by a native instruction language that take cares of the PC architecture (I/O, memory etc...) and controls and manages all of your PC devices (including the Graphic card).

this is why a CPU is the center of the PC - the CPU and the Chip-Set are the only components who can manage the computer.

you would need to emmbed such features into a GPU in-order to make it the "center" of your computer - but it will no longer be a GPU... it will be a CPU + GPU...

This post is best viewed with common sense enabled
March 8, 2002 9:21:01 PM

Quote:
I was reading about the new Video card architectures and specs when it dawned on me that, perhaps, today's personal computer should be built around a GPU rather than a CPU!

This is exactly what nVidia's marketing department is attempting to push on the industry. They would love to be the center of the universe.


Quote:
After all, both the GPU and the CPU are big 25+ million transistor devices fabrication using the latest >0.25 micron processes.

The current Pentium 4 uses a 0.13 micron process. Next year we move to 90nm (0.09 micron) process.


Quote:
(1) Think about it, the kind of application that a typical home or office user runs does heavy duty processing only when dealing with graphics and sound processing. I mean if you take out 3D games, photo-editing, playing back compressed movies or sound files, and the like, all you are left with is the word processor, the spread sheet and perhaps the web browser.

3D games can be processor intensive due to AI routines, input device processing, sound processing, etc. Photo-editing only uses the video card for displaying the end-results. The actual transformations and other features are all done through the CPU. Playing compressed movies requires the CPU to decompress the stream at a high rate of speed. The video card only does one thing, but it does it well. It renders and fills polygons. The CPU does everything else in the system. The CPU certainly handles a great deal more than the video card on a regular basis.


Quote:
(2) Hence, I was force to question as to why the computer is still built around the CPU with a GPU on some graphics cad sitting multiple bridges away on the slow PCI bus to support it. Why not the other way around? Why not have a GPU in the Geforce4 class, build the whole architecture around it and throw the CPU out.

Because then your computer would not be able to do anything. ;)  Sure the video card knows how to push polygons to the screen. But it is the CPU that tells it which polygons and of what shape. The video card is the servant (albeit a fast servant.) The CPU is the master.


Quote:
(3) Instead of having the a big, complex, general purpose CPU powerhouse like the Itanium or Hammer, why not have a powerful GPU as the core of the system and have the general purpose instructions given a paltry 1 million transistors, one instruction pipe, non-superscalar, attention as a supporting part of the graphics chip?

I do not know about you, but I certainly do not want to play games that are all eye-candy and no content. I want real processing power put into my games with real AI and complex interaction. Eye candy is just icing on the cake.

-Raystonn


= The views stated herein are my personal views, and not necessarily the views of my employer. =
March 8, 2002 9:23:40 PM

You can also spin that around... Why not have the GPU become part of the CPU? Last I checked, CPU speeds were much higher then GPU's are currently. Imagine a Radeon 8500 or a Ti4600 running at 2 GHz?

It would be similar to when (way back) CPU's used to have separate math co-processors which are now completely integrated together. Sure the chip will be twice as big, require much more cooling and cost a lot to design, but once it hits the market it would be unstoppable.

I guess thats just wishful thinking...
March 8, 2002 9:37:18 PM

Just hypothetically, consider this. The GPU sits atop the north bridge. The GPU has access to the however many sticks od DIMMs or RIMMs you have as main memory. The GPU writes directly to the video output rasterizer. The rest of the stuff -- PCI masters, IDE, basic I/O, etc -- sits on the south bridge. AND there is a 386DX sitting on the PCI BUS with 64MB of "instruction memory" to do the low performance, mundane, stuff that occasionally needs doing. Basically we swap the position and importance of the CPU and the GPU. Now, of course, we can also moved a low performance "386DX" in as part of the motherboard chipset or build it as a SMALL part of the GPU. Won't that work? Won't that put the emphassis of power where it counts more?

The general purpose co-processor doesn't have to be really powerful because once you distill all the applications down the hardcore processing isn't in deciding the position of the justified text in a word processor or position of the entities in a real time strategy game or xyz co-ordinates of the objects in a flight sim. The hardcore processing is in transforming large polygonal models, textures and sound to make a live-like scene out of the simple data structures representing the virtual world. For all intents and purposes, if you remove the fancy graphics and sound, the applications of today isn't very much more computation demanding than those of the 68000/80286 era. Need a real life example? IF this isn't the case, the game consoles like the PS2 with a paltry 300MHz processor and 32MB of memory won't be able to make great physics model like those in GranTurismo3 work!
March 8, 2002 9:44:40 PM

Physics on the GPU, or a separate PPU? (Now that has some French marketability) You definitely have a good point. I can see how certain calculations like collision detection could be grafted into a GPU. I would be equally amazed if it came without a price on the GPU. It all comes down to the jack-of-all-trades, master of none argument.

All errors are undocumented features waiting to be discovered.
March 8, 2002 9:53:31 PM

A physics engine will come alone eventually, but you need algorithims that do it before we can have hardware the make it fast. 3D models will still sink into a wall in game.

"Ignorance is bliss, but I tend to get screwed over."
March 8, 2002 10:09:14 PM

As long as all the games are based on the same physics, developing standard algorithms that would be accelerated by the GPU could work. Now, I don't agree with what one person said that all you need is a 386DX because a GPU wouldn't be able to accelerate floating point and integer operations of non-graphical programs. However, processing physics through the GPU will remove the constant need for faster processors for a while.

AMD technology + Intel technology = Intel/AMD Pentathlon IV; the <b>ULTIMATE</b> PC processor
March 8, 2002 10:19:09 PM

Thre is and has been work on "computer on a chip" which would do everything. This is about as close to what your talking as it comes! One day we will have one chip and one pcb.....

Jesus saves, but Mario scores!!!
March 8, 2002 10:28:10 PM

It would seem efficient to have an area of the GPU where a few vectors could be stored. These vectors would be collision detected against any geometry thrown into the system. Of course geometry could easily be excluded as this collision detection based on a state flag. One foreseeable problem is there is often projection information stored in the matrices driving the geometry engine. However, this could easily be compensated by separately calculated matrices that do not contain this information, consequently theses matrices would have to be created on the CPU, thus adding another reason for a powerful CPU.

All errors are undocumented features waiting to be discovered.
March 8, 2002 10:57:33 PM

If the games you play are not computationally expensive, then I question your taste in games. ;)  I believe most of us got bored of Quake 3 Arena after two weeks. It was all eye candy and no content. The same could be said about any game that uses very little CPU to perform realistic AI, alterable content, and a great plot. I actually had much more fun playing the text-based games of yesterday than I do playing most games released today.

One of the main reasons most games today are so similar is they all use the same hardware features on the video card. These features tend to lock you into a similar template. There is simply no way to "think outside the box" if you need to stay inside the box that is your video card in order to get the game to run at reasonable speeds. A real CPU offers much more flexibility and power to do whatever your imagination dreams up.

If you start adding more and more features to your video card, pretty soon it becomes a general purpose CPU. The graphics chip companies are more than welcome to try to compete in the CPU market, but they have a long learning curve ahead of them. Simply defining the graphics chipset as the brain is not going to actually change which component really is the brain.

-Raystonn


= The views stated herein are my personal views, and not necessarily the views of my employer. =
March 8, 2002 11:10:04 PM

What I would prefer to see is memory bandwidth to the processor increased sufficiently to allow the actual CPU to take over the 3D processing functionality of the video card.

The reason 3D accelerators came into existence is the processor simply could not pump enough pixels from memory to the video framebuffer on the video card. The main reason for this was low memory bandwidth and low bandwidth to the video card. Now that we have increased AGP transfer speeds, all we need is higher memory bandwidth to the processor and we can actually get rid of the 3D accelerator portion of the video card entirely. This would free us from the contraints of the various 3D APIs such as DirectX and OpenGL, which constrict us to various depths and clipping planes, forcing games on us that look almost exactly like one another, except for minor graphical differences.

Imagine game worlds where you can break a branch off a tree and use it to knock someone over. Video cards have an extremely difficult time with any scene that actually changes. They completely rely on models being predefined and stored in the video card's memory. Move the processing back from the video card over to the CPU and we would eliminate these problems.

-Raystonn


= The views stated herein are my personal views, and not necessarily the views of my employer. =
March 9, 2002 12:45:08 AM

Quote:
big 25+ million transistor devices fabrication using the latest >0.25 micron processes.


<.25*

"The Cash Left In My Pocket,The BEST Benchmark"
No Overclock+stock hsf=GOOD!
March 9, 2002 12:52:42 AM

Quote:
What I would prefer to see is memory bandwidth to the processor increased sufficiently to allow the actual CPU to take over the 3D processing functionality of the video card.


The 3d graphics chip is hardwired to do graphics, if you had to emulate that with software, even with huge bandwith, you would still not get the same performance.


Try running quake 3 in hardware mode, then run it in software, you probably are seeing a 1000% drop in speed if not more, you would have to increase bandwith and cpu speeds to match that, not bearing in mind the other things the cpu does during a game, I just dont see it hapening.


Quote:
3D APIs such as DirectX and OpenGL, which constrict us to various depths and clipping planes, forcing games on us that look almost exactly like one another, except for minor graphical differences.


????

You seem to be confusing a static tl system with an api.


Quote:
Imagine game worlds where you can break a branch off a tree and use it to knock someone over. Video cards have an extremely difficult time with any scene that actually changes. They completely rely on models being predefined and stored in the video card's memory. Move the processing back from the video card over to the CPU and we would eliminate these problems.


A good model is made up of many parts, which can be used seperatly, there is a game(forget the title) where you can blow off an enemies arm and bash him with it.

The api and graphics processor has nothing to do with the features you mentioned.

"The Cash Left In My Pocket,The BEST Benchmark"
No Overclock+stock hsf=GOOD!
March 9, 2002 1:17:38 AM

Actually it does. I want to be able to break apart that tree in any fashion I desire, not just where some 3D modeler decided it would create a place for me to do so. The ability to actually morph objects is important to the next generation of games. 3D cards do not have this ability. In fact they slow down the whole process by requiring you to transfer the model over to the memory on the video card each time you change one little thing. The current form of video card is simply not designed with this type of thing in mind. They are simple polygon pushers; not all that advanced in terms of algorithms.

The last great innovations in the industry came about with Quake. Carmack did some incredible optimizations and implemented the entire thing in software. Since that date DirectX and OpenGL have taken over much of the work, pushing the triangle work onto the video card. I have honestly seen very little innovation since that time.

DirectX started out as an API implemented mostly in software, full of good ideas that had been innovated in software. Gradually the video cards filled in the functionality and took over implementing these functions. Since then I have not seen any algorithm innovations in DirectX beyond what the video card companies have decided to add, which is not much. The gaming industry now sits there waiting for the video card industry to come up with the next best thing rather than innovating themselves. This is a huge loss for gamers.

Either software developers need to start innovating themselves, working without the benefit of a 3D accelerator, or Microsoft needs to start coming up with some new innovations and implementing them in Direct3D in the HEL. Hardware support can come later if companies such as nVidia decide to implement these features, but new features should not require video card hardware support as a prerequisite. This stifles creativity.

-Raystonn


= The views stated herein are my personal views, and not necessarily the views of my employer. =
a b à CPUs
March 9, 2002 2:51:22 AM

The Cyrix MediaGX tried that and stunk at it. The processor was neither good at traditional calculations nor games, it was a compromise that barely worked.

What's the frequency, Kenneth?
March 9, 2002 3:02:46 AM

Quote:
Actually it does. I want to be able to break apart that tree in any fashion I desire, not just where some 3D modeler decided it would create a place for me to do so. The ability to actually morph objects is important to the next generation of games. 3D cards do not have this ability. In fact they slow down the whole process by requiring you to transfer the model over to the memory on the video card each time you change one little thing. The current form of video card is simply not designed with this type of thing in mind. They are simple polygon pushers; not all that advanced in terms of algorithms.


Its a good thing the cpu sets up all models isnt it then, the gpu ONLY draws what the cpu tells it, there is no limit that the gpu places on games which would not be there if the cpu did everything.

Also, the models would all be there in the first place, you wouldnt need to resend a model if you changed it.

Quote:
The last great innovations in the industry came about with Quake. Carmack did some incredible optimizations and implemented the entire thing in software. Since that date DirectX and OpenGL have taken over much of the work, pushing the triangle work onto the video card. I have honestly seen very little innovation since that time.[/qupte]

Youre not looking very hard, have you seen the nature demo on 3dmark2001, that is NOT possible without a good dx8 videocard, and to do it in software would ensure less than 1 fps.


Quote:
DirectX started out as an API implemented mostly in software, full of good ideas that had been innovated in software. Gradually the video cards filled in the functionality and took over implementing these functions. Since then I have not seen any algorithm innovations in DirectX beyond what the video card companies have decided to add, which is not much. The gaming industry now sits there waiting for the video card industry to come up with the next best thing rather than innovating themselves. This is a huge loss for gamers.


I guess thats why when programable gpu engines were released on the gf3 and 8500, all the games now are designed specifically for them, oh wait, they arent.

Computer power as a whole is what has limited game design, and high end gpus like ati's and gf3's are now finally allowing game designers to make groundbreaking games.

Moving everything to the cpu does not work, and the current designs of cpus would make any move to do such foolhardy, redesigning a cpu to do graphics anywhere near as well as a gpu would turn the cpu into a gpu in itself!


Quote:
Either software developers need to start innovating themselves, working without the benefit of a 3D accelerator, or Microsoft needs to start coming up with some new innovations and implementing them in Direct3D in the HEL. Hardware support can come later if companies such as nVidia decide to implement these features, but new features should not require video card hardware support as a prerequisite. This stifles creativity.


You can emulate programable pixel shaders, at 0.01 fps!!!

If you want all the eye candy to be in software, you should get on intel to make that 10ghz p4, because there is FAR from enough cpu power to come even close to anything currently available on the market today.(done via gpu)

"The Cash Left In My Pocket,The BEST Benchmark"
No Overclock+stock hsf=GOOD!
March 9, 2002 4:36:59 AM

Quote:
... there is no limit that the gpu places on games which would not be there if the cpu did everything.

Actually there is. Video cards have a very specific implementation for everything. For example, if you want to use 16-bit color you are usually restricted to a 16-bit Z-buffer as well. This offers a tiny 65,536 different levels of depth for every pixel. If objects get too close to each other, the video card will have no way to tell which one should be in front and thus should be drawn. This leads to all kinds of artifacts. Thus, programmers are forced to keep models a certain distance from each other. Reasons such as this keep you from actually being able to see someone 'touch' an object. If we let you (the viewer) watch such an activity, you would see a mingling of the object and the hand drawn in an erratic fashion, most likely making it look like the item in the person's hand just swallowed the hand.

A solution to this is to have an extremely small world (perhaps split the world up into zones), so that 65,536 levels of depth are adequate. This is why you generally do not see one huge continuous world in any 3D game. The only game that does have a massive continuous world (Asheron's Call) uses a software engine.

Problems like this keep realism very limited in games. There are a whole host of these kinds of issues.


Quote:
Also, the models would all be there in the first place, you wouldnt need to resend a model if you changed it.

Any time you change a model to one with more vertices you must send the entire model over to the video card once again. Models cannot be modified once locked into video memory. They can only be deleted and recreated (which resends it.)


Quote:
Youre not looking very hard, have you seen the nature demo on 3dmark2001, that is NOT possible without a good dx8 videocard, and to do it in software would ensure less than 1 fps.

The demo uses no new hardware algorithms. It might produce nice eye-candy, but it still uses the same old technology with the same limitations.


Quote:
I guess thats why when programable gpu engines were released on the gf3 and 8500, all the games now are designed specifically for them, oh wait, they arent.

Oh gee, pixel shaders. We can now determine how a pixel gets shaded. How exciting. And it only requires a few months worth of man-hours to get it working. Joy. This is not what I would call that great of an innovation. In addition, this is a software solution. Programmable means software.


Quote:
Computer power as a whole is what has limited game design, and high end gpus like ati's and gf3's are now finally allowing game designers to make groundbreaking games.

Up until now I would have agreed with you. However, today CPUs are more than powerful enough to handle these tasks on their own. Asheron's Call does it.


Quote:
Moving everything to the cpu does not work, and the current designs of cpus would make any move to do such foolhardy

See Asheron's Call.


Quote:
redesigning a cpu to do graphics anywhere near as well as a gpu would turn the cpu into a gpu in itself!

A CPU is a general purpose processor. It can do graphics without having to be renamed.


Quote:
You can emulate programable pixel shaders, at 0.01 fps!!!

Programmable pixel shaders are just small software applications. You can perform these tasks just as easily on a standard CPU. The only benefit to having them on the video card is being able to continue using the 3D accelerator for everything else as well.


Quote:
If you want all the eye candy to be in software, you should get on intel to make that 10ghz p4, because there is FAR from enough cpu power to come even close to anything currently available on the market today.(done via gpu)

Not so. Asheron's Call does a fine job. As far as the 10GHz CPU, wait about 3 years or so. ;) 

-Raystonn


= The views stated herein are my personal views, and not necessarily the views of my employer. =
March 9, 2002 5:02:54 AM

Quote:
While past games relied on simple textures painted onto objects to provide their color and shading, AC2 boasts far more dynamic tools. The engine runs a scriptable shading language and supports pixel and vertex shaders, providing artists with an easy-to-use system to describe the surface of an object. These shaders work in conjunction with the appearance system, allowing your characters to get covered in blood or the dents in their armor to properly reflect the light and environment around them.



If asherons call does it so well without gpu support, then why are they abandoning it for the next asherons call engine!

Perhaps its say, limited?

<A HREF="http://zone.msn.com/inviso1/articles/articlesengine.asp" target="_new">http://zone.msn.com/inviso1/articles/articlesengine.asp...;/A>

"The Cash Left In My Pocket,The BEST Benchmark"
No Overclock+stock hsf=GOOD!
March 9, 2002 5:12:44 AM

They are not abandoning the software engine. They have in fact made their engine in a modular fashion so that those who wish to use hardware acceleration can do so. The fact remains that most people do not own a 2GHz processor yet. In order for those folks to play, they will need a 3D accelerator. The general goal is to allow as many people to play as possible.

Eventually 99% of the public will some day own computers with fast processors. When this happens, a 3D accelerator will generally not be required for this level of game. The requirement will be a fast processor and a video card that supports 8X AGP to allow for fast blitting of the scene to the framebuffer.

-Raystonn


= The views stated herein are my personal views, and not necessarily the views of my employer. =
March 9, 2002 5:21:17 AM

Quote:
Actually there is. Video cards have a very specific implementation for everything. For example, if you want to use 16-bit color you are usually restricted to a 16-bit Z-buffer as well. This offers a tiny 65,536 different levels of depth for every pixel. If objects get too close to each other, the video card will have no way to tell which one should be in front and thus should be drawn. This leads to all kinds of artifacts. Thus, programmers are forced to keep models a certain distance from each other. Reasons such as this keep you from actually being able to see someone 'touch' an object. If we let you (the viewer) watch such an activity, you would see a mingling of the object and the hand drawn in an erratic fashion, most likely making it look like the item in the person's hand just swallowed the hand.


Hence the 32 bit color depth and 24 bit zbuffer of the modern videocard.
And you have yet to tell us how the all purpose cpu is going to do all this magic and maintain an acceptable framerate for gameplay.


Quote:
A solution to this is to have an extremely small world (perhaps split the world up into zones), so that 65,536 levels of depth are adequate. This is why you generally do not see one huge continuous world in any 3D game. The only game that does have a massive continuous world (Asheron's Call) uses a software engine.

This is more due to bandwith limitations, everquest has large continuous worlds, and (havent played) its zones are for bandwith, not because theres only a certain number of degrees of seperation.

Furthermore, these degrees would eminate from the camera point, meaning the only limit to world size is the amount of texture and polys you can have in memory(and draw acceptably) This would be a limit on a cpu as well as a gpu.


Quote:
Any time you change a model to one with more vertices you must send the entire model over to the video card once again. Models cannot be modified once locked into video memory. They can only be deleted and recreated (which resends it.)

Perhaps you misunderstood me, the arms vertice is already loaded with the model, and the breaking off of said arm is already planned for.

Quote:
The demo uses no new hardware algorithms. It might produce nice eye-candy, but it still uses the same old technology with the same limitations.

The demo uses pixel; shaders, which are hardware advancements, the technology is new, and if what you have listed as limitations are what you mean again here, I dont see them as graphics card specific limitations.


Quote:
Oh gee, pixel shaders. We can now determine how a pixel gets shaded. How exciting. And it only requires a few months worth of man-hours to get it working. Joy. This is not what I would call that great of an innovation. In addition, this is a software solution. Programmable means software.

Asides from how this statement shows how little you know about what pixel shaders actually are, I will rebut it.

A: the programmable in this case is hardware programable, more like sse or sse2 than an actual software app. They have as I stated, pixel shader emulators, which run at 1/1000th the speed of the hardware pixes shader, perhaps you can take those apps and "optimise" them, if you can get them to run at even 50% speed I will concede the point, you are a software engineer after all.


Quote:
Up until now I would have agreed with you. However, today CPUs are more than powerful enough to handle these tasks on their own. Asheron's Call does it.

Asherons call isnt all that spectacular from the screen shots I have seen, also remember the game was started in 95, hardware t&l engines are very new(gf1), of course an old game like this is software, quake 1 is software too.





Quote:
Programmable pixel shaders are just small software applications. You can perform these tasks just as easily on a standard CPU. The only benefit to having them on the video card is being able to continue using the 3D accelerator for everything else as well.

Prove this incorrect and audacious statement ray.

Linkage.

You dont know how pixel shaders even work(as shown by the statement "oooh it can shade pixels".



Quote:
Not so. Asheron's Call does a fine job. As far as the 10GHz CPU, wait about 3 years or so. ;) 


I just saw some screen shots of asherons call, and if you think thats graphically impressive then you need to play more modern games.


"The Cash Left In My Pocket,The BEST Benchmark"
No Overclock+stock hsf=GOOD!
March 9, 2002 5:48:33 AM

Quote:
Hence the 32 bit color depth and 24 bit zbuffer of the modern videocard.

This was simply one example of the many restrictions present in the use of hardware APIs. Not everyone has a state of the art video card either.


Quote:
And you have yet to tell us how the all purpose cpu is going to do all this magic and maintain an acceptable framerate for gameplay.

For the most part in our high end processors, the CPU is generally idle most of the time during today's games waiting on the video card to perform tasks. The pegging of the CPU in such monitoring applications as Task Manager is due to the fact that Windows' Idle task is not being executed while the processor sits waiting. The requirement for Asheron's Call is a 333MHz processor. Plug in a 2GHz processor and it will be sitting there most of the time doing nothing. There exists plenty of processing power to take over the 3D processing.


Quote:
This is more due to bandwith limitations, everquest has large continuous worlds, and (havent played) its zones are for bandwith, not because theres only a certain number of degrees of seperation.

And Asheron's Call need not worry about bandwidth? There are plenty of ways to deal with bandwidth. It is not difficult to restrict updates to players and creatures within a certain distance of yourself. This is how Asheron's Call does it.


Quote:
Furthermore, these degrees would eminate from the camera point, meaning the only limit to world size is the amount of texture and polys you can have in memory(and draw acceptably) This would be a limit on a cpu as well as a gpu.

Games today cache textures and models. RPGs have far more textures and models than can fit in the memory on your video card. Video card memory does not limit the size of the world or zone at all.


Quote:
the arms vertice is already loaded with the model, and the breaking off of said arm is already planned for.

Singular is "vertex." Plural is "vertices." This is exactly my point. The only way to allow people to break any object in any fashion on today's video cards is to make every object out of hundreds of thousands of polygons. This is not workable. You should not have to plan for how something will break.

We need new algorithms for the morphing of a single object into two when the sheer stress of an object exceeds its tolerances and the physics engine determines it should break. When this happens, the objects should dynamically be transformed into at least two separate parts. This kind of creativity is not possible with today's video cards. It, and many other innovative things not yet present in today's games, is very possible using the CPU.


Quote:
Asides from how this statement shows how little you know about what pixel shaders actually are, I will rebut it.

A: the programmable in this case is hardware programable, more like sse or sse2 than an actual software app. They have as I stated, pixel shader emulators, which run at 1/1000th the speed of the hardware pixes shader...

On the contrary, I know exactly how pixel shaders work. I used to write games for a living. Software engineering is what I do best. Have you taken a look at the programmable pixel shaders? They require you to write in a form of assembly language specific to the video card. This is clearly software. The reason this is required in the video card is because only the video card has access to the stage at which pixel shading must be done. This is because you are using the video card to do the rendering. If you were using the CPU to do the rendering you would simply use the same code (in C or x86 assembly instead) during your own rendering phase.


Quote:
Asherons call isnt all that spectacular from the screen shots I have seen, also remember the game was started in 95...

And it only requires a 333MHz processor to run. Now imagine what you could do if you upped the requirements to a 2GHz processor. Dynamic lighting and other features would easily be a reality, with plenty of processing power left over.


Quote:
You dont know how pixel shaders even work

Matisaro, you argue with me over a great many things. You should not be arguing with me on this one. I know exactly how they work. Software engineering is my life. Do a simple search on any engine for this information. In fact, go to nVidia's website and look it up. They even have their own assembler called NVASM. Check <A HREF="http://developer.nvidia.com" target="_new">http://developer.nvidia.com&lt;/A>.

-Raystonn


= The views stated herein are my personal views, and not necessarily the views of my employer. =
March 9, 2002 6:36:33 AM

Quote:
For the most part in our high end processors, the CPU is generally idle most of the time during today's games waiting on the video card to perform tasks. The pegging of the CPU in such monitoring applications as Task Manager is due to the fact that Windows' Idle task is not being executed while the processor sits waiting. The requirement for Asheron's Call is a 333MHz processor. Plug in a 2GHz processor and it will be sitting there most of the time doing nothing. There exists plenty of processing power to take over the 3D processing.



If that were true, then most games would see little to no benifit of a faster processor, which is very untrue.

Again, software mode on modern games would also be quite fast, and yet it isnt, something about your premise is not adding up ray.


Run3dmark2001 in software mode, and then tell me modern cpus can do the job of a gpu.

"The Cash Left In My Pocket,The BEST Benchmark"
No Overclock+stock hsf=GOOD!
March 9, 2002 6:56:31 AM

Quote:
And Asheron's Call need not worry about bandwidth? There are plenty of ways to deal with bandwidth. It is not difficult to restrict updates to players and creatures within a certain distance of yourself. This is how Asheron's Call does it.


And other games have areas, its a different solution to the same problem, dosent mean one is better than the other, or that one is caused due to graphics cards limitations.


Quote:
Games today cache textures and models. RPGs have far more textures and models than can fit in the memory on your video card. Video card memory does not limit the size of the world or zone at all.



It does cause performance loss, when you constantly hit your agp buss for data, this is not a large problem in mmorpgs because the games generally are not very action orientated. Having enough graphics memory to hold all of the models has a HUGE performance benifit.

Furthermore, alot of textures can fit in graphics memory, 64 megs of texture data is QUITE ALOT. and most modern games load up practically all of their texture data to the graphics chip when loading a level. Remember a texture is just a small repeating bitmap(or some compressed image) it is not very large at all.

And polygon vertix data is rather small by comparison.

Quote:
Singular is "vertex." Plural is "vertices." This is exactly my point. The only way to allow people to break any object in any fashion on today's video cards is to make every object out of hundreds of thousands of polygons. This is not workable. You should not have to plan for how something will break.


LoL, have you ever designed a game, you cannot just say, bam heres a tree, and expect ANY engine to predict and account for any possible action you could do to it. ANything that happens in a game has been and must be predesigned to happen, you are confusing game design with graphical limitations, the videocard does not cause the game designer not to design the game world like you desire, the game designer himself is the cause.

3d models work a very specific way, graphics cards are designed to perform tasks in 3d at very high speeds, they have limits yes, but those limits dont affect game designers any more than having to render everything in software would.

I read somewhere(flamethrower may have info on this)

That a scene from final fantasy the movie took several hours per frame to render on a multi cpu cluster in software.

With a gf3 modified to a quatro, it can now be rendered in real time, the same scene, this alone proves that software is INCAPABLE of operating at high enough speeds to make complex scenes work. A highly specific pipelined gpu is neccicary to make complex games at playable framerates.

An all around cpu only method would not work given todays state of cpu/motherboards, and even the things in 2 years time dont give me the impression that it will be possible then either.

The gpu is constantly evolving and speeding up, and gaining new hardware features, the cpu is doing the same, and since the cpu alone is already at such a disadvantage, the cpu will never catch up and supercede the gpu for high end graphics.


Quote:
On the contrary, I know exactly how pixel shaders work. I used to write games for a living. Software engineering is what I do best. Have you taken a look at the programmable pixel shaders? They require you to write in a form of assembly language specific to the video card. This is clearly software. The reason this is required in the video card is because only the video card has access to the stage at which pixel shading must be done. This is because you are using the video card to do the rendering. If you were using the CPU to do the rendering you would simply use the same code (in C or x86 assembly instead) during your own rendering phase.


A: what games have you written/worked with(interested)
B: The pixel shaders allow the game designer to program effects INTO the hardware of the gpu, thus rendering their results with extreme speed, to emulate it in software is not feasable because of the performance loss, again I point you to the pixel shader software emulators, and how slow they run. Why do they run so slow if general cpus can do the exact same thing so easily as you claim.

Quote:
And it only requires a 333MHz processor to run. Now imagine what you could do if you upped the requirements to a 2GHz processor. Dynamic lighting and other features would easily be a reality, with plenty of processing power left over.


Quake 1 only requires
"a single speed CD-ROM drive (if installing from CD)
a Pentium Processor
MS DOS 5.0 or higher
8 megabytes of RAM, 16 megabytes to run in a DOS Box under Windows 95
a VGA video card
and 40 megabytes of free hard drive space for the shareware version or 80 megabytes for the full version "


Does not mean its a good engine, or that its scalable, as I stated before, the screen shots of the game are not that impressive, and if you think adding real time lighting is so easy and does not hurt performance dramatically, run 3dmark2001's real time lighting demos in hardware and software mode. See the difference!



Quote:
Matisaro, you argue with me over a great many things. You should not be arguing with me on this one. I know exactly how they work. Software engineering is my life. Do a simple search on any engine for this information. In fact, go to nVidia's website and look it up. They even have their own assembler called NVASM. Check


That I do ray, what I am debating here is your assertion that the gpu is not needed and that standard cpus can take over for their functions, this I do not believe.


I ask for proof of your claims, and explinations why, if modern cpus are so powerful, why software mode on all games, and on all benchmarks show huge performance losses, this is what I am asking you about.


You offer one game which is semi modern which does not use the gpu specific functions, and that game supposedly proves the gpu is not needed, when in fact so do all old games, the gpu allows effects not possible with software on even the FASTEST cpus, this I know.


So ray, you made the claim, please offer some proof of the ability of pure software graphics.




"The Cash Left In My Pocket,The BEST Benchmark"
No Overclock+stock hsf=GOOD!
March 9, 2002 6:51:00 PM

God I love whats being said here. I can't decide if you're just uninformed or totally brainwashed. Do you intel guys have to repeat, "We are Intel, We serve me lord" every morning or what?

Damn! There is no way in hell the fastest CPU, AMD or Intel or even VIA (included just for the sake of it), can out perform a GPU, nVidia or ATI, in Transforming and lighting polygons. True, the shaders are software, but software that runs on instructions for very specific purposes. The only thing the CPU has that is remotely close to those are the SIMD instructions such as SSE2 or 3D-Now!pro or whatever. Even using those on a 2GHz P4, or an AthlonXP 2100+ you will not reach the performance of a GF3Ti500 let alone the latest in the series. To reach the performance of the Hardwired T&L using a CPU isn't even the stuff of dreams, but dementia.

True, rendering discounted, most things are done on CPU. I wan't certain things in the GPU. Quaternions, Nurbs, Inverse kinematics (I know, they're kinda intrinsic to each other.) and the common core algorythms for physics, i.e. a lot of vector facilities to be added to the programmable parts of the GPU. And oh yeah! Decent tesselation. Most of these will be done in hardware in the DX9 cards (forget about the physics engine though).

Yes, with decent tesselation, we have a higher order surface that defines a single cuboid as the window. It also defines a sphere as the ball. The ball hits the window. The physics engine kicks in. The window is re-evaluated into several seperate polygonal (still defined in hos) objects. They all fly towards the calculated directions. We switch to slow motion. The camera pans around one of the glass pieces. On the glass we see a car crashing into the side of another. They both collide and vere off in a realistic fashion. With tesselation, and some physics functions onboard, a 300MHz GPU will do this better than even a 4GHz P4.

Why isn't a scenario like this used in games these days? Well, because even SSE2 is too crappy to carry this out in realtime. Unless you add all the extra features in the instruction sets of the Vertex and shaders to a CPU and somehow let them execute at will without the rest of the processor blocking them for doing generic processing, there is know way a CPU will be able to do the job of the "GPU" at an acceptable rate. Oh yeah, you can't do that without removing all those specific instructions to a seperate chip, em.. err... I know! like the GPU!

perhaps thats why you were playing your text adventure game.

My proposed solution is to take away all the extra stuff needed for the AGP card. Put a socket on the Motherboard. The user sticks his/her preferred "media co-processor" in that socket. Stick the DVI and monitor connections on the mobo. Add a cheap riser card for analogue VIVO. For all else, get a duron or a celeron for the main processor. You know, the the Media co-processor, like the DJ, does the work while the cpu, like the doorman, says to the data, "Get in the queue, or yep, you can go in, or where the hell dya think you're goin!"

<font color=red><i>I refugee from Guatanamo Bay,
dance around the border like I'm Cassius Clay
</i></font color=red>
March 9, 2002 8:02:35 PM

I am simply going to have to disagree with you here. With the proper software optimizations, today's advanced processors are capable of handling the functionality that today's video cards perform. If I were to create such an engine, I would likely take Kyro's route. It is the most efficient means of creating the scene. Using similar algorithms it is possible to create an engine that is faster in software than it is using nVidia's algorithms on their video cards.

The problem with most 'software modes' today is they simply use the Direct3D in full HEL mode. This is neither a very good algorithm, nor is the algorithm implementation very well optimized. When writing in software you cannot simply use the algorithm that worked on an nVidia card and expect it to perform well. It does not work that way. You need a new algorithm designed to take advantage of what the processor has to offer while minimizing pixel reads from memory.

Anyway, it appears I am arguing this in the wrong forum. This is my area of expertise and I cannot expect the general public to really understand the subtle technical issues at hand. I am also not in the mood to present a university-level course on the subject in a forum. I will drop the subject to avoid having to give one.

-Raystonn


= The views stated herein are my personal views, and not necessarily the views of my employer. =
March 9, 2002 8:18:09 PM

Raystonn, I'm no professional programmer, but I know two things as fact:
#1: You can never optimize something enough
#2: Programmers are lazy

The problem here is that programmers are too lazy to write algorithms to handle physics, AI, transform, clipping, lighting, triangle setup, etc. If you give a programmer this job, the first result will be a mess of highly inefficient code. The hassle of optimizing the code is huge. It's harder to optimize code than it is to write it in the first place.

As an ameteur, I've played around a bit with the Windows GDI and with DirectDraw (although I haven't ever tried direct3D). I can imagine one way to eliminate pixel overdraw: you could divide the scene into layers and render the foreground first and then calculate the unneed pixels for the layer behind and skip them and so on. Of course, as I don't have experience with Direct3D or OpenGL or 3D animation for that matter, I don't know if that's even possible.

One problem I would imagine is that you don't render scenes pixel by pixel but you use polygons.

It might be something I could try to read up on over the summer as I know very little about designing games.

AMD technology + Intel technology = Intel/AMD Pentathlon IV; the <b>ULTIMATE</b> PC processor
March 9, 2002 8:22:55 PM

I know very well that most programmers are lazy. This is why they prefer an API that will do it all for them. At the moment there are no publicly available APIs that translate to an optimized set of advanced software algorithms that can compete with video cards, which tend to use highly optimized sets of inefficient algorithms. But the lack of such an API/library will only last so long. There may or may not be such a library in development by someone somewhere. *grin*

-Raystonn


= The views stated herein are my personal views, and not necessarily the views of my employer. =
March 10, 2002 1:10:35 AM

I still don't think so. If you find some of my previous discussions with noko, you'll find I am looking at developing a 3D engine of my own. But, it takes a lot of time, time that I was willing to invest during my previous employment. If you look at some of my early posts, you'll also find I wasn't too happy with my old job (coincedently you'll also find most of my posts here were during working hours :wink: ), but with a near doubling of salary with just a simple change of job has kinda made me put more effort in work time and lazy during the rest.

Anyway, I have looked a lot into 3D engines and software rendering. Eberly has one of the most comprehensive books on the subject that has an engine that works, most of the time. It talks a lot about optimising as well, without the context of specific APIs. But no matter what expert you talk to, software rendering, even on absurdly fast processors will lose out to hardware solutions. If the bare processor was just that good, there would be no need for mmx, sse, sse2, 3D-now!, AltiVec etc. When you get into even more specialised application of "doing things with polygons", The Shaders, as they have been named, are currently the best programmable solution. If you're happy with a more rigid solution, then the Hardwired T&L is still the best and fastest way to go. Although bandwidth can become a bottleneck, in which case you're screwed no matter what you do.


<font color=red><i>I refugee from Guatanamo Bay,
dance around the border like I'm Cassius Clay
</i></font color=red>
March 10, 2002 2:43:29 AM

The current bottleneck of video cards is fillrate. Hardware T&L really does very little in the way of speeding up applications. You tend to get a boost of maybe 10% most of the time. My main 'beef' with today's video cards (besides the PowerVR line) is they all use the same inefficient algorithms. They will texture and blend pixels for every polygon before even doing any depth testing. They can end up redrawing the same pixel up to 5 times, each time having to access memory to do so. This is extremely inefficient. A properly designed algorithm, used with a 2GHz processor, could result in a better framerate than many video cards are capable of producing.

If someone were to take Kyro's tile-based engine and implement it in optimized software (using SSE, SSE2, etc.) where each tile fit within the processor's L1 cache, it would likely end up being faster than it is on the Kyro video cards. Rather than being fillrate limited, the tile-based algorithms are processing limited. Today's advanced CPUs are capable of performing the required math to trace a ray to a polygon faster than most of the video cards on the market.

-Raystonn


= The views stated herein are my personal views, and not necessarily the views of my employer. =
March 10, 2002 3:42:47 AM

Quote:
If someone were to take Kyro's tile-based engine and implement it in optimized software (using SSE, SSE2, etc.) where each tile fit within the processor's L1 cache, it would likely end up being faster than it is on the Kyro video cards

Yeah maybe in Bizarro world.

Lets deconstruct this.

Lets look at our goal. Real time 3d rendering on using a system processor.

Assume 640x480 at 60fps.

This gives us 18,432,000 pixels a second. Assuming a 2Ghz processor that leaves us with 108.5 ticks per pixel. So lets just assume that we have a 2.2Ghz processor and the polygon setup is done with the remaining 2Mhz. For each pixel we process we have to do everything in 108 ticks, background clears, lighting, texturing, bump mapping, zbuffering, etc. Considering a single cache miss can cost you 20+ ticks. I don’t think you have a chance.

Added this by edit

Quote:
Today's advanced CPUs are capable of performing the required math to trace a ray to a polygon faster than most of the video cards on the market.


I believe that the last ray-casting engine game was Shadow Warrior. (Um Sticky Bomb Like You) All 3d rendering nowadays is done by projected polygons and the only rays caste from the viewer are those used for specular lighting.



All errors are undocumented features waiting to be discovered.<P ID="edit"><FONT SIZE=-1><EM>Edited by Schmide on 03/09/02 11:03 PM.</EM></FONT></P>
March 10, 2002 4:37:45 AM

History dictates that new intensive innovations get handled by new hardware solutions and then those hardware solutions are eventually replaced with software solutions.

Sound, Network, 2D Video have all gone through this cycle and 3D is partially there... it is only a matter of time before the multi-Ghz CPUs handle everything 3D as well.

The only catch is that video needs to be near isochronous so there will be increasing reliance on dual processing like clawhammers being designed MP as standard and HT in the future consumer P4s.

<font color=blue> Smoke me a Chip'er ... I'll be back in the Morgan </font color=blue> :eek: 
March 10, 2002 5:11:03 AM

Let me give a little information on the Pentium 4 as an example. For integer SIMD operations, which are the 64-bit wide MMX or 128-bit wide SSE2 instructions, there are three execution units that can run in parallel. The SIMD integer ALU execution hardware can process 64 SIMD integer bits per clock cycle. This allows the unit to do a new 128-bit SSE2 packed integer add uop every two clock cycles. A separate shuffle/unpack execution unit can also process 64 SIMD integer bits per clock cycle allowing it to do a full 128-bit shuffle/unpack uop operation each two clock cycles. MMX/SSE2 SIMD integer multiply instructions use the FP multiply hardware mentioned above to also do a 128-bit packed integer multiply uop every two clock cycles. Add to that the fact that the low latency L1 cache can perform one load and one store per clock cycle, and you can see how it is very possible to process a pixel in far less than 100 clocks when working with tiles that fit in the L1 cache.

Let another 12 to 18 months go by and we will also have twice as many clocks to use. The days of a video card being a requirement for multimedia applications and games are numbered.

-Raystonn


= The views stated herein are my personal views, and not necessarily the views of my employer. =
March 10, 2002 5:14:49 AM

Quote:
All 3d rendering nowadays is done by projected polygons and the only rays caste from the viewer are those used for specular lighting.

This is the typical video card yes. Go look up tile-based rendering on the Power VR website. This technology is used in the Kyro chips. It brings back ray-casting and eliminates the fillrate problems. A similar algorithm is what I am discussing for use on a CPU.

-Raystonn


= The views stated herein are my personal views, and not necessarily the views of my employer. =
March 10, 2002 5:47:47 AM

Quote:
This is the typical video card yes. Go look up tile-based rendering on the Power VR website. This technology is used in the Kyro chips. It brings back ray-casting and eliminates the fillrate problems. A similar algorithm is what I am discussing for use on a CPU.

I don’t know if this is what you are referring to <A HREF="http://www.powervr.com/pdf/TBR3D.pdf" target="_new">TBR3D.pdf</A> but it mentions nothing about ray casting. It does mention display list processing. I am pretty familiar with Tile Based Rendering. I used to have a colleague that would constantly rant and rave about it. The fact is that it runs on a DirectX or OpenGL system. In these systems all polygons are projected via use of a projection matrix. The Kyro driver is only responsible for rasterizing these already transformed and lighted packets of data. This is nothing like ray-casting. They basically do what is often referred to as multi-viewport rendering.


All errors are undocumented features waiting to be discovered.
March 10, 2002 6:14:37 AM

Quote:
<snip a fair amount about the p4 which I agree with> … you can see how it is very possible to process a pixel in far less than 100 clocks when working with tiles that fit in the L1 cache

I do believe that you could possibly do simple rendering (color, depth and light) within the L1 cache, but modern day rendering systems do a hell of a lot more than that. You have light maps, bump maps, and textures. None of these are going to fit within a L1 cache. Hell they’re not going to fit in your L2 cache. Add to that tri-linear filtering and anti-aliasing and you have a hell of a task at hand. The Kyro still uses standard pixel processing units and suffers from the same bandwidth problems associated with texture access. They do have the advantage of not doing as much texturing because they factor out all the pixels that will be excluded from the final rendered image. GPU’s have more stages than I can rattle off and pipelining is the true key to why they work so well.


All errors are undocumented features waiting to be discovered.
March 10, 2002 6:25:42 AM

Read through <A HREF="http://www.pvrdev.com/doc/f/PowerVR Tile based rendering.htm" target="_new">this</A>. They project a ray at each pixel location for each triangle that falls within the tile. (More than one ray is projected per pixel when AA is turned on.) As far as Direct3D and OpenGL, those are only APIs. The driver and hardware can decide to actually implement the rendering of the objects in any way they wish. Power VR cards using the Kyro wait until the whole scene has been delivered to the card and then go to work on rendering. This is known as scene capturing and allows the engine full knowledge of the entire scene while it renders. Thus, it can do depth testing and sorting before anything is drawn. This ensures each pixel is only written a single time rather than the typical 3 to 5 times on nVidia hardware.

-Raystonn


= The views stated herein are my personal views, and not necessarily the views of my employer. =
March 10, 2002 6:33:42 AM

Quote:
The Kyro still uses standard pixel processing units and suffers from the same bandwidth problems associated with texture access.

This is much less of a problem since each pixel is lit, textured, bump-mapped, filtered, and anti-aliased only a single time. Immediate mode renderers such as nVidia's cards do the whole process immediately for every new polygon that is pushed to the card where the Z buffer shows closer pixels. Since the hardware has no idea that another polygon is about to show up with even closer Z values, it will happily send those pixels through the gauntlet several times. That is terribly inefficient and contributes greatly to the fillrate problem.

-Raystonn


= The views stated herein are my personal views, and not necessarily the views of my employer. =
March 10, 2002 6:52:52 AM

Did you read this from my previous post?

Quote:
They do have the advantage of not doing as much texturing because they factor out all the pixels that will be excluded from the final rendered image.

All errors are undocumented features waiting to be discovered.
March 10, 2002 7:02:20 AM

Yes, I did. However, you also said:

Quote:
Add to that tri-linear filtering and anti-aliasing and you have a hell of a task at hand


This is not quite true with scene capturing, tile based renderers. Filtering and anti-aliasing are traditionally very expensive to do on immediate mode renderers simply because of all the overdraw. You tend to do them multiple times per pixel, maxing out your fillrate and killing the framerate. These features are not very intensive on the Kyro. In fact, you nearly get anti-aliasing for free.

-Raystonn


= The views stated herein are my personal views, and not necessarily the views of my employer. =
March 10, 2002 7:16:46 AM

<from the above mentioned doc>
Quote:
Calculating the triangle equation and projecting a ray at each position in the triangle return accurate depth information for all pixels

I assume this is what you’re referring to. I was definitely wrong in relating this to ray casting. The ray casting I was referring to is a way of performing ray-tracing like rendering without the recursive nature of ray-tracing, further refinements in this type of method has led to voxels (volumetric pixels). Basically you cast rays from the plane of projection, pixel by pixel, acquiring your pixel data from the first object you hit. Sorry for this misunderstanding.


All errors are undocumented features waiting to be discovered.
March 10, 2002 3:22:45 PM

Quote:
Let another 12 to 18 months go by and we will also have twice as many clocks to use. The days of a video card being a requirement for multimedia applications and games are numbered

Quote:
< From the Kyro docs> The fill-rate requirement for this game is 1280x1024x4x60x3 = 943 Mpixels/sec. This figure is at least twice the real fill-rate of other hardware, which means the game is fill-rated limited. Quake 3 Arena is fill-rate limited in this situation.

943 Mpixels/sec this is 51 times the constraint mentioned in the 18 Mpixels/sec for 640x480 at 60fps argument. <Previous post> Under the 2ghz assumption, that’s 2.1 ticks a pixel, under a 10Ghz processor, that’s 10.6 ticks a pixel. The requirements are exponential from there on out. This is compared to yesterday’s technology. This generation GPU processors are nearing 1200 Mpixels/sec. By the time any future processors come out, the ticks per pixel factor will be down to a tick a pixel. This will require a temporal inversion cache where memory can exist in infinite states with infinitely different associations.


All errors are undocumented features waiting to be discovered.
March 10, 2002 3:40:12 PM

then its not a gpu any more... a gpu is a graphics processing unit... nothing more, then it becomes the cpu, central processing unit... gpu becomes cpu... therefore youre backtracking to having the cpu doing graphics...

if in doubt blame microsoft...
March 10, 2002 4:08:36 PM

Let's get one thing straight here. Both the GPU and the CPU are processors that compute information. Processing physics is related to graphics.

AMD technology + Intel technology = Intel/AMD Pentathlon IV; the <b>ULTIMATE</b> PC processor
March 10, 2002 4:46:54 PM

Um, you're not exactly right there. Sound is going hardware and it is going hardware pretty well. or shall we try to do some 3D sound positioning and then churn out some dolby digital encoded signals in software...

2D video... what? um... Reelmagic hardware, Dxr3... dvd decoding on video cards. People seem to like ATI for that, I don't recall them making CPU's though. DivX... Are you saying that sticking a codec for that on hardware will be no quicker than it is on the current fastest CPU?

<font color=red><i>I refugee from Guatanamo Bay,
dance around the border like I'm Cassius Clay
</i></font color=red>
March 10, 2002 4:57:11 PM

I don't disagree with you on the overdraw fact. But Tile based rendering isn't the best way of doing things as it kinda wants to be at the center of things dictating to everything else. That is why ImgTec have had itsy bitsy problems forwarding onto the next steps, and you damn well know by itsy bitsy I actualy mean bigtime!

The thing is every 3D engine from quake onwards (at least every carmack engine) has pretty good HSR on software. It doesn't rival the TBR approach but it does the job. Stick one of those algorithms in hardware in the right stage of the pipeline and boom it will work way faster. But that isn't the way to go, because this only kinda says 'things behind that wall aren't visible', but not 'things behind that monster aren't visible'.

Both ATI and nVidia have HSR algorithms on their cards. The ATI one doesn't rival TBR either, but it does an OK job. The nVidia one needs specific support, which developers have shown some reluctance towards since DirectX is moving quite fast now. DX9 may say a thing or two about HSR on cards though. We'll just have to wait and see.


<font color=red><i>I refugee from Guatanamo Bay,
dance around the border like I'm Cassius Clay
</i></font color=red>
March 10, 2002 5:02:03 PM

Quote:
This will require a temporal inversion cache where memory can exist in infinite states with infinitely different associations.

Um... beam me up scotty???... :wink:

<font color=red><i>I refugee from Guatanamo Bay,
dance around the border like I'm Cassius Clay
</i></font color=red>
      • 1 / 2
      • 2
      • Newest
!