Look at this vertex shader:

#version 450

layout(location = 0) in vec3 inPos;

out gl_PerVertex {
    vec4 gl_Position;

layout (std430, binding = 1) buffer depth_range_t {
    int min;
    int max;
} depth_range;

vec3 project(vec4 pt)
// somehow projects to (camera_x, camera_y, distance_to_camera)

void main()
    vec4 translated = ubo.worldToCamera * vec4(inPos.xyz, 1.0);
    vec3 projected = project(vec4(inPos.xyz, 1.0));

    atomicMin(depth_range.min, int(projected.z));
    atomicMax(depth_range.max, int(projected.z));

As you see, it uses two atomic operations, which occur to be embarrassingly slow. Using compute shaders I'd be able to utilize hierarchical architecture of a GPU by atomic operations on shared memory, but this in turn, as I see, would introduce hassle with separate writable buffer for vertices.

Is there any way to leverage device caches directly in vertex shader?

I'm especially interested to find if it's possible using Vulkan API (maybe, SPIR-V tricks?), but would also appreciate any information about possible solutions using other popluar graphics API.

  • $\begingroup$ "Is there any way to leverage device caches directly in vertex shader?" Leverage them to do... what? I mean sure, it's obvious that your shader is attempting to compute the minimum and maximum values for the depth of the vertices in the rendering operation(s), but how exactly would "device caches" help here? $\endgroup$ – Nicol Bolas Jul 12 '19 at 17:33
  • 1
    $\begingroup$ @NicolBolas, from my understanding, atomics on local memory are meant to be faster, so I hoped to just use them. $\endgroup$ – Vladimir Nazarenko Jul 15 '19 at 12:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.