Draw call

A draw call is a command that an application running on the CPU issues through a graphics API, such as OpenGL, Direct3D, Metal or Vulkan, to make the graphics processing unit (GPU) draw a set of geometry. Each call submits a group of primitives, usually triangles, that share the same render state: the same shaders, textures, buffers and other settings. In OpenGL the basic draw calls are functions such as glDrawArrays; in Vulkan, "drawing commands (commands with Draw in the name) provoke work in a graphics pipeline". The work submitted by one draw call is often called a "batch".

Much of the overhead of a draw call falls on the CPU, which has to set up render state and pass the command through the graphics driver. When a scene is split into many small draw calls, the CPU can become the bottleneck while the GPU waits for work. This matters more in virtual reality (VR) than in flat-screen games. A headset needs two views of the scene at a high, fixed frame rate, and a naive stereo renderer issues every draw call twice. Mobile and standalone headsets such as the Meta Quest 3 also run on battery-powered processors with limited heat dissipation. Draw call counts are a standard performance budget in VR development guidelines, and techniques such as batching, instancing and single-pass stereo rendering are used to reduce them.

Reviewed 11 October 2026. Checked every claim against the cited Khronos/Vulkan specs, Unity and Meta developer docs, Microsoft/Apple/AMD/Google announcements, the Wloka, Vlachos, Everitt and Intel PDFs, Johansson (JCGT 2016), Miranto et al. (BEEI 2025) and the Lujan IEEE abstracts. About review dates.

How it works

Unity's documentation divides a draw call into two steps. First the CPU updates the render state: it uses the graphics API to prepare and send everything the GPU needs to draw the mesh, such as shader code, textures and buffers. Unity describes this as the most CPU-intensive step. Second, the CPU submits the draw call itself, telling the GPU what to draw. By default each mesh in a Unity scene needs its own draw call. In NVIDIA's 2003 definition, every Direct3D DrawIndexedPrimitive() call was a batch: it submitted some number of triangles, the same render state applied to all of them, and the state-setting calls made before the draw counted as part of the batch. Changing state meant at least two batches.

A draw call can draw more than one copy of its geometry. Vulkan's vkCmdDraw takes a vertex count and an instance count, and Vulkan also has indirect drawing commands that read their parameters from buffer memory instead of from the CPU-side call. The OpenGL extension ARB_draw_instanced, approved by the OpenGL Architecture Review Board in 2008, introduced instanced draw calls that are "conceptually equivalent to a series of draw calls"; a vertex shader reads a built-in instance ID and can use it to fetch per-instance data such as a transform. The later ARB_multi_draw_indirect extension, approved in 2012, lets an application assemble "large batches of drawing commands" in a GPU buffer and dispatch them with one function call.

CPU-bound and GPU-bound rendering

Johansson, writing in the Journal of Computer Graphics Techniques and following Hillaire (2012), summarizes the distinction this way: if an application is CPU-bound, its performance depends mostly on the number of draw calls and related state changes per frame; if it is GPU-bound, it depends on the number of triangles drawn and the complexity of the shader stages. A draw call count therefore says little about GPU load on its own. Meta's WebXR guidance gives an example: submitting 1,000 individual triangles as separate draw calls would likely keep an app below 72 frames per second, even though the Quest GPU can render several orders of magnitude more triangles.

History

Batch counts in the early 2000s

Matthias Wloka of NVIDIA measured the problem in a talk at the Game Developers Conference in 2003. His test application drew about 100,000 triangles per frame in batches of different sizes, changing state between draws. Below an average of about 130 triangles per batch the application was "100% CPU limited", and throughput in batches per second depended on CPU speed rather than on the GPU. A profile of a 1 GHz Pentium 3 drawing two triangles per batch showed 78 percent of the time in the driver and 14 percent in the Direct3D runtime.

From games he examined, Wloka derived a rule of thumb of about 25,000 batches per second using 100 percent of a 1 GHz CPU. His budget formula multiplied that figure by the CPU clock in GHz and by the share of CPU time available for draw and state calls, divided by the target frame rate: a 2 GHz CPU spending 20 percent of its time on submission at 30 frames per second gets about 333 batches per frame. He argued that the work grows linearly with the number of batches, that driver optimizations can reduce the constant but not the order, and that because GPUs were getting faster more quickly than CPUs, developers should put more triangles into each batch instead of making more batches. He suggested packing several textures into one surface and pre-transforming static geometry so that more objects could share a batch.

In the 2005 book GPU Gems 2, Francesco Carucci of Lionhead Studios cited Wloka's finding that a 1 GHz CPU could submit only around 10,000 to 40,000 batches per second in Direct3D, and estimated that a newer CPU could manage around 30,000 to 120,000, or about 1,000 to 4,000 batches per frame at 30 frames per second. As an example, he noted that a forest drawn with one tree per batch could not contain more than 4,000 trees, with no CPU time left for the rest of the game. His chapter described geometry instancing as a way to render many copies of the same geometry in fewer calls.

