CODEWITHSUNDEEP
graphicsgpu
kexu
kexu

Reputation: 306

How does GPU programming differ from usage of the graphics card in games?

One way of doing GPU programming is OpenCL, which will work with parallelized, number-crunching operations.

Now think of your favorite 3D PC game. When the screen renders, what's going on? Did the developers hand-craft an OpenCL kernel (or something like it), or are they using pre-programmed functions in the graphics card?

Sorry to make this sound like a homework problem, I couldn't think of a better way to ask it.

Upvotes: 1

Views: 426

Answers (2)

user
user

Reputation: 5390

H'okay, so, I'ma answer this in terms of history. Hopefully that gives a nice overview of the situation and lets you decide how to proceed.

Graphics Pipeline

3D graphics have an almost set-in-stone flow of calculations. You start with your transformation matrices, you multiply out your vertex positions (maybe generate some more on the fly), figure out what your pixels ought to be colored, then spit out the result. This is the (oversimplified) gist of 3D graphics. To change anything in it, you just twiddle one aspect of the pipeline a bit with a 'shader', i.e. little programmable elements with defined inputs and outputs so that they could be slotted into the pipeline.

Early GPGPU

Back when GPGPU was still in its infancy, the only way people had access to the massively parallel prowess of the GPU was through graphics shaders. For example, there were fragment shaders, which basically calculated what colors should be on each pixel of the screen (I'm kind of oversimplifying here, but that's what they did).

So, for example, you might use a vertex shader to chuck data about the screen before reducing a bunch of values in the fragment shader by taking advantage of color blending (effectively making the tricky transformation of mathematical problem space to... well, color space).

The gist of this is that old GPGPU stuff worked within the confines of 3D graphics, using the same 'pre-programmed functions in the graphics card' that the rest of the 3D graphics pipeline used.

It was painful to read, write, and think about (or at least, I found it so painful that I was dissuaded).

CUDA and OpenCL and [all of the other less popular GPGPU solutions]

Then some folks came along and said, "Wow, this is kind of dumb - we're stuck in the graphics pipeline when we want to be doing more general calculations!"

Thus GPGPU escaped from the confines of the graphics pipeline, and now we have OpenCL and CUDA and Brook and HSA and... Well, you get the picture.

tl;dr

The difference between GPGPU kernels and 3D graphics kernels are that the latter are stuck in a pipeline with (convenient) constraints attached to them, while the former have far more relaxed requirements, the pipeline is defined by the user, and the results don't have to be attached to a display (although they can be if you're masochistic like that).

Upvotes: 1

benshope
benshope

Reputation: 3024

When you run a game there may be two distinct systems operating on your GPU:

  • OpenGL renders images to your screen (graphics)
  • OpenCL does general-purpose computing tasks (compute)

OpenGL is programed with shaders. OpenCL is programmed with kernels.

If you would like to learn in more detail how games work on the GPU, I recommend reading about OpenCL, OpenGL, and game engine architecture.

Upvotes: 1

Related Questions