Feature request: Add functions to retrieve attribute information from programs #154

chaoticbob · 2016-02-02T03:12:20Z

Current reflection API is great and is already quite useful. having the ability to query for attribute information such as location, in/out, and type could greatly aid in the porting process from OpenGL to Vulkan. Especially for tools and middleware that parse this information at run-time. Thanks.

tksuoran · 2017-01-02T08:44:06Z

Running glslangvalidator with -V -q shows little useful information on attributes:

a_position: offset 0, type 8b51, size 0, index 0, binding -1
a_normal: offset 0, type 8b51, size 0, index 0, binding -1

Being able to get attribute location and dimension information would be very nice to have indeed.

mittpat · 2018-11-21T03:54:55Z

Same thing here, I was really surprised that this didn't work... great tool otherwise...

`
Vertex attribute reflection:

vertexNormal: offset 0, type 8b51, size 0, index 0, binding -1, stages 0
vertexTexcoord: offset 0, type 8b50, size 0, index 0, binding -1, stages 0
vertexTangent: offset 0, type 8b51, size 0, index 0, binding -1, stages 0
vertexBitangent: offset 0, type 8b51, size 0, index 0, binding -1, stages 0
vertexPosition: offset 0, type 8b51, size 0, index 0, binding -1, stages 0
`

GLSLang computes the xfb_offset for struct members. In fact, for basic structs, the xfb nir gathering pass expect those to be filled, as one struct variable is lowered to several nir variables, and those need to have the xfb offset already set. See [1]. But, as one existing comments at spirv to nir already points: "GLSLang really likes to place decorations in the most interior thing it possibly can. In particular, if you have a struct, it will place the patch decorations on the struct members" And that includes xfb offset. In fact, GLSLang not expose the xfb offset of the full struct, as it is properly assigned to the members, and it makes a lot of the internal checks (like offset overlapping) easier for them. I was not able to find a spec quote saying that is wrong, as all the individual members has the proper offset. This affects the case of variables that are array of structs, are they are exposed as just one nir variable output. So this commit resets the xfb_offset for the nir_variable if any of the members has a xfb_offset assigned. Rant: In general, the rules for xfb offset assignment on the spec are somewhat underspecified for the new ARB_gl_spirv/vulkan world, as it is not clear who is the responsible to do that (in opposite to the old GLSL world, where the answer is "always/everything should solved by the driver"). Ideally, it would be good if glslang does it, so the vulkan/opengl driver just need to get the info. Unfourtunately, there are cases, like arrays of structs where the driver still need to do the assignment. So perhaps in the end it should be the opposite, glslang (or any other frontend), just exposing the explicit info from the user, and let the driver do the individual assignments. Unfourtunately, with the current spec, there isn't anything preventing the frontend to do that, so we would need to be defensive, and cover all aspects. [1] KhronosGroup/glslang#154

GLSLang computes the xfb_offset for struct members. In fact, for basic structs, the xfb nir gathering pass expect those to be filled, as one struct variable is lowered to several nir variables, and those need to have the xfb offset already set. See [1]. But, as one existing comments at spirv to nir already points: "GLSLang really likes to place decorations in the most interior thing it possibly can. In particular, if you have a struct, it will place the patch decorations on the struct members" And that includes xfb offset. In fact, GLSLang not expose the xfb offset of the full struct, as it is properly assigned to the members, and it makes a lot of the internal checks (like offset overlapping) easier for them. I was not able to find a spec quote saying that is wrong, as all the individual members has the proper offset. This affects the case of variables that are array of structs, are they are exposed as just one nir variable output. So this commit resets the xfb_offset for the nir_variable if any of the members has a xfb_offset assigned. Rant: In general, the rules for xfb offset assignment on the spec are somewhat underspecified for the new ARB_gl_spirv/vulkan world, as it is not clear who is the responsible to do that (in opposite to the old GLSL world, where the answer is "always/everything should solved by the driver"). Ideally, it would be good if glslang does it, so the vulkan/opengl driver just need to get the info. Unfourtunately, there are cases, like arrays of structs where the driver still need to do the assignment. So perhaps in the end it should be the opposite, glslang (or any other frontend), just exposing the explicit info from the user, and let the driver do the individual assignments. Unfourtunately, with the current spec, there isn't anything preventing the frontend to do that, so we would need to be defensive, and cover all aspects. [1] KhronosGroup/glslang#154 (cherry picked from commit cfd7e30)

