Compute Shader

[cpt-max]

This PR adds compute shader support for DirectX and OpenGL. It's based on #7352 which already adds tessellation and geometry shaders.

The following use cases are covered (with sample projects):

• Fill up a StructuredBuffer in a compute shader, then use it directly in another shader stage (sample project)
• Fill up a StructuredBuffer in a compute shader, then download the data to the CPU (sample project)
• Write directly to a texture from a compute shader (2D texture sample, 3D texture sample)
• Write directly to a vertex or index buffer from a compute shader (sample project)
• Indirect drawing (simple sample, complex sample)

Compute Shader Guide for MonoGame NuGet Packages, Platform Support and Build Requirements

Shader Migration Guide for OpenGL. Shader Model Support for OpenGL.

[cpt-max]

I added a computer shader guide to the description on top.

[cpt-max]

I added support for writing to textures. A sample has been added on top, and the compute shader guide has been updated.

• Currently only Texture2D is supported, no Texture3D or TextureCube.
• Only mipmap level 0 can be written to.
• Writing to texture arrays is not yet possible.

[cpt-max]

Writing to vertex and index buffers is now also possible, see sample project and the updated compute shader guide on top.

[cpt-max]

3D textures are now also accessible from compute shaders. A sample project can be found on top, even though nothing is fundamentally different than with 2D textures.

Texture arrays are currently not working for GL, maybe once #7361 is merged, I'll add support for those. Writing to mip levels could be added, but I want to look into indirect drawing next. If anyone is interested in mip level support, I'd like to hear about it.

[cpt-max]

Indirect drawing is now also possible. While most people have some idea what compute shaders can do, you may not be familiar with indirect drawing. I added a short explanation to the indirect draw chapter in the compute shader guide.

One thing to look out for with OpenGL at the moment, if you have two buffers of the exact same type

RWStructuredBuffer<Ship> FirendlyShips;
RWStructuredBuffer<Ship> EnemyShips;

the 2nd buffer will get a name change, so in C# you have to set the parameters like this

effect.Parameters["FirendlyShips"].SetValue(firendlyShips);
effect.Parameters["EnemyShips_1"].SetValue(enemyShips);

This is only for OpenGL, and should of course be solved eventually: https://github.com/KhronosGroup/SPIRV-Cross/issues/1721

EDIT: this name conflict issue has been resolved

[JohnLouderback]

This is extremely exciting. Really hope to see this merged soon. 🙂

[cpt-max]

Shader compilation for OpenGL works natively on Linux now, so Wine is not needed anymore (tested on Ubuntu 20.04). I also published NuGet packages, so you can try this out without building from source. The samples have been updated to use the custom packages.

[cpt-max]

Since this PR was recently added to the 3.9 Milestone let me mention some decision that need to be made:

What happens to MojoShader and shader model 2 and 3 support?

• Drop shader model 2 and 3 support completely. I wouldn't mind, but a lot of people probably will.
• Use MojoShader to compile shader model 2 and 3 shaders, use ShaderConductor for shader model 4 and 5. I like this option quite a bit, as It guarantees full backwards compatibility.
• Use ShaderConductor also for shader model 2 and 3. The problem here is that ShaderConductor doesn't work very well for those shader models. It's an open source project and the developers don't seem to care that much about outdated shader models. I don't blame them.

On Mac and iOS OpenGL is still limited to verion 2

This is because OGL is created using the legacy context there. Windows and Linux use the compatibility context which allows mixing of OGL 2, 3 and 4. Apple doesn't support the compatibility context at all. If you want shader model 4+ on Apple platforms you have to create an OGL core context. If you do that you loose OGL 2 support though. That means unlike on Windows/Linux you won't be able to mix shader models 2, 3, 4 and 5. You have to make the decision up front: shader model 2 and 3 using the legacy context, or shader model 4 and 5 using the core context.

This probably means that the feature level (HiDef, Reach) needs to be used for GL as well, currently only DX seems to use it. You would need to make the decision between legacy and core context based on the feature level. It's probably also time for a 3rd feature level: SuperHighDef? HiDef is for DX 10 level hardware, compute shaders need DX 11 hardware.

Oh and of course compute shaders won't work on Apple platforms through OGL anyway, because they stopped at OGL 4.2, compute shaders are 4.3. But shader model 4 and 5 should work, once the core context is supproted.

[damian-666]

ice.js 脚手架遇到了同样问题:

[Ravendarke8]

