HLSL: RWBuffers not implemented, Compute shaders not implemented either?

[dankbaker]

A very simple compute shader:

RWBuffer<uint> s_InstanceArguments : register(u0);


cbuffer ComputeInputs : register(b0)
{
    uint g_Diamonds : packoffset(c0.x);
};

[numthreads(64,1,1)]
void SetInstanceArgs(uint3 DTid : SV_DispatchThreadID)
{
     s_InstanceArguments[ 0 ] = 6;
     s_InstanceArguments[ 1 ] = g_Diamonds;
     s_InstanceArguments[ 2 ] = 0;
     s_InstanceArguments[ 3 ] = 0; 
     s_InstanceArguments[ 4 ] = 0;
}

This shader has a number of compilation issues:

1. RWBuffer isn't even accepted as a token

2. u type registers aren't accepted as grammer

3. Doesn't appear that [numthreads(64,1,1)] attribute is parsed, or rather any attribute is parsed before a function.

This leads me to think that there is no work yet at all on Compute Shaders. The first 2 problems would manifest themselves on other shader stages since IIRC all shader stages can have UAVs in D3D12.

[johnkslang]

Yes, these have not been on the radar (missing in the todo list in issue #362). Perhaps it's time to close issue #362 and go for individual ones instead? Otherwise, it's still nice to see these lined up in one place.

It is useful to see the examples.

[dankbaker]

Do compute shaders not compile at all? It wasn't clear to me if they hadn't been implemented at all or if just there was alot of missing syntax. e.g. are these bugs or are they major missing features?

[johnkslang]

I don't think we've tried compute shaders yet.

[dankbaker]

Ok, I can probably get some of these to parse but I think I would have trouble getting the right AST for them.

Seems like there will 5 main things for compute shaders

1. RWBuffer support. It may be close to identical to Buffers
2. Syntax for dereferencing a RWBuffer, which ends up being the [] array syntax
3. Ability to understand both the attribute for thread group size and the various SV_ semantics needed for input types
4. Support for local shared memory
5. Support for threadgroup syncronization

1 & 2 are needed actually for other shader stages since you can write to buffers from anywhere in the pipe now.

Is this on anyone's radar presently?

[ghost]

Is this on anyone's radar presently?

I've been aware of RWBuffer, but it's been far down on my priority list, so I haven't given it even as much thought as you just did in the previous post :). I had noticed the dereference operator on buffers in the SM5 syntax, but haven't thought about that much yet either.

[johnkslang]

various SV_ semantics

@dankbaker were you still going to submit a PR that fleshed out the relevant set of SV_* handleSemantic() has the placeholder set of example ones.

Otherwise, I want to move basic "to do" items to the issue #362, rather than tracking separate issues for things not done (or vice versa, but I think that can wait a month or so, and then we'll turn #362 into individual issues for what's still remaining).

[dankbaker]

I can parse them sure, but I don't know enough about the AST to know how to
translate all of them. Is the issue turning them into valid SPRIV or just
understanding what they are and what they do?

-D

On Wed, Aug 17, 2016 at 1:29 PM, John Kessenich notifications@github.com
wrote:

various SV_ semantics

@dankbaker https://github.com/dankbaker were you still going to submit
a PR that fleshed out the relevant set of SV_* handleSemantic() has the
placeholder set of example ones.

Otherwise, I want to move basic "to do" items to the issue #362
#362, rather than
tracking separate issues for things not done (or vice versa, but I think
that can wait a month or so, and then we'll turn #362
#362 into individual
issues for what's still remaining).

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#460 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AC-AU5p-7bLS3-OE3q0Nq1lC7aFzKakyks5qg0TjgaJpZM4Jjf8l
.

[johnkslang]

All the parsing is already done, as is the AST work. If you look at handleSemantic() you'll see a trivial mapping that has to get fleshed out between HLSL SV_* names and GLSL built-in variable names, with 10 examples already in place.

[johnkslang]

The SV_* is in, and the missing items are in issue #362, so closing this one.