Sign in with
Sign up | Sign in
Your question

What makes a good gaming CPU?

Last response: in CPUs
Share
a c 131 à CPUs
December 1, 2010 8:33:23 PM

My question revolves mainly around instruction sets and programming of games.

I am wondering if anyone could explain, or has any links to, what specifically would make a good gaming CPU with regards to instruction sets, FPU performance and integer performance. Take into account how programmers will make use of instruction sets etc of the CPU when programming for games. Take into account what kind of instructions a game would most request from the CPU from a game.

My definition of game is a video game involving 3D graphics that heavily makes use of a graphics card's processing power. Such as the COD series or Dragon Age.

I hope someone can point me in the right direction. Thanks in advance guys.

Let me make it clear I am not interested in buying a CPU. I want information that someone who has read my entire post can provide or lead me in the right direction to the information.

More about : makes good gaming cpu

December 2, 2010 2:24:58 PM

Quote:
I might have some info for you..


Care to share? I'm interested also!
December 2, 2010 4:37:16 PM

haha :D 
Related resources
a b à CPUs
December 2, 2010 4:46:49 PM

We are waiting Mal, LOL
a c 81 à CPUs
December 2, 2010 4:56:56 PM

I don't think there is any such thing as a gaming CPU.. As for the term game, it need not be just 3D.. Even 2D flash games fall in that genre.. The concept is pretty much similar across the platform.. There is basically artwork, model and world designing etc. which get all linked via programming.. The processors role is to basically decode the instructions and send them over to the video/audio card sub-system for further processing.. The faster a processor can do this, the more smoother is the game experience..
a c 131 à CPUs
December 2, 2010 5:19:36 PM

Emperus said:
I don't think there is any such thing as a gaming CPU.. As for the term game, it need not be just 3D.. Even 2D flash games fall in that genre.. The concept is pretty much similar across the platform.. There is basically artwork, model and world designing etc. which get all linked via programming.. The processors role is to basically decode the instructions and send them over to the video/audio card sub-system for further processing.. The faster a processor can do this, the more smoother is the game experience..

You misunderstand my question. let's try a response to yours:

". The processors role is to basically decode the instructions and send them over to the video/audio card sub-system for further processing.. The faster a processor can do this, the more smoother is the game experience"

yep. but what I want to know is the type of instructions used specific to the programming of 3d games that are given to the CPU. Which ones are most prevalent etc. Then it could possibly become easy to analyze a CPU using benchmarks designed to test performance using various instruction sets, like SSE performance etc..
Anonymous
a b à CPUs
December 2, 2010 6:25:15 PM

enzo matrix said:
My question revolves mainly around instruction sets and programming of games.

I am wondering if anyone could explain, or has any links to, what specifically would make a good gaming CPU with regards to instruction sets, FPU performance and integer performance. Take into account how programmers will make use of instruction sets etc of the CPU when programming for games. Take into account what kind of instructions a game would most request from the CPU from a game.

My definition of game is a video game involving 3D graphics that heavily makes use of a graphics card's processing power. Such as the COD series or Dragon Age.

I hope someone can point me in the right direction. Thanks in advance guys.


Well, I've seen Black Ops run rather smoothly on an Athlon II. So let's say you was to fit a Phenom II, which are reasonably priced for what they do, you'd be covered as long as you have a good video card.
a c 131 à CPUs
December 2, 2010 8:28:16 PM

Quote:
Well, I've seen Black Ops run rather smoothly on an Athlon II. So let's say you was to fit a Phenom II, which are reasonably priced for what they do, you'd be covered as long as you have a good video card.

Perhaps you should read my entire post.
December 3, 2010 1:13:49 PM

What I've determined is that I like a CPU for gaming that runs quiet and smooth, while keeping cool. Intel has features like TurboBoost and such that help with that, because you don't need an insane CPU to game so don't instantly buy a crazy powerful CPU because of it's raw power. Look into some other features or known things about that specific CPU.
a c 131 à CPUs
December 6, 2010 4:26:38 PM

Zterling said:
What I've determined is that I like a CPU for gaming that runs quiet and smooth, while keeping cool. Intel has features like TurboBoost and such that help with that, because you don't need an insane CPU to game so don't instantly buy a crazy powerful CPU because of it's raw power. Look into some other features or known things about that specific CPU.

What does that have to do with instruction sets and what most games use during gameplay?
a c 102 à CPUs
December 7, 2010 1:36:28 AM

enzo matrix said:
My question revolves mainly around instruction sets and programming of games.

I am wondering if anyone could explain, or has any links to, what specifically would make a good gaming CPU with regards to instruction sets, FPU performance and integer performance. Take into account how programmers will make use of instruction sets etc of the CPU when programming for games. Take into account what kind of instructions a game would most request from the CPU from a game.

My definition of game is a video game involving 3D graphics that heavily makes use of a graphics card's processing power. Such as the COD series or Dragon Age.

I hope someone can point me in the right direction. Thanks in advance guys.

Let me make it clear I am not interested in buying a CPU. I want information that someone who has read my entire post can provide or lead me in the right direction to the information.


What you want to do is execute a game through a code profiling program such as Intel VTune or AMD CodeAnalyst. That will tell you the mix of instructions the game uses and the time it takes to execute each one. After you run enough games, you should be able to get an idea of what CPU functions games hit the hardest, and by extension, what functions you would look for to be especially fast to make an excellent gaming CPU. I have never done this and a brief look at the tools makes me think this may be quite an undertaking to do well, but it would certainly be interesting to see.
a c 131 à CPUs
December 7, 2010 10:05:37 AM

MU_Engineer said:
What you want to do is execute a game through a code profiling program such as Intel VTune or AMD CodeAnalyst. That will tell you the mix of instructions the game uses and the time it takes to execute each one. After you run enough games, you should be able to get an idea of what CPU functions games hit the hardest, and by extension, what functions you would look for to be especially fast to make an excellent gaming CPU. I have never done this and a brief look at the tools makes me think this may be quite an undertaking to do well, but it would certainly be interesting to see.

Thanks! I'll report back when I get the time over the holiday season.
a c 131 à CPUs
December 16, 2010 8:44:49 PM

CodeAnalyst doesn't have an option to monitor the instruction sets used by a program.


I might have some info for you..
Any luck, Malmental?
a c 131 à CPUs
January 24, 2011 2:33:27 AM

Quote:
got to piece it together first, I had a project about gaming architecture about two years back, got to find it..

Did you manage to find it?
January 24, 2011 5:29:02 AM

depends on the game in question. last year, we saw 2 game titles that are horribly cpu bound (f1 2010, blackops).

the question should be reiterated into "what is a good gaming CPU for X?" where X is the videogame title. in essence, it's the developer's choice what feature set he will use.
a c 131 à CPUs
January 24, 2011 6:22:53 PM

wh3resmycar said:
depends on the game in question. last year, we saw 2 game titles that are horribly cpu bound (f1 2010, blackops).

the question should be reiterated into "what is a good gaming CPU for X?" where X is the videogame title. in essence, it's the developer's choice what feature set he will use.

^Sigh. Another person who didn't read my post.

Quote:
Quote:
Love is easy. Middleware is hard.

We used middleware on Fracture for physics, tree rendering, audio, animation, facial animation, network transport, and various other systems. Now that the game is finished, we’re taking stock of the lessons that we learned and deciding what packages we want to keep and what we want to replace as we move forward.

Middleware offers two main benefits, each of which is balanced by an associated cost:

1. Middleware provides you with more code than you could write yourself for a fraction of what it would cost you to try. No matter how clever you are, that’s how the economics of the situation work. The costs of developing a piece of software are largely fixed. But once written, any piece of software can be sold over and over again. Because they can spread their costs over a large number of customers, middleware vendors can afford to keep larger, more experienced teams working on a given piece of functionality than independent game developers can. During Fracture, we watched a couple of pieces of immature middleware spring up after we’d written similar tools ourselves. We watched those pieces of middleware grow and surpass our tools, because we couldn’t afford to devote the resources to our tools that the middleware vendors devoted to theirs.

The corresponding cost is that none of the functionality you get is exactly what you would have written yourself, and much of it will be entirely useless to you. Middleware is written to support the most common cases. If you have specific needs that differ from the norm, you may be better off implementing a solution yourself.

2. Middleware offers structure. Middleware draws a line between the things that you have to worry about and the things you don’t. As long as it’s reasonably well documented and stable, you don’t need to waste mental bandwidth worrying about the things that go on underneath your middleware’s public API. As games grow ever-larger and more complex it’s become incredibly valuable to be able to draw a line and say, The stuff on the other side of that line isn’t my responsibility, and I don’t have to worry about it.

The associated cost is that you can’t change what’s on the other side of that line. If you’re going to use middleware, you have to be willing to accept a certain amount of inflexibility in dealing with the problems that the middleware solves. You have to be willing to shape your own technology to suit the third-party libraries that you’re buying. Trying to do otherwise is a recipe for misery.

Given those benefits and costs, it makes sense to use middleware wherever you can–as long as you don’t try to license technology in the areas where you want your game to be unique. Every game has certain unique selling propositions: things that make it distinct from every other game on the market. Likewise, every game has certain characteristics that it shares with many others. When it comes to the latter, you should buy off-the-shelf technology, accept that technology’s inflexibility, and modify your game design to suit it. When it comes to the former, you should write the code in-house. As Joel Spolsky says, don’t outsource your core competency.

