Help needed: Problems with compute shaders about shadergen HOT 9 CLOSED

The OpenGL problem is caused by the #version header being wrong. Basically, we need to detect when StructuredBuffers are being used, and switch to #version 430 core. We already switch versions in some cases when different resource types are used -- we just missed this one. This is working in Compute shaders because those automatically default to 430 core.

_cl.SetComputeResourceSet(0, _computeResourceSet);
_cl.SetComputeResourceSet(1, _computeScreenSizeResourceSet);

This part of ShaderGen isn't terribly well-documented. If you don't do anything special, then all of the resources you define will go into set 0. To override that, you have to put a [ResourceSet] attribute on the field. So the public ScreenSize ScreenSize; field should have [ResourceSet(1)] above it. That should fix up the resource linkage.

Note that the D3D11 backend doesn't care about ResourceSet's per-se. Everything gets translated into a flat binding scheme there, so as long as the resources are in order, then things will work out. I'm not sure why the particles are moving too fast there -- that's potentially a different problem.

from shadergen.

Thanks, I’ll try that out tomorrow, I managed to figure most stuff out myself from diving through the code, but I ran out of time and I just don’t have enough shader experience. If I get it working would you like me to fork Veldrid-Samples and create a Pull Request with the updated shader for ComputeParticles, as it would be nice to have a complete example with Compute Shaders? I understand the benefit of not all the shaders using ShaderGen in the samples.

I also converted the shaders to embedded resources as you did in the other ShaderGen projects.

from shadergen.

I think I would prefer to keep things as-is over in Veldrid-Samples, but I appreciate the offer. I've had feedback that people would rather see the shader code explicitly in the repo rather than have another tool introduced to them. I would like if at least the "basic" examples are using regular shader code, even if it takes longer to write.

I'll go ahead and fix the #version issue in a minute.

from shadergen.

So the public ScreenSize ScreenSize; field should have [ResourceSet(1)] above it.

Thanks, adding the explicit ResourceSet attributes to the shaders fixed both the zoomies and the Vulkan crash.

I think I would prefer to keep things as-is over in Veldrid-Samples

Understood!

I'll go ahead and fix the #version issue in a minute.

Great, thanks! What's the NuGet pre-release strategy, is it done automatically on pull request acceptance?

from shadergen.

Great, thanks! What's the NuGet pre-release strategy, is it done automatically on pull request acceptance?

Yep, new versions are automatically pushed to myget when a commit happens. I think that I fixed the #versino issue in this commit.

from shadergen.

Yep, new versions are automatically pushed to myget when a commit happens. I think that I fixed the #versino issue in this commit.

I couldn't see any update when using the NuGet browser, so I went and checked the myget feed directly here and noticed that the build names are not correctly formatted, and so don't sort as you would expect.

Although the latest by date is:

1.2.0-beta2-g464080fc94	47.06 KB	Mon, 14 May 2018 04:58:00 GMT

it appears a long way down the list, with

1.2.0-beta2-g464080fc94	47.06 KB	Mon, 14 May 2018 04:58:00 GMT

appearing first, and so being the 'latest' by NuGet naming convention. As such Visual Studio won't show any update being available (it takes the first item in the feed as the latest).

To fix you need to use the correct semantic version (see (here)[https://docs.microsoft.com/en-us/nuget/reference/package-versioning]). Part of the issue is that the builds are currently outputting 1.2.0-beta2, which technically preceed 1.2.0-g due to suffices being sorted alphabetically.

You can supply build metadata in Semantic version 2, but technically it should be preceeded with a '+' not a '-' to indicate it is build metadata. Also, you should avoid on 'official' releases as it isn't supported by older NuGet clients.

e.g. (in descending order)

1.2.0+gf000000000
1.2.0+ge000000000
1.2.0-beta+gd000000000
1.2.0-alpha+gc000000000
1.9.2+gb000000000

Hope that helps.

from shadergen.

Yeah, browsing in the VS UI won't work very well -- personally I just always manually edit package references and have less issues that way.

I would like to improve the CI auto-versioning, but I haven't looked into the specifics of it. Right now, the versioning is just handled by this package, and I haven't tried to customize it very much. Perhaps there's a way that we can get it to spit out something like v1.2.0-master-125 ?

You can supply build metadata in Semantic version 2, but technically it should be preceeded with a '+' not a '-' to indicate it is build metadata. Also, you should avoid on 'official' releases as it isn't supported by older NuGet clients.

Sure -- the git tag is just there for the rolling builds from CI. I'm not sure if the GitVersioning library lets you change the delimiter there. I think I'm just using the default.

from shadergen.

@mellinoe - I did a quick read through of the Nerdbank.GitVersioning Nuget and I think you may be using it wrong.

The 3rd, 'patch' value is supposed to be set automatically by Nerdbank to the Git Height, so that it gives the expected package ordering. However, yours is always hard coded '0'. This seems to be because this line in version.json:
"version": "1.2.0.0-beta2"

should read:
"version": "1.2-beta2"

according to the specified file format.

I recommend you correct to "1.3-beta" to start numbering correctly.

from shadergen.

This appears to be corrected in 71806a5.

from shadergen.