Low-overhead graphics APIs

Lower per-draw-call overhead was a headline goal of several graphics APIs introduced in the 2010s. In September 2013 AMD announced Mantle, and AMD's Raja Koduri said it would allow nine times as many draw calls per second as rival APIs by reducing CPU overhead. In a March 2014 blog post introducing Direct3D 12, Microsoft said it would deliver "significantly reduced draw call overhead, and many more draw calls per frame". Microsoft's documentation lists "vastly reduced CPU overhead" as its first benefit over Direct3D 11 and says the freed CPU time can be used to increase the number of draw calls. At GDC 2014, engineers from AMD, Intel and NVIDIA presented "Approaching Zero Driver Overhead in OpenGL", a session on OpenGL techniques that the presenters said could reduce driver overhead "by up to 10x or more" across vendors. In June 2014 Apple introduced Metal for iOS 8 and claimed a "10 times improvement in draw call speed".

Vulkan, from the Khronos Group, followed the same approach. Google's Android team wrote in April 2016 that Vulkan's lower CPU overhead let some synthetic benchmarks reach as much as 10 times the draw call throughput on a single core compared with OpenGL ES, and that applications submit draw calls into command buffers that can be reused. Benchmarks measure this directly: the 3DMark API Overhead test for Android raises the number of draw calls step by step and reports how many draw calls per second each API achieves before the frame rate falls below 30 frames per second.

Peer-reviewed comparisons have found the gains depend on workload. In a 2019 study on a graphics rendering server, Lujan and colleagues reported that OpenGL's performance was unpredictable, that Vulkan saved a significant amount of energy at the same performance, and that OpenGL could not keep up with Vulkan when an extremely high frame rate was required. A 2021 follow-up on an ARM processor with big and LITTLE cores, motivated by the battery drain of mobile games and VR, found that Vulkan could save up to 24 percent of energy on heavy workloads by running in parallel on the LITTLE cores and could render at a much higher frame rate once OpenGL ES reached its limit, but that the gains were negligible for light workloads.

Reducing draw calls

Engines and graphics programmers use several methods to cut the number of draw calls or the cost of each one.

Method	How it reduces draw call cost
Static batching	Combines static meshes that use the same material into shared vertex and index buffers in world space so they can be drawn with fewer render state updates. Unity's implementation allows up to 64,000 vertices per buffer.
GPU instancing	Draws many copies of the same mesh and material in one draw call, with per-instance properties such as color or scale. Unity notes that the benefit depends on the platform and is larger on mobile than on desktop.
Fewer render state changes	Unity's SRP Batcher reduces render state updates with techniques such as large GPU buffers. Meta recommends sharing and instancing meshes, using global texture arrays and limiting an app to a small set of unified shaders.
Texture packing	Packing several textures into one surface lets objects with different textures share a batch, at the cost of tool support and possibly wasted texture space.
Culling and level of detail	Frustum and occlusion culling remove objects that cannot be seen, so they are never submitted; Meta's PC guidelines list level of detail, culling and batching as ways to stay within its draw call limit.
Indirect and multi-draw commands	Draw parameters live in GPU buffers, and one call can dispatch many draws.
Low-overhead APIs	Direct3D 12, Metal and Vulkan reduce the CPU and driver cost per draw call; Direct3D 12 is designed to make full use of multithreading, and Vulkan command buffers can be reused.

Reducing draw calls is not always worth its own cost. Johansson found that for one building model, once occlusion culling and stereo instancing were in use, the high level of occlusion in its exterior views meant that average frame times were actually lower with geometry instancing and batching of walls turned off. Unity's engineers, comparing stereo rendering modes in 2017, found only a small CPU difference between single-pass and single-pass instanced rendering: instancing removes draw calls, but they wrote that this cost is quite low compared with processing the scene graph, and that issuing draw calls can be quite fast on the dispatching thread because most modern drivers are multithreaded.

Draw calls in VR and AR

Stereo rendering

A VR frame has two views, one per eye. Meta's PC performance guidelines note that rendering both views typically means every draw call is issued twice, every mesh drawn twice and every texture bound twice. Johansson made the same point: a two-pass stereo renderer doubles the number of occlusion tests, rasterized triangles and issued draw calls. The Khronos OVR_multiview specification, whose contact is Cass Everitt of Oculus and whose contributors include John Carmack, states that sequential stereo rendering "typically incurs double the application and driver overhead, despite the fact that the command streams and render states are almost identical".

