A message from our CEO about the future of Stack Overflow and Stack Exchange. Read now.

Hot answers tagged

32

It's not the app's responsibility to ensure the GPU doesn't overheat, and it's not the app's fault if it does overheat. If the GPU doesn't have proper cooling, then yes, running a 3D app can heat it up to dangerous levels. I don't know why your app does it and Crysis doesn't, but it means the card has inadequate cooling, and/or it has been messed with (...


31

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 ...


29

GPU compressed texture formats like DXT / BC / ETC are specifically designed to be read directly from their compressed form. They don't need to be unpacked into a raw RGBA buffer. The way this works is each block of texels (often 4x4) takes up some fixed number of bits - so we know exactly how far along in the buffer to look for a particular texel - and ...


24

It has happened in the wild. Starcraft II in 2010 had a problem where it had an uncapped framerate on menu screens placing an odd load on graphics cards, destroying cards from some vendor with insufficient thermal protection. Design and manufacturing flaws in the GPU itself can also lead to the card dismantling itself under load. G84/G86 mobile GPUs had ...


20

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 ...


20

That's the gist of it. In principle, the platform could, conceivably, do whatever it wants. One could imagine an advanced operating system doing just-in-time translation of compiled code from, say, x86 to GPU code. Similarly, OpenGL drivers could run whatever it wants on the host CPU. But really, what you just described, is what happens.


19

There are some really good answers here, so just to supplement them. A major driving force behind software rendering is capability. This was touched on in one of the answers, but I'm going to make an opposing point: software rendering can actually be more capable than hardware rendering, not less. With hardware you're generally limited to the capabilities ...


14

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 ...


14

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 ...


13

They're called profilers. Visual Studio has both CPU and GPU profilers built in to recent versions. A profiler will give you an idea of how much time your app is taking and where that time is being spent. This won't entirely avert the problems of over-specced hardware, though; the app might peg a lesser CPU but only use 60% of your developer machine. They ...


12

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 to ...


11

Selecting the adapter with the highest available dedicated memory might work in a lot of cases, but in some cases a GPU with less processing power might have more dedicated memory, and your game will still run on the "wrong" adapter. This brings me to a counter-question, what is the right adapter? The one with the most computational power? The one with the ...


11

Modern graphics APIs are very careful about specifying how rasterization of triangles that share edges will be done in order to avoid overlapping fragments and missing fragments. Fabien Giesen mentions one of these rules in his article series on the graphics pipeline, cited here: you need to have tie-breaking rules to ensure that for any pair of ...


10

Hardware or GPU rendering is, as you guessed using the graphical processing unit (aka Video Card) to render an image. The opposite is software rendering where the CPU is used. Software rendering is usually used as a fallback when there is no (suitable) GPU available. However since the GPU is orders of magnitude faster software renders are almost never ...


10

Locality of reference does matter, but you don't have to worry that much...because you don't have absolute control. When using OpenGL/DirectX you usually have limited control over memory layout, the driver will do the rest. For example you can try multiple vertex buffers layouts, such as using interleaved or non-interleaved vertex data and depending on your ...


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 ...


9

Your question is much more complex than what you wrote. I would say the general question is "can software break hardware?", and the answer to that is a definite yes. Mind you, not all hardware can be theoretically broken via software commands, but eventually, what software does is send electrical signals to very delicate hardware components. Usually, the ...


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

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 ...


8

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

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 ...


7

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.


7

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 ...


7

NVIDIA have a document here outlining some strategies that may be helpful for you: http://developer.download.nvidia.com/devzone/devcenter/gamegraphics/files/OptimusRenderingPolicies.pdf - unfortunately, the one I would otherwise suggest - the NvOptimusEnablement export - is only documented for C++; it may be possible to also do this with C# but someone who ...


7

As you clearly already know what GPU rendering is... let me answer what you seem to be asking. Traditionally, hardware rendering has carried a stigma of being very complex. This has in large part been due to the design of the application programming interfaces (APIs) which have not been well-geared to concealing complexity; that is, the learning curve has ...


7

Generally, Yes. Java is used to write programs that run on the cpu. Shader languages (cg,hlsl, et al) are used to write programs that run on the gpu. An exception to the rule would be using third party apis which can bridge the gap.


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