Vertex shader output variables morphing

Hello.

Though I have been using OpenGL for some time now, I have posted in under ‘Basic Coding’ because I feel if this isn’t a driver bug, then I might be missing something very simple.

I have been experimenting with geometry shaders recently to allow me to take some work more work off the CPU.

In my current minial example I have this setup:

Vertex Shader

#version 330 core

uniform mat4 gfxPV;

in mat4 gfxTransform;

flat out int instID;
out mat4 vertTransform;

void main()
{
    instID = gl_InstanceID;
    vertTransform = gfxTransform;
}

Geometry Shader

#version 330 core

layout (points) in;
layout (triangle_strip, max_vertices = 4) out;

flat in int instID[];
in mat4 vertTransform[];

uniform mat4 gfxPV;

out vec2 uv;

void main()
{
... // Construct a square for each input point
}

I was facing issues and decided to debug it using RenderDoc, only to find this as a result:

If you notice in the vertex shader output section, for some reason the instID value is overwriting the first column of the vertTransform matrix.

I have been unable to fix this despite a days worth of trying, and by extension I am beginning to suspect that this may in fact be a driver bug. In the case that this is a bug with the driver, I am using OpenGL 4.6 (Core Profile) Mesa 20.2.3.

Thanks in advance for any help and info given!

I don’t know if that might be the source of the problem, but why in the GS, your inputs are arrays whereas they are simple variables in the output of your VS ?

That is how geometry shaders work.
A vertex shader runs once for each individual vertex and it only knows about that one single vertex.
All the output of the vertex shader for an entire object(or primitive), must then be sent to the geometry shader.
The geometry shader runs over an entire primitive, so the output of the vertex shader’s running on each individual vertex get combined together into an array for the geometry shader.

Or atleast, I’m pretty sure that’s the case.

OK. I never used inputs other than built-in in GS.

But you might be interested in reading this and this, interface blocks have special semantics for non-sized arrays. If I’m not wrong only the last declaration in the interface block can be a non-sized array. Therefore I would rearrange everything around a named interface block, with the whole being an array instead of having each variable being an array (or give fix sizes for each of your inputs).

Have tried it, even putting each field in a separate block. It had no effect.

Thanks for the help though!