@cosmicchipsocket In theory we can implement a new API for Vulkano that would allow shaders loading(and maybe even compiling) in runtime and even in safe way(with some runtime overhead), but it would contradict Vulkan's design approach fundamentals that assume that the user is loading and configuring everything beforehand. Generally speaking if we change the Shader and recreating the Pipeline and all related objects often it could lead to performance penalties in Vulkan(and actually in OpenGL too). Especially when the shaders' code significantly differ between loadings.
If the shader's initial specialization is a goal, then one can use specialization constants on Pipeline creation stage. Specialization constants work in form of "macros" inside the shader, and as such allow to change the shader program workflow significantly. I use this feature often in my project. There is just one huge shader with thousands of lines in source code, and several specialization constants that allow to specialize this large shader into several small one. This approach works perfectly in Vulkano, has no performance issues(at least so far I didn't notice any), and doesn't require Shader re-compilation in runtime.
pipelineinside of a struct. What is the type of
pipeline? It seems like it has to be an Arc of a GraphicsPipeline, where the GraphicsPipeline takes three template parameters. I can't figure out the third parameter. Best I can come up with is
Arc<RenderPass<<Self as DrawControl>::new::scope::CustomRenderPassDesc>>but the compiler says that
<Self as DrawControl>::new::scope::CustomRenderPassDescis not an associated type. I am creating the pipeline within the associated
new()function of my struct. Somehow it's creating a new type within that function? How do I use it to fill in the pipeline definition in my struct?
[u8; 4]instead of a
[f32; 4]in the vertex struct, since i can't figure out where to specify the attribute's format
@pac85_gitlab Are there any advantages in using Concurrent sharing?
you can use the resource from multiple queues without transitioning the ownership which could perform better if you would have to do them frequently .On the other end if you upload some data from a queue after loading it and the always access it from one queue you are better of transitioning the ownership since resources with exclusive sharing will have better performance when you access them. .
BufferSlice::from()and use an &Arc<CpuAccessibleBuffer<T>> as suggested in the documentation, I'm told instead that it's expecting another BufferSlice