So now that you’ve figured out which game functions you should be implementing through middleware, how do you decide which of the scads of available middleware packages is best for you? There are a number of issues to keep in mind.

Good middleware lets you hook your own memory allocator. If your approach to memory is to partition the entire free space up front and minimize runtime allocations, then you’ll want the ability to reserve a block for your middleware and allocate out of that. Even if you allow dynamic allocations at any time, you’ll want to track how much memory is used by each system and instrument allocations to detect memory leaks. Any piece of middleware that goes behind your back and allocates memory directly just isn’t worth buying.

Good middleware lets you hook your own I/O functions. Most games store resources in package files like the old Doom WAD files. Middleware that doesn’t let you hook file I/O doesn’t let you put its resources in packfiles. Many modern games stream resources off DVD as the player progresses through a level. If you can’t control middleware I/O operations, then you can’t sort file accesses to minimize DVD seeks. You’ll waste read bandwidth and your game will be subject to unpredictable hitches. Again, any piece of middleware that does file I/O directly just isn’t worth buying.

Good middleware has extensible functionality. No middleware package will do everything you want out of the box. But you shouldn’t have to modify any piece of middleware to make it do what you need. Good middleware offers abstract interfaces that you can implement and callbacks that you can hook where you need to do something unique to your game. An animation package may let you implement custom animation controllers. A physics package may let you write your own collision primitives. Your objects should be first-class citizens of your middleware’s world.

Good middleware avoids symbol conflicts. Beware of middleware that uses the Standard Template Library carelessly. It’ll work fine until you try to switch to STLPort or upgrade to a new development environment, and then you’ll suddenly find that your engine has multiple conflicting definitions of std::string and other common classes. To avoid symbol clashes, every class in a middleware library should start with a custom prefix or be scoped inside a library namespace. And if a piece of middleware is going to use the STL, it should do so carefully, making sure that every STL class instantiated uses a custom allocator. That allows you to hook your own memory allocator and avoids symbol conflicts.

Good middleware is explicit about its thread safety. We live in an ever-more-multithreaded world, but one where most game engines are still bound by main thread operations most of the time. For best performance, you want to offload any operations you can onto other threads. To do that with a piece of middleware, you need to know which operations can be performed concurrently and which have to happen sequentially. Ideally a piece of middleware will let you create resources asynchronously so you can construct objects in a loader thread before handing them off to the game.

Good middleware fits into your data pipeline. Most companies export data in an inefficient platform-independent format, then cook it into optimized platform-specific formats and build package files out of those as part of a resource build. Any piece of middleware should allow content creators to export their assets in a platform-independent format. Ideally, that format should still be directly loadable. The build process should be able to generate platform-specific versions of those assets using command-line tools.

Good middleware is stable. One of the main benefits of middleware is that it frees your mind to focus on more critical things. In this respect, middleware is like your compiler: It frees you from having to think about low-level implementation details–but only as long as you trust the compiler! A buggy piece of middleware is a double curse, because instead of freeing your attention from a piece of functionality, it forces you to focus your attention there, on code that was written by a stranger and that no one in your company understands. Worse still, if you’re forced to make bug fixes yourself, then you need to carry them forward with each new code drop you get of your middleware libraries. You shouldn’t need to concern yourself with the implementation details of your middleware. Middleware is only a benefit to the extent that its API remains inviolate.

Good middleware gives you source. Despite the previous point, having access to the source for any middleware package is a must. Sometimes you’ll suspect that there’s a bug in the middleware. Sometimes you need to see how a particular input led to a particular result before you can understand why the input was wrong. Sometimes you’ll have to fix a bug no matter how good the middleware is. And frequently you’ll need to recompile to handle a new platform SDK release or to link with some esoteric build configuration.

There are other questions to ask about any piece of middleware: How much memory does it use? How much CPU time does it require? What’s the upgrade path for your current code and data? How does it interact with your other middleware? How good is the vendor’s support? How much does it cost?

But those questions have vaguer answers. Acceptable performance or cost will vary depending on the nature of your product. A cell phone game probably can’t afford to license the Unreal Engine–and probably couldn’t fit it in available memory if it did! Data upgrade paths are less of a concern if you’re writing a new engine from scratch than if you’re making the umpteenth version of an annual football game.

The rules that don’t vary are: You should buy middleware wherever you can do so without outsourcing your core competency. And to be worth buying, any piece of middleware should behave itself with respect to resource management and concurrency.


http://gamearchitect.net/


Getting closer. Do you have a point to draw from the article for those of us who are less savvy?
!