@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.

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

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

Is there any update on getting this officially merged into monogame ?

The foundation is planning to merge the move to ShaderConductor in its next goals, but the addition of other shader stages will be considered after DesktopVK and WindowsGDK, and the move NativeAOT on consoles have shipped (those are the priority at the moment).

The foundation is planning to merge the move to ShaderConductor in its next goals, but the addition of other shader stages will be considered after DesktopVK and WindowsGDK, and the move NativeAOT on consoles have shipped (those are the priority at the moment).

I have a small question, the shader conductor github seems abandoned by microsoft, will the monogame foundation plan to support the maintainance of (a fork of) shaderconductor alongside monogame ?

I have a small question, the shader conductor github seems abandoned by microsoft, will the monogame foundation plan to support the maintainance of (a fork of) shaderconductor alongside monogame ?

I likely shouldn't have mentioned ShaderConductor at all because we might not even need it.

A few points regarding this:

• Most of this code in this PR is applicable with or without ShaderConductor. Essentially this PR is to add new graphics features (4 new shader stages including compute), to allow higher shader levels and to no longer be limited by the MojoShader issues.
• With this PR ShaderConductor is really only used in the content building pipeline, not the MonoGame.Framework.
• ShaderConductor states that "it glues existing open source components to do the cross-compiling". The two main open source components to this are DirectXShaderCompiler and SPIRV-Cross, both of which are very actively maintained. ShaderConductor just assists building and wrapping these libraries together.
• The main methods at ShaderConductor's core are around 1k lines of code, so the ShaderConductor approach doesn't necessarily need ShaderConductor itself.
• This PR doesn't remove MojoShader and rather works side-by-side with it, laying the framework for multiple shader pipeline options via MGCB arguments. This way there are no breaking API changes (and this is also why I'm still not sure why this PR has been moved to the 5.0 roadmap).

• Most of this code in this PR is applicable with or without ShaderConductor. Essentially this PR is to add new graphics features (4 new shader stages including compute), to allow higher shader levels and to no longer be limited by the MojoShader issues.

I've reviewed and tested this PR a while ago, I know. MojoShader needs to go.

• ShaderConductor states that "it glues existing open source components to do the cross-compiling". The two main open source components to this are DirectXShaderCompiler and SPIRV-Cross, both of which are very actively maintained. ShaderConductor just assists building and wrapping these libraries together

We really don't need ShaderConductor at all for what MonoGame needs to do. A while ago, it used to be relevant considering that we were expecting to keep DesktopGL around (so that's what we still have written on our roadmap and why I mentioned it like this, but it's more about cleaning things out than moving to another tool), but now that the future is mostly going to be about the Vulkan and DX12 implementations, we don't need anything actually, those pipeline are implemented now and running without specific tools. Mojoshader and OpenGL will just retire once the new targets are stable. We won't even need SPIRV-Cross (unless we keep OpenGL around for some reason like mobiles).

• This way there are no breaking API changes (and this is also why I'm still not sure why this PR has been moved to the 5.0 roadmap).

Because it has breaking changes in the public API. The other important thing is that we're expecting feature changes/new features to have feature-parity throughout all platforms. Who's going to implement these changes for consoles (some stages just work entirely differently there, so that makes it challenging)? Likely someone at the foundation because we don't have that many contributors with clearances for all consoles. So that makes few people, with non-unlimited time. That's mostly why this PR is in a limbo. If we were against it, we would have closed it. We could skip its implementation for consoles, but that still makes a bunch of changes to make that takes time for every private platforms.

Then comes the discussion about priorities. Adding new shader stages currently isn't a hot topic because besides the people asking for it in this thread, the vast majority of MonoGame's users don't even know what a geometry shader is. We also want to clear the current refactor work before introducing new features or breaking stuff. The current priorities are moving everything to NativeAOT and refactoring everything into the native backend (which will allow the private platforms to be less sensitive to public API changes).

I understand the frustration that some people have around this very PR (and sorry for that), and the fact that some people in the community are using this PR as the avatar of "MonoGame isn't modern" (it's part of the game, we accept those comments) but we need to stay focused on what's hot.

We'll get to this PR, and we're trying to accelerate things. That's all I can say.

Thanks for the comprehensive reply, I was replying primarily to orobogdan's concern that "shader conductor github seems abandoned by Microsoft" in particular though. That's why I mentioned the "code in this PR is applicable with or without ShaderConductor" and "the ShaderConductor approach doesn't necessarily need ShaderConductor itself".

Adding new shader stages currently isn't a hot topic because besides the people asking for it in this thread, the vast majority of MonoGame's users don't even know what a geometry shader is.

Just an observation but compute shaders do get raised in the community discord from time to time, sometimes by people considering MonoGame for their project. Also while some won't use compute shaders directly, they may still benefit indirectly through the libraries built for MonoGame which may add updated features (graphic effects, particle shaders, physics engine improvements, etc). I agree though that there are definitely other priorities first.

Because it has breaking changes in the public API.

Maybe I have misunderstood in that case then. In my own experience I've been able to swap directly without changing method arguments in around 10 or so games. I haven't done a full line by line review to confirm this fully though.

The approach I particularly like with this PR is the side-by-side design of not directly swapping all in one go (everything or nothing) but having the content pipeline option to use the existing system or the new experimental system on a per shader basis. It's a bit like the experimental flags in browsers where existing systems work as expected but new features can be tested/developed by anyone while retaining the option to include, rework or scrap the implementation down the line.

In any case I'm looking forward to hearing more about progress and the roadmap at the Open Hours event!

Yes, cpt-max put a lot of effort in having a "isMojoshader" path and a newer path. For what it is, this PR is good and clean, and it's really cool that it is being distributed properly too with documentation.

It's just that "it's complicated" to get it moving forward upstream due to all the platforms.

We hope that moving to the native backend will make things much smoother, with much less situations like this one (because changing the public API will have less impact on platform implementations).