2
\$\begingroup\$

In older systems, the CPU calculates the final vertex positions and feeds those, along with material properties, color, lighting info and uv position for each vertex and the GPU renders the image based on that data. Does this still hold true for modern game engines, or has some of this work been offloaded to the GPU instead?

For example; to me it would make sense that the GPU would have the 3D model and the CPU would just give the position, rotation and scale so the GPU can calculate the final vertex positions instead.

\$\endgroup\$
4
  • \$\begingroup\$ If by "older systems" you mean circa the late 90s/early 2000s, maybe. We've been mostly keeping object-space vertex data persistent in video memory and just uploading a transformation matrix each frame for the last two decades. There are some exceptions for batching, skinning, and procedurally modified geometry, but even those have GPU-side options (with certain tradeoffs). What resource are you looking at that's saying vertex transformation is/was mainly done CPU-side? It might be talking about a special case, or else it may be very out of date. \$\endgroup\$
    – DMGregory
    Commented Apr 24 at 15:59
  • \$\begingroup\$ @DMGregory At least based on my knowledge, on the Nintendo DS you do it the way I described. You have a set of "geometry commands" you use to send the 3D data to the GPU and it will draw the frame based on that. Some games even have the 3D models structure described as geometry commands rather than vertices, uvs, etc. I don't know if this is one of the exceptions and I incorrectly assumed that this was common back then. \$\endgroup\$
    – NMITIMEN
    Commented Apr 25 at 5:58
  • \$\begingroup\$ The DS is a bit different, since it doesn't have the same kind of programmable pipeline that PCs and non-portable consoles have had since the Xbox/PS3 generation. If you want to learn about developing for portable consoles specifically, that would be good detail to include in your question. \$\endgroup\$
    – DMGregory
    Commented Apr 25 at 10:43
  • \$\begingroup\$ Well not specifically, I just used it as an example. \$\endgroup\$
    – NMITIMEN
    Commented Apr 25 at 11:08

2 Answers 2

3
\$\begingroup\$

With modern rendering APIs, one of the main ways that the CPU remains involved with the rendering process is with draw calls. The process that you've described of passing rendering parameters (such as transformation, lighting, and material settings) to the GPU is done via draw calls.

Each draw call has some overhead, so a large number of draw calls may cause performance to degrade. To mitigate this, some engines will spend CPU time trying to optimize the draw calls before sending them to the GPU. Some common optimizations are culling (discarding objects that will definitely not be visible to the camera), instancing (rendering multiple copies of one mesh in different places at the same time), and batching (combining multiple meshes into one). Draw call optimizations are a delicate balancing act; if not configured correctly, they can actually hurt performance. A modern engine should let the developer adjust the settings for these optimizations, sometimes on a per-object basis.

A relatively new area of rendering which makes heavier use of the CPU is raytracing. Even when using a GPU with hardware-accelerated raytracing (like the NVidia RTX series), raytracing is well known to greatly increase CPU usage in many games. Systems with a modern raytrace-capable GPU but older CPU may bottleneck on the CPU. I am not very familiar with how hardware-accelerated raytracing works under the hood, so I can't be more specific about how the CPU is involved in the hardware-accelerated raytracing process.

\$\endgroup\$
0
\$\begingroup\$

These days, a lot of the rendering process can be done entirely on the GPU.

Even things like frustum culling can be done on a modern GPU. You might find this 2015 paper on GPU driven rendering interesting.

Of course, just because it's possible to offload those tasks to the GPU, it doesn't mean that lots of games actually do that.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .