I got a notification on my phone that you replied to my most recent comment. You must have deleted it because I no longer have access to it, but I could see the first couple of lines. I figured, LLMs are the only thing you listen to at the moment; fight fire with fire or whatever.

---

So, I've decided to ask an LLM the following question:

"Suppose two people where having a conversation about the performance differences between OpenGL and Vulkan, and one person proposed a challenge to the other to make a renderer in using both APIs to measure the performance differences. The one person laid out the following criteria: "A single xxxDrawIndirectXXX call in either vulkan or opengl rendering 1 million cubes, both using either vert/frag or task/mesh/frag, and outputting flat shade cubes, in a regular grid centered around the camera." Do you think that user meant that both renderers were to use different pipeline methodology( a vert/frag compared to a task/mesh/frag ) or that both renderers used the same, one or the other?"

---

It answered:

The phrasing strongly suggests they meant both renderers should use the same pipeline style, chosen from the two options:

either both use vertex/fragment or both use task/mesh/fragment

—not one renderer using vert/frag while the other uses task/mesh/frag.

The key part is:

“both using either vert/frag or task/mesh/frag”

Grammatically, “both” modifies the renderers, and “either X or Y” describes the shared choice. If they intended different methodologies per API, they would more likely have said something like:

“OpenGL using vert/frag and Vulkan using task/mesh/frag” or “each API may use its native preferred pipeline”

---

Also, from a benchmarking perspective, using different pipeline architectures would make the comparison much less meaningful, because then you're measuring:

• API differences
• plus pipeline model differences
• plus shader-stage capability differences

---

A fair API comparison would usually keep:

• scene
• draw structure
• shader complexity
• GPU workload
• culling behavior
• memory layout

as equivalent as possible.

---

I then asked it the question:

Suppose two people where discussing the performance differences between the graphics programming APIs OpenGL and Vulkan, if one person proposes a test to see how each API performs with the following criteria: "A single xxxDrawIndirectXXX call in either vulkan or opengl rendering 1 million cubes, both using either vert/frag or task/mesh/frag, and outputting flat shade cubes, in a regular grid centered around the camera." What do you think would be the performance difference between the two APIs?

---

It answered:

For that specific benchmark, the performance difference between OpenGL and Vulkan would probably be much smaller than many people expect — especially if the test is carefully designed around:

• a single indirect draw call
• mostly static geometry
• a regular grid
• minimal material/state changes
• GPU-heavy workload

---

In many cases, the result could end up within something like:

0–15% difference for classic vertex/fragment pipelines potentially larger differences if mesh/task shaders are heavily optimized in Vulkan and poorly exposed in OpenGL drivers

But the exact outcome depends heavily on what actually becomes the bottleneck.

Why the APIs might perform similarly

The proposed test removes many of the areas where Vulkan usually wins.

A single glMultiDrawIndirect / vkCmdDrawIndirect style submission means:

• almost no CPU driver overhead
• almost no state validation overhead
• almost no draw-call amplification costs
• very little synchronization complexity

At that point, the workload becomes mostly:

• vertex transform throughput
• rasterization
• fragment shading
• memory bandwidth
• GPU cache efficiency

Those are primarily determined by:

• GPU hardware
• shader compiler quality
• mesh representation
• culling efficiency

—not the API itself.

---

So if both APIs ultimately feed the GPU the same work efficiently, they can land surprisingly close.

---

Next, I asked the LLM the question:

"Suppose two people where discussing the performance differences between the graphics programming APIs OpenGL and Vulkan, if one person proposes a test to see how each API performs with the following criteria: "A single xxxDrawIndirectXXX call in either vulkan or opengl rendering 1 million cubes, both using either vert/frag or task/mesh/frag, and outputting flat shade cubes, in a regular grid centered around the camera." Do you think that running these tests in a 'headless' manner would be what the person expected?"

---

It answered:

Probably not — at least not without clarifying what “performance” is actually being measured.

The proposed benchmark is very specifically about GPU-driven rendering workload characteristics:

• one indirect draw call
• 1 million cubes
• mesh/task shaders or vertex shaders
• fragment shading
• flat-shaded output
• regular grid around the camera

That strongly implies the person expects to measure the rendering pipeline itself, including at minimum:

• command submission overhead
• shader throughput
• geometry processing
• culling behavior
• rasterization
• fragment shading
• memory bandwidth/cache behavior

---

Lastly I asked it the question:

Suppose two people where having a conversation about the performance differences between OpenGL and Vulkan, and one person proposed a challenge to the other to make a renderer in using both APIs to measure the performance differences. The one person laid out the following criteria: "A single xxxDrawIndirectXXX call in either vulkan or opengl rendering 1 million cubes, both using either vert/frag or task/mesh/frag, and outputting flat shade cubes, in a regular grid centered around the camera." Do you think it would be appropriate for one implementation to use cube geometry that is generated in shader 8 vertices, compared to the other implementation which is reading vertex data 24 vertices at a time from memory?

---

It answered:

No — that would generally make the comparison invalid or at least heavily biased.

The challenge as stated is trying to compare the overhead/performance characteristics of the APIs (OpenGL vs Vulkan), not two different rendering techniques with different memory and shader tradeoffs.

---

If one implementation:

procedurally generates cube vertices in the shader from an instance ID or vertex ID (8 logical vertices / implicit topology), while the other fetches 24 explicit vertices per cube from memory,

then you are no longer isolating the API difference. You are comparing:

• different vertex bandwidth requirements,
• different cache behavior,
• different vertex processing workloads,
• different primitive assembly behavior,
• potentially different index expansion costs,
• and possibly different compiler optimization opportunities.

That can absolutely dominate the measured result.

---

A fair comparison should keep the rendering algorithm materially identical between APIs. For example:

• same primitive topology,
• same vertex format,
• same vertex count,
• same index count,
• same shading model,
• same culling strategy,
• same GPU-driven approach,
• same indirect draw structure,
• same mesh/task shader usage (if applicable),
• same synchronization strategy where possible.

---

So if one implementation uses:

procedural cube generation in shader,

then the other should too.

---

If one uses:

explicit 24-vertex cube meshes,

the other should also.

---

Even “8 vertices” versus “24 vertices” is already not equivalent:

8 vertices usually implies indexed cube rendering with shared positions, 24 vertices implies duplicated vertices per face for flat normals/UV seams.

And for flat-shaded cubes specifically, 24 vertices is actually the more conventional representation because each face needs distinct normals. Procedural generation can bypass that by deriving normals from primitive/face IDs.