Several methods remove the duplicate draw calls. In his GDC 2015 talk "Advanced VR Rendering", Valve's Alex Vlachos rated running the CPU code twice as "BAD", resubmitting command buffers as "GOOD" (Valve's solution at the time) and using instancing to double the geometry as "BETTER", with "half the API calls". With stereo instancing, an application replaces each draw call with an instanced one, for example glDrawArraysInstanced in place of glDrawArrays, using an instance count of two, and the vertex shader uses the instance ID to project each vertex for the left or the right eye. Unity's engineers wrote that this approach "literally halve[s] the number of draw calls" on the API side. In multiview rendering, "draw calls are instanced into each corresponding element of the texture array", and the vertex shader reads a view ID to compute per-view values such as vertex position. Vulkan's VK_KHR_multiview has the same goal, describing multiview as "a rendering technique originally designed for VR"; its functionality became part of core Vulkan 1.1. Meta's RenderDoc guide for Unreal Engine developers says instanced stereo or multiview halves the number of draw calls in the base pass, with each draw call dispatching two instances per mesh.

On mobile hardware the savings were measured early. Presenting at SIGGRAPH 2016, Everitt said that once devices with multiview support became available, real and synthetic apps showed CPU time reductions of 33 to 49 percent, and power numbers dropped by 27 to 33 percent; he added that driver overhead and validation with multiview cost about the same as monoscopic rendering.

Other effects multiply draw calls further. In a 2019 Meta developer blog post, Trevor Dasch advised against a depth pre-pass on mobile VR because it doubles the draw calls, and noted that rendering a mirror or portal the naive way can triple them; he wrote that "draw calls are quite heavy on the cpu".

Draw call budgets

Meta's performance guidelines for PC VR apps recommend limiting each frame to a maximum of 500 to 1,000 draw calls and 1 to 2 million triangles or vertices. For its standalone headsets Meta publishes example ranges that depend on how much other work the app does on the CPU. Meta says the number of draw calls an app can afford depends on pipeline state changes, the capacity of the main and render threads and the graphics API, and that CPU work such as animation, skinning and networking can delay the render thread. It describes "busy" apps as those with heavy simulation such as many networked players or NPCs, "medium" as fitting most apps, and "light" as apps with minimal state changes such as puzzle games.

Example draw call ranges per frame for Meta Quest headsets (Meta developer documentation)

Headset	Busy simulation	Medium simulation	Light simulation
Oculus Quest (Quest 1)	50-150	150-250	200-400
Meta Quest 2, Meta Quest Pro	80-200	200-300	400-600
Meta Quest 3, Meta Quest 3S	200-300	400-600	700-1000

Meta calls these figures examples and says actual results vary. In January 2020 UploadVR reported that Unity had added Vulkan support for the Oculus Quest, noting that Vulkan's lower-level access to the hardware means less driver overhead for draw calls, so more draw calls can be used each frame. Browser-based WebXR apps face the same limit. Meta's WebXR guide lists too many draw calls as a common cause of CPU-bound apps and recommends batching objects that share a material, merging small meshes, and using multiview or instanced mesh rendering, while still culling instanced meshes.

Case studies and research

In a 2016 Intel case study, application engineer Finn Wong profiled Pangu, a PC VR game from Tencent built on Direct3D 11. Before optimization the game ran at an average of 36.4 frames per second on an Oculus Rift DK2 with 4,437 draw calls per frame and GPU load of 49.64 percent, because the GPU sat idle while the CPU prepared draw calls, culling and other work. Wong noted that Direct3D 11 rendering is single-threaded and has relatively high draw call overhead compared with Direct3D 12. After optimizations that included level of detail, Instanced Stereo Rendering, removal of dynamic shadows and an earlier start for the render thread, the game ran at 71.4 frames per second on an HTC Vive with 845 draw calls per frame, and the CPU-bound period in each frame fell from 7.37 ms to 2.62 ms.

Johansson's 2016 study used building information models (BIM) of a dormitory, a hotel and an office, targeting the 90 Hz minimum frame rate (11.1 ms per frame) set for the consumer Oculus Rift and HTC Vive. With only view frustum culling, the models were mainly CPU-bound because of the large number of draw calls relative to the number of triangles. Stereo instancing cut average frame times on exterior camera paths by 27 to 52 percent compared with two-pass rendering on a GeForce GTX 980M. The exterior of the hotel model still had too many visible objects, and it reached 90 Hz only after the number of draw calls was cut further by combining occlusion culling and stereo instancing with batching of wall geometry and geometry instancing.

Draw call counts also appear as a standard metric in applied VR research. In a 2025 study in the Bulletin of Electrical Engineering and Informatics, Miranto and colleagues measured frame rate, triangle count and draw calls in a Unity climate-education simulation running on a Meta Quest 3, treating triangle count as an indicator of GPU load and draw calls as an indicator of CPU load. They used static batching for terrain and infrastructure and GPU instancing for repeated trees; their baseline scene had 55,370 triangles and 65 draw calls. Trees with transparent, alpha-cutout foliage reduced batching efficiency and cost more GPU time than high-triangle opaque character models.

See also

• Single-pass stereo rendering
• Stereoscopic rendering
• Graphics pipeline
• Graphics processing unit
• CPU
• Occlusion culling
• Level of detail
• Vulkan
• Rendering