Tag Info

Hot answers tagged

42

"I've read that F1 cars are faster than those we drive on the streets... why people don't use F1 cars then?" Well... The answer to this question is simple: F1 cars can't break or turn as fast as most cars do (the slowest car could beat an F1 in that case). The case of GPUs is very similar, they are good at following a straight line of processing, but they ...


30

GPUs are very good a parallel tasks. Which is great... if you're running a parallel tasks. Games are about the least parallelizable kind of application. Think about the main game loop. The AI (let's assume the player is handled as a special-case of the AI) needs to respond to collisions detected by the physics. Therefore, it must run afterwards. Or at the ...


22

As someone with a few years of driver development, I see this as two separate issues. A graphics driver is a very complicated beast. To implement everything in a optimal way would be a simply impossible task; it's a big enough hurdle just to make a driver that actually follows the specs - and the specs keep getting increasingly more complex. So, you develop ...


20

Why is not so easy to answer -- it's important to note that GPUs are specialized processors which are not really intended for generalized use like a regular CPU. Because of this specialization, it's not surprising that a GPU can outperform a CPU for the things it was specifically designed (and optimized) for, but that doesn't necessarily mean it can replace ...


19

I like to think of performance in terms of "limits". It's a handy way to conceptualise a fairly complicated, interconnected system. When you have a performance problem, you ask the question: "What limits am I hitting?" (Or: "Am I CPU/GPU bound?") You can break it down into multiple levels. At the highest level you have the CPU and the GPU. You might be CPU ...


18

Assume running a vertex shader is 100 flops, then that means you can process 1000e9 / 100 = 10e9 vertices per second. No, it most assuredly does not. Basically, you should consider any calculation of the execution speed of any code based solely on "FLOPS" count to be suspect. Indeed, it's generally best if you completely ignore FLOPS entirely. You did ...


17

CPUs are more flexible, it's generally easier to program them, they can run single threads a lot faster. While modern GPUs can be programmed to solve pretty much any task they only gain a speed advantage when they can utilize their parallel architecture. This is usually the case with highly repetitive "simple" tasks. A lot of the code we write is branching ...


12

JPG and PNG files will almost always be smaller on-disk than in memory; they need to be decompressed on-the-fly to acquire raw RGB data, thus requiring more processing power for the loading and more RAM afterwards. So many modern engines opt to store the same format on disk as they do in memory, leading to files that are the same size as the texture's memory ...


12

Pseudo random numbers in a pixel shader aren't easy to obtain. A pseudo random number generator on the CPU will have some state which it both reads from and writes to, on every call to the function. You can't do that in a pixel shader. Here's some options: Use a compute shader instead of a pixel shader - they support read-write access to a buffer, so you ...


12

In an ideal world they wouldn't. This is not an ideal world however, so game-specific performance improvements may come from one or more of the following (not intended to be an exhaustive list): The game is doing a combination of operations A, B and C with states X, Y and Z set. The driver can make assumptions based on this and push things to a more ...


9

It really is debatable on a few things, for the most part browsers now support hardware, so to some degree your hardware will allow more performance, no chance it'll really perform well on devices/phones as a canvas game, they would be better off as an app than something in a webpage. It is possible to run a good sized canvas game in isometric how ever. But ...


8

