8000 Add GLSL_EXT_type_deduction by LBV2012-26 · Pull Request #344 · KhronosGroup/GLSL · GitHub
[go: up one dir, main page]

Skip to content

Add GLSL_EXT_type_deduction - #344

Open
LBV2012-26 wants to merge 2 commits into
KhronosGroup:mainfrom
LBV2012-26:main
Open

LBV2012-26 wants to merge 2 commits into
KhronosGroup:mainfrom
LBV2012-26:main

Conversation

@LBV2012-26
@LBV2012-26 LBV2012-26 commented Oct 15, 2026 •
Copy link
Copy Markdown

This commit implement a type deduction feature in GLSL.
I select "auto" because lots of graphics programmer using C++ language, and GLSL is based on C not Rust/Swift/C#.
I’m really not very good at writing long articles, so I used AI assistance to draft this one.
This is my first attempt; I’d really appreciate it if you could point out any mistakes or specific details that could be discussed.
glslang implementation at KhronosGroup/glslang#4473

Copilot AI balanced review requested due to automatic review settings October 15, 2026 02:52
Copilot AI left a comment
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

An organization owner can choose the repository organization as the billing source for reviews requested by members with a paid Copilot license. Learn about Copilot code review billing.

@CLAassistant
CLAassistant commented Oct 15, 2026 •
Copy link
Copy Markdown

CLA assistant check
All committers have signed the CLA.

@arcady-lunarg
Copy link
Copy Markdown

Just out of curiosity, was this spec generated by an AI agent? Who was raising the issues in the "issues" section and who provided the answers?

@LBV2012-26
LBV2012-26 commented Oct 16, 2026 •
Copy link
Copy Markdown
8000 Author

Just out of curiosity, was this spec generated by an AI agent? Who was raising the issues in the "issues" section and who provided the answers?

Not all of it. Let me briefly explain the process I followed in writing it to avoid any misunderstandings. For the code-reading section of glslang, I used AI to help me understand the code architecture and suggest modifications, but I wrote the actual code changes myself. Afterward, I drafted an outline myself, but since it was all in spoken language, I used GPT to refine most of the phrasing. During this process, I didn’t have the AI generate the entire piece in one go; I generally only had it revise one paragraph at a time.
As for the “Issue” section, because I noticed that this section is also included in GL_EXT_buffer_reference, and the first revision already contained some clarifications regarding potential points of confusion. But I'm not entirely sure if it necessary, which is why I'm hoping someone can suggest relevant changes—I'll make the revisions right away.

@arcady-lunarg
Copy link
Copy Markdown

Thanks for answering. I would recommend leaning a bit less on the AI and a bit more on communication with people. In the end, the spec is meant for both shader authors and compiler developers to be able to read and agree on the meaning of.
That said, I am curious what motivated your proposing this extension, what your usage of GLSL looks like, and what use cases you are envisioning for this, and what problems you are trying to solve. I'm also curious if there's any broader demand for this in the GLSL community, but that's not a question you can really answer.

@LBV2012-26
Copy link
Copy Markdown
Author

Thanks for answering. I would recommend leaning a bit less on the AI and a bit more on communication with people. In the end, the spec is meant for both shader authors and compiler developers to be able to read and agree on the meaning of. That said, I am curious what motivated your proposing this extension, what your usage of GLSL looks like, and what use cases you are envisioning for this, and what problems you are trying to solve. I'm also curious if there's any broader demand for this in the GLSL community, but that's not a question you can really answer.

As you know, when GLSL initialize a struct, you can use MyStruct ms = MyStruct(x); to construct it, but if you encounter a relatively long type, I don't think it's necessary to write the type twice. The same applies to function return types. I've been writing shaders for Vulkan using GLSL. I also used Slang for a while, but I found it very awkward to work with. At the Shading Languages Symposium 2026, you encouraged everyone to come up with more ideas, so I’d like to streamline some of the well-proven, stable, and unambiguous syntax features from C++ and incorporate them into the extension to some extent.

@jeffbolznv
Copy link
Copy Markdown
Contributor

FWIW, I would find this handy, e.g. to write auto Acc = coopmat<float, gl_ScopeWorkgroup, Rows, Cols, gl_MatrixUseAccumulator>(0); without repeating the type. But it hasn't been a big enough deal for me to put in the time to spec/implement it.

@LBV2012-26
Copy link
Copy Markdown
Author

Thanks for answering. I would recommend leaning a bit less on the AI and a bit more on communication with people. In the end, the spec is meant for both shader authors and compiler developers to be able to read and agree on the meaning of. That said, I am curious what motivated your proposing this extension, what your usage of GLSL looks like, and what use cases you are envisioning for this, and what problems you are trying to solve. I'm also curious if there's any broader demand for this in the GLSL community, but that's not a question you can really answer.

Hi, I noticed you add two labels on the PR in glslang repo. I'd like to know what the main purpose of those tag are. Thanks for your response.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants

0