It is world changing. Even fairly old HW supports compute shaders, honestly, as long as we are talking desktop, every mainstream GPU have full compute functionality. Majority of rendering techniques these days use compute in some way. Efficiently written forward+ / deferred+ (tiled) is impossible without compute. Every state aware particle system runs in compute these days. Hell, there are compute rasterizers that beat normal path (Nanite's rasterization) as well as "software" raytracing. MG supporting compute is absolutely crucial and from where I stand, in last six years that I can remember, this is single handedly most important PR for MG I've seen.

[Ravendarke8]

What happens to MojoShader and shader model 2 and 3 support?

* Drop shader model 2 and 3 support completely. I wouldn't mind, but a lot of people probably will.

* Use MojoShader to compile shader model 2 and 3 shaders, use ShaderConductor for shader model 4 and 5. I like this option quite a bit, as It guarantees full backwards compatibility.

* Use ShaderConductor also for shader model 2 and 3. The problem here is that ShaderConductor doesn't work very well for those shader models. It's an open source project and the developers don't seem to care that much about outdated shader models. I don't blame them.

I would say drop SM 2 - 3 support, BUT that's more in line with MG 4.x+ plans I guess. Hence I completely agree with second option "Use MojoShader to compile shader model 2 and 3 shaders..." I think it is win win scenario for everyone..

[mrhelmut]

I believe that we should be fine dropping SM 2 and 3, we need to move forward at some point. People who need SM 2 or 3 could still use MG 3.8.x.

There is no clear plan yet, but it's likely going to be hard to maintain one single version of monogame that supports each and every scenario. I would vouch for a "legacy" version (something like MG 3.8.x or 3.9.x) with the current OpenGL and Direct3D 11 backends, calling it LTS, and then move into modern stuff with a new numbering (and working with Direct3D 12, Vulkan, and Metal from here).

I also wonder if we should just skip geometry shaders entirely since they are highly discouraged/deprecated and their implementation on each hardware is often a mess (providing it even exists). Compute are much more relevant by now.

[Ravendarke8]

I agree with dropping support of SM 2 / 3 in future, I do not agree with dropping GS support, they are incredibly useful in great many cases (including optimizations) and working perfectly fine on DX. From where I stand they were mostly discouraged by people coming from platforms that have poor or no support for them (if I can't have it, neither can you sort of sad mindset). However I agree that Compute is the most important.

Edit: Also GS is giving you rendering feature edge over Veldrid

[cpt-max]

I finally updated the compute fork to the new MonoGame version (3.8.1). The samples have been updated to .NET 6 and the new compute Nugets (3.8.2). There's now also a Nuget for Android (MonoGame.Framework.Compute.Android) and some Android Samples.

A few more changes:

• Shader files that only contain shader model 2 and 3 shaders will now be compiled by MojoShader instead of ShaderConductor. Check the Shader Migration Guide for more details and a way to override this.
• Added integer surface formats, which can be used for per-pixel atomic operations.
• Assigning default values to shader parameters in HLSL will now also work for OpenGL. This is limited to assigning simple values though, no expressions or identifiers.
• Pixel shaders can now also write to buffers and textures (UAV) like compute shaders. This is DirectX only for now. With OpenGL that's possible too, but a bit more complicated.

[MrScautHD]

Does this support Windows, Linux, Mac and Android + IOS?

[Beyley]

Does this support Windows, Linux, Mac and Android + IOS?

read up in the thread

[MrScautHD]

Does this support Windows, Linux, Mac and Android + IOS?

read up in the thread

i not saw IOS, so does it not?

[cpt-max]

There's this link from my first post: NuGet Packages, Platform Support and Build Requirements A few posts up I'm also talking about iOS: https://github.com/MonoGame/MonoGame/pull/7533#issuecomment-1129300172

[cpt-max]

@cpt-max can you put up a sponsor button ill hit it.

@damian-666 I don't really want to do that. Once I start taking peoples money, I'll feel obligated to deliver something in return. While I have no plans to stop supporting the compute fork, it's just a spare time project for me, not business. If you want to support MG development financially, there's a Patreon page.

[cpt-max]

I published new MGCB Nugets. This fixes an issue where content wasn't built, when building from within the MGCB editor. The new version is 3.8.2.3. This affects the Nugets that go into dotnet-tools.json

[cpt-max]

Solved some merge conflicts and updated to new MG version with .NET 8 support. New NuGet version is 3.8.3.