Obviously: It depends on the format. Let's take a 256 by 256 pixel square texture. If it's uncompressed 32-bit with an alpha channel (Color in XNA) then it takes 256KB (256*256*4 bytes). 16-bit formats (eg: Bgr565) will obviously be half the size - 128KB. Then you get onto the compressed formats. In XNA you have DXT1, DXT3 and DXT5 (also known as S3 ...


8

In DirectX 10 the cards all have the same capabilities: this means that they guarantee that all features are available and implemented. However, they are free to do driver-level optimizations. Take, for example, the major difference in the way that they do anisotropic filtering (this article contains sources). Not only is the output of each vendor different ...


8

It is possible that the total size of a sprite sheet will affect performance of your game in some reasonably small fashion. Extremely small sprite sheets generally mean that you have many, which in turn implies many state changes, and frequent state changes are not good for performance. Extremely large sprite sheets consume more GPU RAM, and if they need to ...


7

Since the heavy calculations made in a computer are either graphical or not, we separate them into 2 dedicated chips. It's not really because they're graphical or not, it's that there are 2 distinct types of computation, which I shall term 'branching', being heavy on choices, loops, and conditionals, and 'linear' which has few or no conditionals and is ...


7

AMD Fusion is the next logical step in onboard graphics; the first step was of course "why don't we take the video card, and stamp it onto the motherboard instead!" - of course, greatly reducing the power in the process. Now they're thinking "why don't we take that onboard graphics chip, and built it into the processor". It will be low-powered, just like ...


7

Path finding is essentially a graph problem, in which a lot of parallelism takes place. There are a lot of papers out there on how to implement and optimize graph based algorithms for CUDA. I found some papers that might interest you (although these are quite academic): http://cvit.iiit.ac.in/papers/Pawan07accelerating.pdf ...


7

I see no reason not to re-promote one of my old answers: Are there any benefits for using the CPU instead of the GPU? On top of that it's worth considering that we don't party like it's 1999 any more, 20 000 polygons on screen definitely looks better than 10 000. But if it's 500 000 polygons vs. 200 000, or fancy dynamic shadows vs. blob shadows, or 2000 ...


7

No, you don't. All current-generation commodity GPUs use (and have used for some time) triangle-based rasterization methods exclusively. Even though older version of OpenGL support the GL_QUADS rendering mode, these were converted to triangles by commodity GPUs. It's likely that GL_QUADS only resulted in actual quadrilaterial-based rasterization on esoteric ...


7

Game developers push the bounds of GPUs. We can make an analogy to a game and a game engine. The more advanced the requirements of the game, the more advanced the game engine needs to be to support it. This is the same with graphics cards. Computer games and GPU manufactures are good bed fellows. It's in their best interest to work together to improve the ...


7

Does its data get sent to GPU memory only once and sit there forever? Usually yes, but the driver is free to do what is "optimal", the data might be stored at VRAM or RAM or could just be cached here is an atricle that explains what actually happens with the VBO flow. For example if it was flagged as a dynamic openGL buffer (e.g. VBO), it's more likely ...


6

First, the interconnect between the GPU and the CPU is usually very narrow. For example, when developing for the iPhone, memory bandwidtch is a huge problem. People pack vertex data using 16-bit integers and use matrices to rescale them. For example, I used 0...1023 to represent [0.0, 1.0] range in OpenGL texture coordinate by applying a scaling factor of ...


6

GPU are very difficult to program. You should search howto to sort a list on a GPU. Many thesis have search to do it. Use a CPU with one thread is easy, use multi-threads is more difficult, use many computers with parallel library as PVM or MPI is hard and use a gpu is the hardest.


6

This is a tricky question because you don't have complete control over whether a vertex buffer is stored in VRAM or main RAM. The driver makes that decision for you based on the usage and CPU access flags specified when you create the vertex buffer. Generally speaking, buffers with default and immutable usage will be stored in VRAM; those with staging ...


6

If you're fetching all the vertex attributes in the shader, then in general attributes in multiple streams may be slower than all attributes in one stream, due to the loss of cache locality. However, using multiple streams can still be a good idea in some cases, such as: Some passes only need to read a few of the attributes. For example, drawing the ...


6

This is going to be one of those "it depends" answers, so let's get that over with first: "it depends". The objective here is not to reduce workload in one stage but to balance workload across all stages. That's what keeps your pipeline pumping nicely without each stage needing to go idle while waiting on the previous stage to complete. So - with specific ...


6

GLES2 (OpenGL) pretty much forces you to use vertex buffer objects and shaders to do any rendering. That's a good thing because it means you are using the GPU correctly and keeping battery life high by keeping information off the power hungry transfer busses. You don't have to worry about using the entire GPU because those shader units automatically divide ...


6

If you're using a rendering API, then you only need to worry about what that API tells you to worry about. OpenGL doesn't say anything about quad-based or triangle-based rendering systems. So you don't need to concern yourself with it. In any case, all consumer-grade GPUs use triangles, not quads.


6

Basically, it's not easy to get the vertex data back from the video card once it's there. Keeping the vertex data available to the CPU allows for a number of things, here are a few: As melak47 suggests, it allows the developer to free up video memory by freeing a VBO, while being able to quickly replace the data without needing to read from disk again. It ...


6

No. SDL's drawing primitives do not match modern hardware well. I've been told that projects like SDL_gfx seek to offer an accelerated but simple 2D drawing API, though the docs indicate otherwise (it looks likw SDL extensiona). I believe the prerelease SDL 2.0 code has hardware accelerated 2D. Building your own over OpenGL or Direct3D is another option, ...



Only top voted, non community-wiki answers of a minimum length are eligible