GLSLang computes the xfb_offset for struct members. In fact, for basic structs, the xfb nir gathering pass expect those to be filled, as one struct variable is lowered to several nir variables, and those need to have the xfb offset already set. See [1]. But, as one existing comments at spirv to nir already points: "GLSLang really likes to place decorations in the most interior thing it possibly can. In particular, if you have a struct, it will place the patch decorations on the struct members" And that includes xfb offset. In fact, GLSLang not expose the xfb offset of the full struct, as it is properly assigned to the members, and it makes a lot of the internal checks (like offset overlapping) easier for them. I was not able to find a spec quote saying that is wrong, as all the individual members has the proper offset. This affects the case of variables that are array of structs, are they are exposed as just one nir variable output. So this commit resets the xfb_offset for the nir_variable if any of the members has a xfb_offset assigned. Rant: In general, the rules for xfb offset assignment on the spec are somewhat underspecified for the new ARB_gl_spirv/vulkan world, as it is not clear who is the responsible to do that (in opposite to the old GLSL world, where the answer is "always/everything should solved by the driver"). Ideally, it would be good if glslang does it, so the vulkan/opengl driver just need to get the info. Unfourtunately, there are cases, like arrays of structs where the driver still need to do the assignment. So perhaps in the end it should be the opposite, glslang (or any other frontend), just exposing the explicit info from the user, and let the driver do the individual assignments. Unfourtunately, with the current spec, there isn't anything preventing the frontend to do that, so we would need to be defensive, and cover all aspects. [1] KhronosGroup/glslang#154

GLSLang computes the xfb_offset for struct members. In fact, for basic structs, the xfb nir gathering pass expect those to be filled, as one struct variable is lowered to several nir variables, and those need to have the xfb offset already set. See [1]. But, as one existing comments at spirv to nir already points: "GLSLang really likes to place decorations in the most interior thing it possibly can. In particular, if you have a struct, it will place the patch decorations on the struct members" And that includes xfb offset. In fact, GLSLang not expose the xfb offset of the full struct, as it is properly assigned to the members, and it makes a lot of the internal checks (like offset overlapping) easier for them. I was not able to find a spec quote saying that is wrong, as all the individual members has the proper offset. This affects the case of variables that are array of structs, are they are exposed as just one nir variable output. So this commit resets the xfb_offset for the nir_variable if any of the members has a xfb_offset assigned. Rant: In general, the rules for xfb offset assignment on the spec are somewhat underspecified for the new ARB_gl_spirv/vulkan world, as it is not clear who is the responsible to do that (in opposite to the old GLSL world, where the answer is "always/everything should solved by the driver"). Ideally, it would be good if glslang does it, so the vulkan/opengl driver just need to get the info. Unfourtunately, there are cases, like arrays of structs where the driver still need to do the assignment. So perhaps in the end it should be the opposite, glslang (or any other frontend), just exposing the explicit info from the user, and let the driver do the individual assignments. Unfourtunately, with the current spec, there isn't anything preventing the frontend to do that, so we would need to be defensive, and cover all aspects. [1] KhronosGroup/glslang#154 (cherry picked from commit 51fb1ee)

GLSLang computes the xfb_offset for struct members. In fact, for basic structs, the xfb nir gathering pass expect those to be filled, as one struct variable is lowered to several nir variables, and those need to have the xfb offset already set. See [1]. But, as one existing comments at spirv to nir already points: "GLSLang really likes to place decorations in the most interior thing it possibly can. In particular, if you have a struct, it will place the patch decorations on the struct members" And that includes xfb offset. In fact, GLSLang not expose the xfb offset of the full struct, as it is properly assigned to the members, and it makes a lot of the internal checks (like offset overlapping) easier for them. I was not able to find a spec quote saying that is wrong, as all the individual members has the proper offset. This affects the case of variables that are array of structs, are they are exposed as just one nir variable output. So this commit resets the xfb_offset for the nir_variable if any of the members has a xfb_offset assigned. Rant: In general, the rules for xfb offset assignment on the spec are somewhat underspecified for the new ARB_gl_spirv/vulkan world, as it is not clear who is the responsible to do that (in opposite to the old GLSL world, where the answer is "always/everything should solved by the driver"). Ideally, it would be good if glslang does it, so the vulkan/opengl driver just need to get the info. Unfourtunately, there are cases, like arrays of structs where the driver still need to do the assignment. So perhaps in the end it should be the opposite, glslang (or any other frontend), just exposing the explicit info from the user, and let the driver do the individual assignments. Unfourtunately, with the current spec, there isn't anything preventing the frontend to do that, so we would need to be defensive, and cover all aspects. [1] KhronosGroup/glslang#154

