Implement Veldrid vertex buffers #5595
Conversation
| @@ -19,6 +19,7 @@ public class VertexMemberAttribute : Attribute | |||
| /// The type of each component of this vertex attribute member. | |||
| /// E.g. a <see cref="osuTK.Vector2"/> is represented by 2 **<see cref="VertexAttribPointerType.Float"/>** components. | |||
| /// </summary> | |||
| // todo: this should be replaced by an enum defined in o!f. | |||
There was a problem hiding this comment.
As per above, we shouldn't rely on using osuTK enums for o!f rendering code anymore, but seeing that changing the enum would be a breaking change, I've left a TODO for now.
| if (!pipelineCache.TryGetValue(pipeline, out var instance)) | ||
| { | ||
| pipelineCache[pipeline] = instance = Factory.CreateGraphicsPipeline(ref pipeline); | ||
| stat_graphics_pipeline_created.Value++; | ||
| } |
There was a problem hiding this comment.
This is kinda scary. So we need a new graphics pipeline for every set of shaders/textures/framebuffers/etc, because they're immutable? The construction of these pipelines does not seem trivial.
It may be something that we'll need to have a dynamic cache for to expire older items, because I can foresee this cache getting quite large.
I suppose the cost is fine in the context that this is effectively a context switch, now at a CPU level just as much as it is at a GPU level.
There was a problem hiding this comment.
I'm not 100% sure about my statistics, but checking the "total pipelines created" one on o!f visual tests it interestingly doesn't get beyond 3 different pipeline states. So I felt it's sufficient now just for the time being.
Implementations mostly copied from
GLVertexBufferand siblings. Not too sure aboutVeldridIndexData, I've went with it just to have something working (in a similar manner toGLLinearIndexData), but it's completely up for refactor.