Hot answers tagged

32

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


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


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

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


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.


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

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

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

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

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

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

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.


7

Using a tessellation shader, you can efficiently build useful representations of Bezier curves and surfaces all on the hardware. You can do this in conjunction with fully dynamic tessellation levels to implement automatic level-of-detail. It's a very simple concept. I'll illustrate using a Bezier curve tessellation although the principles extend trivially ...


7

Answers to your questions really depends on the platform. Generally BC formats are kept in compressed form in memory and decompression is done in flight by GPU texture units, but there are exceptions. Namely Xbox 360 is known to decompress complete 4x4 pixel BC blocks to cache before TU fetches the data thus inflating cache usage. I don't know of any ...


6

Your approach and implementation are valid (disregarding that position += force line). As long as there is only one instance of gravity. There is nothing in the code you have provided that leads to an over-O(n²) runtime. Therefore it is reasonable to expect a drop in framerate by half at 100 planets. That is 100 planets at 150fps. 200 planets at 30fps. etc. ...


6

In general, you can't. The dual-GPU driver hides the two GPUs behind a single interface, so solutions like Nathan Reed's typically don't work in most common high-speed/low-power dual-GPU setups. The GPU selection must be handled by the driver in some way. With NVIDIA Optimus, you usually update the Optimus profiles to add the application to the list of ...


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