<p>It appears that this is indeed a bug within renderdoc. I have encountered the bug I was debugging for in only 1 model, while all the others work fine. In every instance of using the renderdoc debugger, I get the same problem though.</p>

CC BY-SA 4.0
2021-03-14T05:35:46.940Z
It looks like it's replicating the first value of each row of the matrix. Odd, but you could [send them a bug report](https://github.com/baldurk/renderdoc/issues).
Nathan Reed
CC BY-SA 4.0
2021-03-13T23:44:14.813Z
2021-03-13T23:44:14.813Z
xyz
<p>I am attempting to use a compute shader to calculate joint transforms for animations.</p>
<p>I use a loop to calculate the global joint transforms from the local transforms. Relevant code below:</p>
<pre><code>layout(set = 0, binding = 2) readonly buffer LocalTransforms {
    Similarity local_transforms[];
};

layout(set = 0, binding = 3) buffer GlobalTransforms {
    mat4 global_transforms[];
};

struct NodeAndParent {
    uint node_index;
    int parent_index;
};

layout(set = 0, binding = 4) readonly buffer DepthFirstNodes {
    NodeAndParent depth_first_nodes[];
};

void main() {
    uint index = gl_GlobalInvocationID.x;

    uint nodes_offset = index * num_nodes;

    if (nodes_offset &gt;= global_transforms.length()) {
        return;
    }

    for (uint i = 0; i &lt; num_nodes; i++) {
        NodeAndParent indices = depth_first_nodes[i];

        uint node_index = nodes_offset + indices.node_index;
        mat4 local_transform = similarity_to_mat4(local_transforms[node_index]);

        if (indices.parent_index != -1) {
            mat4 parent_transform = global_transforms[nodes_offset + indices.parent_index];
            global_transforms[node_index] = parent_transform * local_transform;
        } else {
            global_transforms[node_index] = local_transform;
        }
    }
</code></pre>
<p>There is a bug somewhere and I have been attempting to use renderdoc to debug it. I have realised that on the first iteration, one matrix is written to index 3 of of the buffer (right side image), but when it is read back as the parent transform on the second iteration (left image), the values reported in renderdoc are incorrect.</p>
<p><a href="https://i.sstatic.net/ktkNY.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/ktkNY.png" alt="enter image description here" /></a></p>
<p>Note that the section of the buffer is not being used by any other thread, and I have an early-exit for threads that would be out-of-bounds of <code>global_transforms</code>. I've tested other threads and they all return early.</p>
<p>My question is this:</p>
<ul>
<li>A) Is it possibly that renderdoc is reporting this incorrectly?</li>
<li>B) Is the value stored in the buffer really like that in that point in time? Would using a barrier help? What kind of barrier?</li>
<li>C) Is there some other problem with the code that could be causing this?</li>
</ul>
<p>Thank you!</p>

CC BY-SA 4.0
2021-03-14T05:32:22.333Z
Are you somehow ensuring that child bones are always processed in the same invocation as the parent bones? Otherwise, a bone could be processed in one invocation before its parent bone's transform has been computed in another invocation. Also, your indexing is confusing me—it looks like every invocation will be processing the same depth_first_nodes elements, but looking at different parts of the local_transforms and global_transforms arrays. Is it for different instances of the same model, or how does that work?
Nathan Reed
<glsl><vulkan><compute-shader>
Mat4 that is written to a storage buffer in a compute shader has an altered value when read back
xyz
# Mat4 that is written to a storage buffer in a compute shader has an altered value when read back

(Asked by: username_0 on 2021-03-13)

I am attempting to use a compute shader to calculate joint transforms for animations.

I use a loop to calculate the global joint transforms from the local transforms. Relevant code below:

```
layout(set = 0, binding = 2) readonly buffer LocalTransforms {
    Similarity local_transforms[];
};

layout(set = 0, binding = 3) buffer GlobalTransforms {
    mat4 global_transforms[];
};

struct NodeAndParent {
    uint node_index;
    int parent_index;
};

layout(set = 0, binding = 4) readonly buffer DepthFirstNodes {
    NodeAndParent depth_first_nodes[];
};

void main() {
    uint index = gl_GlobalInvocationID.x;

    uint nodes_offset = index * num_nodes;

    if (nodes_offset >= global_transforms.length()) {
        return;
    }

    for (uint i = 0; i < num_nodes; i++) {
        NodeAndParent indices = depth_first_nodes[i];

        uint node_index = nodes_offset + indices.node_index;
        mat4 local_transform = similarity_to_mat4(local_transforms[node_index]);

        if (indices.parent_index != -1) {
            mat4 parent_transform = global_transforms[nodes_offset + indices.parent_index];
            global_transforms[node_index] = parent_transform * local_transform;
        } else {
            global_transforms[node_index] = local_transform;
        }
    }

```

There is a bug somewhere and I have been attempting to use renderdoc to debug it. I have realised that on the first iteration, one matrix is written to index 3 of of the buffer (right side image), but when it is read back as the parent transform on the second iteration (left image), the values reported in renderdoc are incorrect.

[![enter image description here](https://i.sstatic.net/ktkNY.png)](https://i.sstatic.net/ktkNY.png)

Note that the section of the buffer is not being used by any other thread, and I have an early-exit for threads that would be out-of-bounds of `global_transforms`. I've tested other threads and they all return early.

My question is this:

* A) Is it possibly that renderdoc is reporting this incorrectly?
* B) Is the value stored in the buffer really like that in that point in time? Would using a barrier help? What kind of barrier?
* C) Is there some other problem with the code that could be causing this?

Thank you!

**Tags:** glsl, vulkan, compute-shader

> **Comments:**
> **username_1**: Are you somehow ensuring that child bones are always processed in the same invocation as the parent bones? Otherwise, a bone could be processed in one invocation before its parent bone's transform has been computed in another invocation. Also, your indexing is confusing me—it looks like every invocation will be processing the same depth_first_nodes elements, but looking at different parts of the local_transforms and global_transforms arrays. Is it for different instances of the same model, or how does that work?  

---

## 1 answers

### Answer by username_0 on 2021-03-13. Score: 1 | Accepted answer

It appears that this is indeed a bug within renderdoc. I have encountered the bug I was debugging for in only 1 model, while all the others work fine. In every instance of using the renderdoc debugger, I get the same problem though.

> **Comments:**
> **username_1**: It looks like it's replicating the first value of each row of the matrix. Odd, but you could [send them a bug report](https://github.com/baldurk/renderdoc/issues).  

---

