!fjjkgHFcwtkREywzfk:matrix.org

Naga Shader Translator

103 Members
Embracing HLSL9 Servers

Load older messages


SenderMessageTime
27 Jul 2021
@kvark:matrix.orgkvarkOk, I'll try to finish your pr17:39:57
@pyrotechnick:matrix.orgpyrotechnickThanks. No rush really. I feel like it's close but I lost confidence finding code paths that seem untested17:44:56
@pyrotechnick:matrix.orgpyrotechnickOK I've bisected the GLSL stuff and it comes from https://github.com/gfx-rs/naga/commit/e76824aba3583b4a509454aa0605f930c046928518:05:22
@pyrotechnick:matrix.orgpyrotechnickNot sure why it didn't disappear after a rebase and force-push but you can basically disregard all of the changes to GLSL output suggested by the PR18:24:39
28 Jul 2021
@kvark:matrix.orgkvark Gordon-F: are you around by any chance? https://github.com/gfx-rs/naga/pull/1144 00:09:35
@kvark:matrix.orgkvarkI don't get why there needs to be mapping from types to names00:10:36
@kvark:matrix.orgkvarkIIRC, GL queries are not on types anyway, they are on variable names00:10:48
@dj2:matrix.orgdj2 pyrotechnick: in general, with the WGSL spec, the grammar is looser then the text. So, the grammar may allow things that are then explicitly disallowed by the text (in some cases they're hard to specify in the grammar). So, the text is what should be followed for restrictions based on what the grammar allows 02:22:43
@kvark:matrix.orgkvark pyrotechnick: I think the approach pays off very well. As such, for example, a chunk of IR validation for the access just goes away, because it's correct by construction. 04:56:01
@indish:matrix.orgGordon-F kvark: Could you explain, how backend should know which function argument in/out/inout based on a pointer? https://github.com/gfx-rs/naga/issues/1147 14:40:09
@indish:matrix.orgGordon-F

For example:

#version 460

layout (location = 0) out vec4 fragColor;

void MyFunction(in float inputValue, out float outputValue, inout float inAndOutValue)
{
  inputValue = 0.0;
  outputValue = inAndOutValue + inputValue;
  inAndOutValue = 3.0;
}

void main()
{
    float in1 = fragColor.x;
  	float out1 = fragColor.y;
  	float out2 = fragColor.z;
  	MyFunction(in1, out1, out2);
	fragColor = vec4(0.4, 0.4, 0.8, 1.0);
}
[1]: Function {
            name: Some(
                "MyFunction",
            ),
            arguments: [
                FunctionArgument {
                    name: Some(
                        "inputValue",
                    ),
                    ty: [2],
                    binding: None,
                },
                FunctionArgument {
                    name: Some(
                        "outputValue",
                    ),
                    ty: [3],
                    binding: None,
                },
                FunctionArgument {
                    name: Some(
                        "inAndOutValue",
                    ),
                    ty: [3],
                    binding: None,
                },
            ],
        [3]: Type {
            name: None,
            inner: Pointer {
                base: [2],
                class: Function,
            },
        },
14:40:14
@indish:matrix.orgGordon-F All MyFunction arguments are the same in IR. 14:41:17
@indish:matrix.orgGordon-F Or outputValue and inAndOutValue arguments should be with class Private? 14:49:51
@kvark:matrix.orgkvark
In reply to @indish:matrix.org
All MyFunction arguments are the same in IR.
That means glsl-in is producing bad IR
15:58:40
@kvark:matrix.orgkvarkIt needs to treat these arguments as pointers16:02:04
@kvark:matrix.orgkvark(Just like spirv)16:02:17
@jcapucho:matrix.orgjcapuchoHmm that ir seems fine to me, the out and inout should be function class pointers and in is just a regular argument16:03:03
@jcapucho:matrix.orgjcapucho* Hmm that ir seems fine to me, the out and inout should be function class pointers and in is just a regular argument16:03:38
@indish:matrix.orgGordon-F
In reply to @kvark:matrix.org
It needs to treat these arguments as pointers
These arguments are pointers:
16:29:48
@indish:matrix.orgGordon-F
[3]: Type {
            name: None,
            inner: Pointer {
                base: [2],
                class: Function,
            },
        },
16:29:54
@indish:matrix.orgGordon-F *
[3]: Type {
            name: None,
            inner: Pointer {
                base: [2],
                class: Function,
            },
        },
16:30:11
@indish:matrix.orgGordon-Fspv-in produce the same IR.16:47:09
@kvark:matrix.orgkvark So it's the glsl-out problem 16:56:38
@indish:matrix.orgGordon-F
In reply to @kvark:matrix.org
So it's the glsl-out problem
Sorry, I still don't understand. How glsl-out can handle it? We have 3 different function arguments from the GLSL lang perspective and 3 the same arguments in IR. (All 3 are Pointers with Function class).
17:06:43
@kvark:matrix.orgkvark Hmm. So glsl can just conservatively assume inout for pointer arguments 17:15:51
@jimb:mozilla.orgjimb
In reply to @kvark:matrix.org
we should also require it in the validator
I don't think we can require Vertex entry points to always have Builtin::Position in their results, because neither GLSL nor SPIR-V require this.
21:37:18
@jimb:mozilla.orgjimb The front ends would have to insert dummy Position pass-through code. 21:37:45
@jimb:mozilla.orgjimb For example tests/in/glsl/280-matrix-cast.vert is a GLSL vertex shader that does nothing with gl_Position. 21:41:32
@kvark:matrix.orgkvarkMSL requires and and WebGPU requires it. Are you saying we shouldn't require it in Naga specifically?22:06:24
@kvark:matrix.orgkvarkthat's fine by me22:06:28

There are no newer messages yet.


Back to Room List