GLSLang computes the xfb_offset for struct members. In fact, for basic structs, the xfb nir gathering pass expect those to be filled, as one struct variable is splitted to several nir variables, and those need to have the xfb offset already set. See [1]. But in addition to that, after computing the xfb offset, GLSLang unsets the xfb offset for the full struct, or array of structs. This affects the case of variables that are array of structs, as they are exposed as just one nir variable output. This commit resets the xfb_offset for the nir_variable if any of the members has a xfb_offset assigned. FWIW, this was not needed for array of blocks because on that case we are iteraring through all the members of the array of blocks, in order to support the case where just some members were assigned a xfb_offset. [1] KhronosGroup/glslang#154 Equivalent to previous patch (so comments applies), but implemented on a different place. We would need to chose in which one.

GLSLang computes the xfb_offset for struct members. In fact, for basic structs, the xfb nir gathering pass expect those to be filled, as one struct variable is lowered to several nir variables, and those need to have the xfb offset already set. See [1]. But, as one existing comments at spirv to nir already points: "GLSLang really likes to place decorations in the most interior thing it possibly can. In particular, if you have a struct, it will place the patch decorations on the struct members" And that includes xfb offset. In fact, GLSLang not expose the xfb offset of the full struct, as it is properly assigned to the members, and it makes a lot of the internal checks (like offset overlapping) easier for them. I was not able to find a spec quote saying that is wrong, as all the individual members has the proper offset. This affects the case of variables that are array of structs, are they are exposed as just one nir variable output. So this commit resets the xfb_offset for the nir_variable if any of the members has a xfb_offset assigned. Rant: In general, the rules for xfb offset assignment on the spec are somewhat underspecified for the new ARB_gl_spirv/vulkan world, as it is not clear who is the responsible to do that (in opposite to the old GLSL world, where the answer is "always/everything should solved by the driver"). Ideally, it would be good if glslang does it, so the vulkan/opengl driver just need to get the info. Unfourtunately, there are cases, like arrays of structs where the driver still need to do the assignment. So perhaps in the end it should be the opposite, glslang (or any other frontend), just exposing the explicit info from the user, and let the driver do the individual assignments. Unfourtunately, with the current spec, there isn't anything preventing the frontend to do that, so we would need to be defensive, and cover all aspects. [1] KhronosGroup/glslang#154 (cherry picked from commit 2d91af2)

GLSLang computes the xfb_offset for struct members. In fact, for basic structs, the xfb nir gathering pass expect those to be filled, as one struct variable is splitted to several nir variables, and those need to have the xfb offset already set. See [1]. But in addition to that, after computing the xfb offset, GLSLang unsets the xfb offset for the full struct, or array of structs. This affects the case of variables that are array of structs, as they are exposed as just one nir variable output. This commit resets the xfb_offset for the nir_variable if any of the members has a xfb_offset assigned. FWIW, this was not needed for array of blocks because on that case we are iteraring through all the members of the array of blocks, in order to support the case where just some members were assigned a xfb_offset. [1] KhronosGroup/glslang#154 Equivalent to previous patch (so comments applies), but implemented on a different place. We would need to chose in which one.

GLSLang computes the xfb_offset for struct members. In fact, for basic structs, the xfb nir gathering pass expect those to be filled, as one struct variable is lowered to several nir variables, and those need to have the xfb offset already set. See [1]. But, as one existing comments at spirv to nir already points: "GLSLang really likes to place decorations in the most interior thing it possibly can. In particular, if you have a struct, it will place the patch decorations on the struct members" And that includes xfb offset. In fact, GLSLang not expose the xfb offset of the full struct, as it is properly assigned to the members, and it makes a lot of the internal checks (like offset overlapping) easier for them. I was not able to find a spec quote saying that is wrong, as all the individual members has the proper offset. This affects the case of variables that are array of structs, are they are exposed as just one nir variable output. So this commit resets the xfb_offset for the nir_variable if any of the members has a xfb_offset assigned. Rant: In general, the rules for xfb offset assignment on the spec are somewhat underspecified for the new ARB_gl_spirv/vulkan world, as it is not clear who is the responsible to do that (in opposite to the old GLSL world, where the answer is "always/everything should solved by the driver"). Ideally, it would be good if glslang does it, so the vulkan/opengl driver just need to get the info. Unfourtunately, there are cases, like arrays of structs where the driver still need to do the assignment. So perhaps in the end it should be the opposite, glslang (or any other frontend), just exposing the explicit info from the user, and let the driver do the individual assignments. Unfourtunately, with the current spec, there isn't anything preventing the frontend to do that, so we would need to be defensive, and cover all aspects. [1] KhronosGroup/glslang#154

