Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Cosmic Chip Socket
    @cosmicchipsocket
    What does this use as a backend? Is it easily embeddable? https://crates.io/crates/glsl-to-spirv
    And why is it deprecated?
    Ella-0
    @Ella-0
    Vulkano uses shaderc-rs for compiling shaders I'm fairly sure
    Cosmic Chip Socket
    @cosmicchipsocket
    Yes but that's compile-time. I need a way to safely load shaders at runtime without bloating the binary size
    Ella-0
    @Ella-0
    You can use shaderc at runtime. I'm not sure about the safety of it though.
    Cosmic Chip Socket
    @cosmicchipsocket
    Yes but that's going to make my binary really big
    Also since it's a non-Rust library it will complicate build environment setup
    I'm not concerned about safety in something like shaderc. I assume they have that sort of thing covered
    But I am concerned about the binary remaining around roughly 2MB
    And ease of setup
    Okay so apparently shaderc depends on glslang anyway
    On my system the glslang package is 13.44 MiB
    That is after the removal of debug symbols
    Cosmic Chip Socket
    @cosmicchipsocket
    Has anyone ever distributed something using shaderc as a runtime component? What libraries need to be included alongside the binary?
    Given that runtime loading of shaders is done by like every game engine I'm honestly surprised there doesn't seem to be a good way of handling this currently
    Cosmic Chip Socket
    @cosmicchipsocket
    I understand that this is outside the scope of Vulkan as an API but given that Glium has such an easy way to do this (make_program()) I would have expected similar in at least an add-on library.
    And the methods of doing this safely well-documented
    Cosmic Chip Socket
    @cosmicchipsocket
    Hmm, for now I could get around this by just using pre-compiled SPIR-V shaders and introducing a basic trust model in my resource system
    So that shaders can't be loaded from untrusted sources
    Eliah Lakhin
    @eliah_lakhin_twitter

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

    Cosmic Chip Socket
    @cosmicchipsocket
    Why would one need to keep recreating the pipeline? Just create pipelines for each shader right at load-time and hang onto them, right? It would only really be a load-time issue, probably faster than OpenGL anyway because of the lack of need to compile the high level shader code (assuming SPIR-V is used).
    Cosmic Chip Socket
    @cosmicchipsocket
    The idea behind wanting to load custom shaders is for special effects for specific objects that wouldn't necessarily apply to everything else. So just having one standard shader wouldn't really work here.
    I already understand that this isn't really a core "goal" of Vulkan which is why I suggested it as an add-on library.
    Chevy Ray Johnston
    @ChevyRay
    hi, new to gitter and starting out with Vulkano. if i have a simple code question, may i just ask it here?
    Cosmic Chip Socket
    @cosmicchipsocket
    I don't see why not
    Cosmic Chip Socket
    @cosmicchipsocket
    So I'm trying to create a pipeline for instanced draws, like here: https://github.com/vulkano-rs/vulkano/blob/master/examples/src/bin/instancing.rs
    But I need to store pipeline inside 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::CustomRenderPassDesc is 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?
    Cosmic Chip Socket
    @cosmicchipsocket
    Oops, looks like the question was answered above! My bad
    Chevy Ray Johnston
    @ChevyRay
    cool, so my Q is about mapping the vertex struct to attributes...
    that's the full question, to save spamming here. but basically i can't figure out how to use a [u8; 4] instead of a [f32; 4] in the vertex struct, since i can't figure out where to specify the attribute's format
    antonino
    @pac85_gitlab

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

    in any case vulkano is still at 0.19.0, I'm started to be worried that it might have been abandoned.
    Cosmic Chip Socket
    @cosmicchipsocket
    I too am concerned, especially for something that is arguably quite important to the ecosystem
    Cosmic Chip Socket
    @cosmicchipsocket
    So in the call to AutoCommandBufferBuilder::draw_indexed(), according to this example, you can pass a tuple for the vertex buffer to have a vertex/instance pairing https://github.com/vulkano-rs/vulkano/blob/master/examples/src/bin/instancing.rs#L327
    But when I try it in my application, I'm told that it expects a Vec instead. Should this be a Vec?
    Also, I'm having difficulty using BufferSlice, because I want to only draw the portion of the buffer that has been filled with data. If I try BufferSlice::from() and use an &Arc<CpuAccessibleBuffer<T>> as suggested in the documentation, I'm told instead that it's expecting another BufferSlice
    Cosmic Chip Socket
    @cosmicchipsocket
    Finally, I can't seem to figure out how to write to an already-created buffer. I can do write().map() but use of this seems to be undocumented
    Cosmic Chip Socket
    @cosmicchipsocket
    So I'm trying to replace the CpuAccessibleBuffer for instances with a CpuBufferPool. However, I can't use it in draw() because it's not an Arc type (it in fact wraps one)
    Cosmic Chip Socket
    @cosmicchipsocket
    Think I got it working now
    Vivian Leigh Stewart
    @vivichrist
    In order to first do a compute operation to prepare an image and then blit that image to the current swapchain framebuffer for display. What are the steps necessary to swap between pipelines in the eventloop? I know that synchronisation is one of them.
    Cosmic Chip Socket
    @cosmicchipsocket
    I'm trying to figure out some performance issues with my new Vulkano renderer - the drawing overhead currently is even worse than glium. Seems like if I call CpuBufferPool::chunk() about 3000 times a frame performance just dies, not only in try_next_impl() but also cleanup_finished() dropping lots and lots of Arcs. What is the correct way to use CpuBufferPool? It doesn't seem like it's doing any reusing of resources at all!
    CpuBufferPool::chunk() is being called every time I submit a draw
    What is the best way to resolve this?
    Cosmic Chip Socket
    @cosmicchipsocket
    Would posting a question via the bug tracker be an appropriate way to ask about this? Because I'd really like to fix this performance bottleneck and am looking for help from someone who is more familiar with buffers in Vulkano
    The performance is really bad and the existing tutorial resource about buffer usage is insufficient
    Cosmic Chip Socket
    @cosmicchipsocket
    Vulkano seems to provide no resources about how to 1. reuse buffer resources by putting them in a struct (the examples all exist in a vacuum, nothing about the types of the buffers to store them for later), 2. write data to certain structs (the tutorial seems outdated and I can't access a CpuAccessibleBuffer by index after a call to write(), and no way to rewrite the contents of a CpuBufferPool chunk), 3. use two different types of buffers for the vertex and instance buffers in a draw() call (putting them in a tuple does not compile, and putting them in a vec means both need to be an Arc type, so I have to create a new Arc for each submit, which seems to be adding a lot of overhead) - I don't understand what type the vertex parameter is looking for, and how to make something that satisfies the type with my vertex and instance buffers while still being performant
    I have so many questions. Does anyone still read the gitter?
    Will I have to contact individual project maintainers to ask for help?