Mesh Pipelines

[GDBobby]

Mesh Pipelines

Description of changes that aren't implicit.

1. Reordered every mention of Graphics, Compute, Mesh, and Raytracing pipelines to follow that order. For example, in line 331 of IGPUCommandBuffer, Compute was moved below Graphics, and mesh was put below compute, which is above raytracing.
2. In ILogicalDevice, I abstracted the commonalities between Graphics and Mesh pipeline creation. The end result for Graphics doesn't change at all.
3. I'll probably need help with the features and limits. I included the bare minimum.

Testing

https://github.com/GDBobby/Nabla-Examples-and-Tests/tree/master/MeshShader

TODO list:

I need to fix IGPUCommandBuffer::drawMeshTasksIndirect. I haven't done anything with Indirect commands yet so I'll have to figure it out as I go.

[devshgraphicsprogrammingjenkins]

[CI]: Can one of the admins verify this patch?

[devshgraphicsprogramming]

What a wonderful Christmas gift!

[devshgraphicsprogramming]

@GDBobby the last person to add @kevyuu did the RT Pipeline PR, he can review after me

[devshgraphicsprogramming]

as @AnastaZIuk will tell you, this needs to stay as it was, you need to for the submodules yourself as well.

Its important the submodules are relative.

[devshgraphicsprogramming]

you can't add this to all examples, override the function like the raytracing examples in the mesh shader example

[devshgraphicsprogramming]

just use DispatchIndirectCommand_t instead

[devshgraphicsprogramming]

provide only one uint16_t3 overload

[devshgraphicsprogramming]

graphics and mesh bind to same bindpoint (unlike RT which has a separate bindpoint from Compute)

you may need to return a common base class (Ssee how its done for acceleration structures)

[devshgraphicsprogramming]

graphics and mesh bind to same bindpoint (unlike RT which has a separate bindpoint from Compute)

you may need to store a common base class (Ssee how its done for acceleration structures - BLAS and TLAS the GPU types)

[GDBobby]

graphics and mesh bind to same bindpoint (unlike RT which has a separate bindpoint from Compute)

you may need to store a common base class (Ssee how its done for acceleration structures - BLAS and TLAS the GPU types)

Can you explain this further so that I know what kind of change should be made? In what situation are we expecting dynamic dispatch to help?

[devshgraphicsprogramming]

typo ? should be IGPUMeshPipeline probably ?

[GDBobby]

Sorry, I tried to do the signoff rebase, I can undo that.

The most bulky change will be the abstraction between mesh and the traditional graphics bindpoint which I'm awaiting further direction on, it should altogether still take less than an hour or so.

I guess I'm pushing the mesh pipeline change so I'll put my thoughts out.
The easiest change would be to return PipelineBase

 //former
 //const IGPUMeshPipeline* getBoundMeshPipeline() const { return m_boundMeshPipeline; }
 
 //replacement
const IPipelineBase* getBoundRasterizationPipeline() const{return m_boundRasterizationPipeline;}

the alternative would be to make a IRasterizationPipeline, like so

class IMeshPipeline : IRasterizationPipeline : IPipeline;
class IGraphicsPipeline : IRasterizationPipeline : IPipeline;

Graphics Pipeline Libraries are on my todo list within the month, so I'm not very familiar with them. But I've found zero mentions of mesh shaders and libraries within the same text. I'm not sure how the planned pipeline library refactor will change the hypothetical IRasterizationPipeline, which makes me a bit hesitant.

[devshgraphicsprogramming]

Sorry, I tried to do the signoff rebase, I can undo that.

The most bulky change will be the abstraction between mesh and the traditional graphics bindpoint which I'm awaiting further direction on, it should altogether still take less than an hour or so.

I guess I'm pushing the mesh pipeline change so I'll put my thoughts out. The easiest change would be to return PipelineBase

 //former
 //const IGPUMeshPipeline* getBoundMeshPipeline() const { return m_boundMeshPipeline; }
 
 //replacement
const IPipelineBase* getBoundRasterizationPipeline() const{return m_boundRasterizationPipeline;}

the alternative would be to make a IRasterizationPipeline, like so

class IMeshPipeline : IRasterizationPipeline : IPipeline;
class IGraphicsPipeline : IRasterizationPipeline : IPipeline;

Graphics Pipeline Libraries are on my todo list within the month, so I'm not very familiar with them. But I've found zero mentions of mesh shaders and libraries within the same text. I'm not sure how the planned pipeline library refactor will change the hypothetical IRasterizationPipeline, which makes me a bit hesitant.

1. don't force push
2. if in doubt then merge

Now we have commits with two authors

As for your question, make a IRasterizationPipeline please