GLSLang computes the xfb_offset for struct members. In fact, for basic structs, the xfb nir gathering pass expect those to be filled, as one struct variable is splitted to several nir variables, and those need to have the xfb offset already set. See [1]. But in addition to that, after computing the xfb offset, GLSLang unsets the xfb offset for the full struct, or array of structs. This affects the case of variables that are array of structs, as they are exposed as just one nir variable output. This commit resets the xfb_offset for the nir_variable if any of the members has a xfb_offset assigned. FWIW, this was not needed for array of blocks because on that case we are iteraring through all the members of the array of blocks, in order to support the case where just some members were assigned a xfb_offset. [1] KhronosGroup/glslang#154 Equivalent to previous patch (so comments applies), but implemented on a different place. We would need to chose in which one.

GLSLang computes the xfb_offset for struct members. In fact, for basic structs, the xfb nir gathering pass expect those to be filled, as one struct variable is lowered to several nir variables, and those need to have the xfb offset already set. See [1]. But, as one existing comments at spirv to nir already points: "GLSLang really likes to place decorations in the most interior thing it possibly can. In particular, if you have a struct, it will place the patch decorations on the struct members" And that includes xfb offset. In fact, GLSLang not expose the xfb offset of the full struct, as it is properly assigned to the members, and it makes a lot of the internal checks (like offset overlapping) easier for them. I was not able to find a spec quote saying that is wrong, as all the individual members has the proper offset. This affects the case of variables that are array of structs, are they are exposed as just one nir variable output. So this commit resets the xfb_offset for the nir_variable if any of the members has a xfb_offset assigned. Rant: In general, the rules for xfb offset assignment on the spec are somewhat underspecified for the new ARB_gl_spirv/vulkan world, as it is not clear who is the responsible to do that (in opposite to the old GLSL world, where the answer is "always/everything should solved by the driver"). Ideally, it would be good if glslang does it, so the vulkan/opengl driver just need to get the info. Unfourtunately, there are cases, like arrays of structs where the driver still need to do the assignment. So perhaps in the end it should be the opposite, glslang (or any other frontend), just exposing the explicit info from the user, and let the driver do the individual assignments. Unfourtunately, with the current spec, there isn't anything preventing the frontend to do that, so we would need to be defensive, and cover all aspects. [1] KhronosGroup/glslang#154

GLSLang computes the xfb_offset for struct members. In fact, for basic structs, the xfb nir gathering pass expect those to be filled, as one struct variable is lowered to several nir variables, and those need to have the xfb offset already set. See [1]. But, as one existing comments at spirv to nir already points: "GLSLang really likes to place decorations in the most interior thing it possibly can. In particular, if you have a struct, it will place the patch decorations on the struct members" And that includes xfb offset. In fact, GLSLang not expose the xfb offset of the full struct, as it is properly assigned to the members, and it makes a lot of the internal checks (like offset overlapping) easier for them. I was not able to find a spec quote saying that is wrong, as all the individual members has the proper offset. This affects the case of variables that are array of structs, are they are exposed as just one nir variable output. So this commit resets the xfb_offset for the nir_variable if any of the members has a xfb_offset assigned. Rant: In general, the rules for xfb offset assignment on the spec are somewhat underspecified for the new ARB_gl_spirv/vulkan world, as it is not clear who is the responsible to do that (in opposite to the old GLSL world, where the answer is "always/everything should solved by the driver"). Ideally, it would be good if glslang does it, so the vulkan/opengl driver just need to get the info. Unfourtunately, there are cases, like arrays of structs where the driver still need to do the assignment. So perhaps in the end it should be the opposite, glslang (or any other frontend), just exposing the explicit info from the user, and let the driver do the individual assignments. Unfourtunately, with the current spec, there isn't anything preventing the frontend to do that, so we would need to be defensive, and cover all aspects. [1] KhronosGroup/glslang#154 (cherry picked from commit d3c7fb6)

arcady-lunarg · 2023-07-13T20:35:10Z

@chaoticbob is this still needed or is the equivalent functionality available through spirv-reflect?

johnkslang added the enhancement label Feb 2, 2016

chaoticbob mentioned this issue Feb 28, 2016

Cinder Vulkan back-end (NormalMappingBasic test app): ciBlock1T UB is assigned a 12-byte range of a buffer view cinder/Cinder#1342

Closed

johnkslang added the GLSL/ESSL label Aug 12, 2016

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Feature request: Add functions to retrieve attribute information from programs #154

Feature request: Add functions to retrieve attribute information from programs #154

chaoticbob commented Feb 2, 2016

tksuoran commented Jan 2, 2017

mittpat commented Nov 21, 2018 •

edited

arcady-lunarg commented Jul 13, 2023

Feature request: Add functions to retrieve attribute information from programs #154

Feature request: Add functions to retrieve attribute information from programs #154

Comments

chaoticbob commented Feb 2, 2016

tksuoran commented Jan 2, 2017

mittpat commented Nov 21, 2018 • edited

arcady-lunarg commented Jul 13, 2023

mittpat commented Nov 21, 2018 •

edited