Skip to main content
gamedev.net
🔒 Locked

How does driver render a frame?

Started by ajas95 1 reply 1k views
Original Post
ajas95
ajas95
Mainly I'm curious about drivers, so this is maybe a low-level question about how the API interacts with the driver which interacts with the video card. I would just like to know what happens when. For instance, does the driver immediately dispatch commands to the video card to render as it receives them from the API... or does it buffer an entire frame of commands, and only then submit them in one big chunk at the VSync? It seems like the latter case would give the best balance of CPU and GPU performance but would cause an extra frame of lag. Another question relates to the GDC'04 paper OpenGL Performance Tuning. It focuses on identifying application bottlenecks, and on page 8 it addresses CPU Bottlenecks. On a bullet titled "Driver or API limitations" it has "Too many state changes per draw" listed as the main cause. Everybody knows that state changes are bad, but I'd always envisioned them as bad because of GPU stalling... not because of a CPU API stall. Can anyone verify that it is actually a CPU bottleneck and not actually a GPU limitation? This paper was presented as a joint effort of ATI and NVidia at the most watched developer event in the world, so I can't doubt its veracity... I guess it disspells a long-held notion I had about GPU/CPU performance balancing.
outRider
outRider
Your API calls get written to a FIFO command buffer by the library (D3D, GL, etc), the command buffer is hardware independent. The driver then takes the command buffer and creates a FIFO push buffer, which is hardware specific. The GPU then probably reads the push buffer asynchronously and executes the commands. The buffers are usually 1-3 frames worth of data, depending on how much you do per frame.

As for your other question, I have no idea where exactly the state change bottleneck is. I have no idea what happens on a state change, but I can't think of a reason off the top of my head why the hardware would stall significantly either way, it's probably driver bookkeeping instead. Then again, hardware-level info on videocards isn't exactly public knowledge.
Nik02
Nik02
State changes require function calls that span across all layers of the operating system, from your application up to the actual hardware. These functions themselves are costly because of the layer translation, so you should strive to achieve as much as possible with the minimum number of API calls possible (technique known as "batching"). The burden of the call translation falls to the CPU.

Most render state changes are unlikely to stall the rendering itself, but as the command buffer is of finite length, you can - in theory - overload it with state calls.
Niko Suni

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.