Simplify FUSE and avoid doubling VL functionalities

[tebjan]

Before the 1.0 stable release the FUSE systems that double functionality of VL.Stride should be removed and replaced by the ones already in place in VL.Stide. This has several advantages:

• The users don't get conFUSEd anymore and only have to learn one GPU/Shader workflow
• The systems will work correctly. Currently, the Fuse copies of the systems aren't on par with the features of VL.Stride and have some issues unsolved that are solved in VL.Stride
• Future improvements are automatically also available in FUSE
• There is only one code base to maintain with the limited manpower available
• FUSE gets smaller and simpler
• FUSE can focus its energy more on its core functionalities of providing modular GPU systems

Systems that are easy to replace

• Shader CPU input handling
• The new copies of the material nodes

The strategy

Taking part in the compilation

Since FUSE is basically a string generator, VL.Stride only needs a node to get a string shader into the mixin system. Fuse hands over the string and VL.Stride takes care of compilation and input key handling.

Input values and ShaderFX to FUSE

Ideally, FUSE only deals with GPU types/values, if it needs a CPU value, a GPU<T> will be composed into the shader. So fuse only needs to make shader permutation keys, but no value keys. VL.Stride will create and compose the CPU inputs. The types between fuse nodes can still be a proprietary type. Buffers and Textures can also be passed by ComputeBuffer or ComputeTexture shaders that return either GPU resource.

FUSE to ShaderFX

The resulting fuse string shader inherits from ComputeFloat4 or any other shader etc. and can be composed normally into other shaders.

All in all, it only needs minor additions to ShaderFX and in FUSE small changes and a lot can be removed.

[chkworks]

Out of curiousity, as it seems the stable release is around the corner - what is the status / opinion about this?

[texone]

With the latest fuse release we can now look into better aligning fuse with vl and stride

Here are my thoughts to it after all it might not all be so easy, there might be details that are not that easily covered, another point to think of is if it makes sense to make fuse not to stride dependend to be open for other renderering front ends, still we code offer solutions for a seemless VL, Fuse Stride Experience. Next Steps could be.

1. Create a CompositionIn or ShaderFXToFuse Node
2. See how far input handling works if we use the shaderfx variants and connect them to fuse with the CompositionIn
   do keys match can one input be connected to multiple shaders
   how do you connect an input to multiple nodes this should be done with one compositionin
   in computeshader when is buffer or texture RW
   how is appendbuffer handled
   how does monadic feature work if inputs are not shaderNodes anymore
   how far would the computesystem needs adjustments
   Once all functionality is established in Test patches we switch to shaderfx inputs
3. Replace DrawShader with DrawFXGraph
   DrawFXGraph needs a way to handle geometry shaders
   Ensure inputs are correctly handled
   Maybe better to handle it like when writing a draw shader where you can have one big shader but can still have other inputs
   For debugging having one shader can help a lot
4. Replace Compute Shader
   ComputeFX needs to add error log
5. Remove Fuse Material
   Currently there is a fuse material wrapper which is annoying but ensures all calculation is done in one graph and all material properties are set as semantics which are than applied in the later stages not sure if this can be handled differently