Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Syntaxxor
    @Syntaxxor
    Hello! Just dropping in to ask if the tutorial will be completed for this project. It's a cool project, but since I'm not super familiar with Vulkan in general, I would greatly prefer to have a full tutorial that doesn't stop in the middle of implementing swapchains.
    Syntaxxor
    @Syntaxxor
    Should I just download the triangle example and then pretend to understand it until I actually get it to really work properly? Because I guess I could do that.
    Ilya Lakhin
    @Eliah-Lakhin

    @Syntaxxor Hi Syntaxxor. Sorry, this chat is rarely maintaining. In the future you can raise questions and suggestions in the repo's Issues section. They are watching by me and the community more frequently.

    Regarding your question. Currently examples is probably the main source of truth for new comers. Site's tutorial is a bit outdated, but it also could be a place to start learning. If you want to refresh the Tutorial, this is very welcome and will be very beneficial for the community! Anyway, please raise this topic in the Issues section first.

    Braden McDorman
    @bmcdorman

    Hi, I'm having some trouble with a AccessError(AlreadyInUse) when executing a command buffer. I'm using a compute pipeline and need to copy a new image at the beginning of the queue, generate mip map levels for that image, process it through a shader, then copy the image buffer back to the host. The program worked prior to adding the mipmap generation steps, but adding the blit_image steps for mipmap generation causes the proceeding shader dispatch command to fail. (AccessError { error: AlreadyInUse, command_name: "vkCmdBindDescriptorSets", command_param: "Image bound to descriptor 0 of set 0", command_offset: 9 }')

    The execution is as follows:

    1. write image to buffer (host side)
    2. copy buffer to image
    3. generate mip map levels
    4. dispatch shader <-- this fails
    5. copy image to buffer
    6. read buffer (host side)

    It seems like this could be caused by a pipeline barrier issue, but vulkano appears to abstract those away. Any hints on how I should proceed? I can post code if that would help.

    Braden McDorman
    @bmcdorman
    I decided to use UnsafeCommandBufferBuilder directly so I could insert my own pipeline barriers. That appears to be working
    Ilya Lakhin
    @Eliah-Lakhin
    @bmcdorman Please post your question in the Issues section. Thank you.
    Faule Socke
    @faulesocke
    does anyone have ideas for security related research in vulkano?
    Eragon
    @Eragonfr
    Hello does anyone have a project template for Vulkano ? With multiples files, and comments, wish an example like the buffer-pool example or any other example.
    Hugh Sipière
    @hgsipiere
    Just a curiosity, is it possible to compile shaders before running a Vulkano program? By this I don't mean compiling GLSL to the SPIR-V intermediate format but the real binary representation for the GPU.
    I don't have any need to whatsoever, I'm just curious so no worries if you aren't sure.
    dzil123
    @dzil123:fairydust.space
    [m]
    The Vulkan spec says that the shader code you provide to the api is always SPIR-V https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VkShaderModule.html
    Faule Socke
    @faulesocke
    @hgsipiere you could experiment with pipeline caches
    kity
    @kity:kity.wtf
    [m]
    hey, i'm trying to base a new project off of the triangle example, but when i do pipeline.layout().descriptor_set_layout(0).unwrap() it panics
    my understanding is that the pipeline layout should have a set 0, since it's inferred from my fragment shader which contains a layout(set = 0, binding = 0) uniform usampler3D
    i'm not very familiar with vulkan though, and certainly not this library... anyone know what might be wrong?
    kity
    @kity:kity.wtf
    [m]
    WOW
    so after hours of debugging, i figure out that because i'm not using the uniform, i guess through the ~magic~ vulkano does to infer the pipeline layout, it can't tell that the uniform exists because it's effectively optimized out
    referencing the uniform in my shader makes it work
    antonino
    @pac85_gitlab
    I could find no way of waiting for an eventi and opened an issue
    Jay Leimer
    @CodingJinxx
    Is the vulkano guide out of date?
    solater
    @solater:i-c-quiche.com
    [m]
    I am attempting to integrate vkGetSemaphoreFdKHR into vulkano, which necessitates the device extension VK_KHR_external_semaphore_fd. When I try to call that function, I get the FeatureNotPresent error. I believe no features should be needed to call this function. However, I am not too familiar with the Vulkan documentation. Could someone help me confirm that using this vulkan function requires no extra feature to be enabled?
    solater
    @solater:i-c-quiche.com
    [m]
    Fixed it, I forgot that I needed to create the semaphore with the additional structure for export
    echo!
    @dotqurter
    Question: I've been trying to make a project that can use as many queues and such that are available for various tasks, but I haven't got it to work. How would I access the queues in the other families to do things?
    Greg Henry
    @GregoireHENRY
    Hello, I had to change a bit the examples of the guide (like mandlebrot) to make them work (after having read issue #1527).
    Do you want me to raise an issue with the codes updated or create a pull request?
    antonino
    @pac85_gitlab
    @Eliah-Lakhin hi. Regarding that thing about events. The api shares a lot with a barriers except that aside from specifying barriers you also specify ecents. Now instead of Copy and pasting UnsafeCommandBufferBuilderPipelineBarrier(or using macros ti do so)and adding methods to enable to add events I was thinking that I could have a different Struct just for events and when issuing a wait event command one could pass an instance of the new struct and an instance of UnsafeCommandBufferBuilderPipelineBarrier. The implementation would be neater but the api kind of breaks the pattern followed by the rest of vulkano. Which one do you think is best?
    Ilya Lakhin
    @Eliah-Lakhin
    @pac85_gitlab Hi Antonino! Sorry, I can't read the chat regularly. Would you mind raising this topic in Github Issues, please? https://github.com/vulkano-rs/vulkano/issues
    Roy Wellington Ⅳ
    @thanatos

    I am having a super hard time figuring out how to take pixel data from the CPU, put it into a Vulkan image, and then blit that onto the screen. I'm trying to use a ImmutableImage, but that seems pretty hard-wired to be used later in a shader, not in blits. (Which… makes sense, as a first use-case.)

    I think I almost have it. Things compile & run, but I get memory garbage on the screen where the blit should be.

    I captured it in RenderDoc, and there, the blit is "Undefined" repeated.

    It seems like I'm hitting this passage in the Vulkan spec:

    When performing a layout transition on an image subresource, the old layout value must either equal the current layout of the image subresource (at the time the transition executes), or else be VK_IMAGE_LAYOUT_UNDEFINED (implying that the contents of the image subresource need not be preserved). The new layout used in a transition must not be VK_IMAGE_LAYOUT_UNDEFINED or VK_IMAGE_LAYOUT_PREINITIALIZED.

    On the color pass, there is a VkImageMemoryBarrier for it in RenderDoc, but the oldLayout on it is VK_IMAGE_LAYOUT_UNDEFINED, which, as I understand it, would discard the image data. (And thus, "memory garbage" makes sense as the result.)

    It seems like vulkano should be setting this up to be a transition from whatever the current layout of the image is (which I think should be VK_IMAGE_LAYOUT_TRANSFER_DST_OPTIMAL from when we uploaded data from the CpuAccessibleBuffer into the image). But, it isn't, hence garbage. That's where I've gotten stuck.

    One thing I noticed was https://docs.rs/vulkano/0.21.0/src/vulkano/image/immutable.rs.html#89 : SubImage::new seems to ignore layout, and always stores ImageLayout::ShaderReadOnlyOptimal, which doesn't seem right.

    Roy Wellington Ⅳ
    @thanatos
    Upgrading to 0.24.0 to try to fix the above, but now vulkano uses ash. ash seems to think Vulkan handles are u64, but sdl2 thinks they're usize. sdl2 seems to have it right, too. (They're opaque pointers.)
    🤔 actually, even vulkano itself, through vulkano::Handle thinks handles are u64
    Roy Wellington Ⅳ
    @thanatos

    Oooh, now I get errors though, instead of rendered garbage.
    Sometimes:

    thread 'main' panicked at 'then_execute failed: AccessError { error: UnexpectedImageLayout { allowed: TransferSrcOptimal, requested: PresentSrc }, command_name: "vkCmdBlitImage", command_param: "source", command_offset: 11 }', src/main.rs:531:10

    In ImmutableImage::try_gpu_lock
    Sometimes,

    thread 'main' panicked at 'then_execute failed: AccessError { error: UnexpectedImageLayout { allowed: PresentSrc, requested: TransferSrcOptimal }, command_name: "vkCmdBeginRenderPass", command_param: "attachment 0", command_offset: 0 }', src/main.rs:531:10

    But from somewhere else that I don't know about. Probably the SwapchainImage.
    And sometimes it runs but renders garbage like before…

    …but "PresentSrc" being requested on the ImmutableImage sounds 9001% wrong? It's not the swapchain image? But I'm not trying to present it, I'm trying to blit from it, to the swapchain image?
    But also… why are we requesting TransferSrcOptimal on the swapchain… that also sounds wrong. It should be TransferDestOptimal, maybe…?

    Zachary Murray ₿⚡️
    @Rudefire_twitter

    i'm trying to do the compute tutorial on vulkano.rs.

    Having a hard time creating layout, as use vulkano::descriptor::PipelineLayoutAbstract; no longer seems to be in the source. Am I missing something?

    Zachary Murray ₿⚡️
    @Rudefire_twitter
    nevermind, I found it. If you want to do this, call use vulkano::pipeline::ComputePipelineAbstract
    aleksander-mendoza
    @aleksander-mendoza
    Hi, does anybody know how to reuse command buffers in vulkano? I saw this example https://github.com/bwasty/vulkan-tutorial-rs/blob/f2f6935914bec4e79937b8cac415683c9fbadcb1/src/bin/15_hello_triangle.rs#L523 but it uses very old version of vulkano. In the newest version cloning PrimaryAutoCommandBuffer is not implemented. So how should this be achieved now?
    Roy Wellington Ⅳ
    @thanatos

    I am new to this library too, but this chat room is too quiet, and I think I can answer your question.

    If you're doing something like <future>.then_execute(queue, cb), the second argument there should allow you to pass an Arc.
    Specifically, it takes: https://docs.rs/vulkano/0.24.0/vulkano/command_buffer/trait.PrimaryCommandBuffer.html#impl-PrimaryCommandBuffer-1 (and more specifically, that impl should allow an Arc.)

    I think when you call, e.g., AutoCommandBufferBuild::primary, you'll also need to supply an appropriate usage there.

    Roy Wellington Ⅳ
    @thanatos
    I think I've finally narrowed my ImmutableImage crash down. When the command buffer is finalizing self.resources, the resulting final_resources_states depends on the order of self.resources. Since self.resources is a hash map, this smells like a bug, and the key in both the original map and the final map has custom PartialEq and Hash impls.
    I guess I need to see if I can MVCE it.
    Will Song
    @incertia
    what is the rusty way of storing futures for later use? right now i just wait on the FenceSignalFuture right after submitting a command buffer, presenting, and flushing, but what if i want to do some extra work on the cpu in the meantime? the goal is to either return it out of a function or store it in a struct but throwing around FenceSignalFuture<PresentFuture<...>>s doesn't seem like the correct approach
    Kirill Dubovikov
    @kdubovikov
    Hi. I wonder if those kinds of signatures are ok, or I can simplify them somehow?
    fn create_descriptor_sets(
            pool: &Arc<Mutex<FixedSizeDescriptorSetsPool<Arc<GraphicsPipelineAbstract + Send + Sync>>>>,
            uniform_buffers: &[Arc<CpuAccessibleBuffer<UniformBufferObject>>],
        ) -> Vec<Arc<FixedSizeDescriptorSet<Arc<GraphicsPipelineAbstract + Send + Sync>, ((), vulkano::descriptor::descriptor_set::PersistentDescriptorSetBuf<std::sync::Arc<vulkano::buffer::CpuAccessibleBuffer<UniformBufferObject>>>)>>>
        {
            uniform_buffers
                .iter()
                .map(|uniform_buffer|
                    Arc::new(
                        pool
                            .lock()
                            .unwrap()
                            .next()
                            .add_buffer(uniform_buffer.clone())
                            .unwrap()
                            .build()
                            .unwrap()
                    )
                )
                .collect()
        }
    Georg Schäfer
    @georg.peter.schaefer_gitlab
    I'm currently trying to get into vulkans ray tracing extension, but I couldn't find any of the types provided by the extensions in vulkano-rs. Is there currently no support for ray tracing in vulkano?
    Java
    @java:furry.lol
    [m]

    hi, im trying to follow the outdated guide on vulkano.rs
    and i made it to to the mandelbrot set compute shader, but when i try call add_image on my PersistentDescriptorSetBuilder i get this compilation error:

    error[E0277]: the trait bound `vulkano::image::StorageImage: SafeDeref` is not satisfied
       --> src/main.rs:111:82
        |
    111 |     let set = Arc::new(PersistentDescriptorSet::start(layout.clone())).add_image(image.clone()).unwrap().build().unwrap();
        |                                                                                  ^^^^^^^^^^^^^ the trait `SafeDeref` is not implemented for `vulkano::image::StorageImage`
        |
        = note: required because of the requirements on the impl of `ImageViewAbstract` for `vulkano::image::StorageImage`
        = note: 1 redundant requirements hidden
        = note: required because of the requirements on the impl of `ImageViewAbstract` for `Arc<vulkano::image::StorageImage>`

    i am creating the image like this:

    let image = StorageImage::new(
        device.clone(),
        ImageDimensions::Dim2d {
            width: 1024,
            height: 1024,
            array_layers: 1,
        },
        Format::R8G8B8A8Unorm,
        [queue.family()],
    )
    .unwrap();
    Java
    @java:furry.lol
    [m]
    SafeDeref should be present
    Roy Wellington Ⅳ
    @thanatos

    SafeDeref should be present

    I think it's not that it's not SafeDeref per se (I would guess you're saying that since it's an Arc, the Arc is SafeDeref — and I'd agree), but that there is also a requirement on ImageViewAbstract that T::Target be ImageViewAbstract.

    That is, T (== Arc<StorageImage> must be SafeDeref. You've got that.
    T::Target (== StorageImage must be ImageViewAbstract, which it is not)

    nivpgir
    @nivpgir:matrix.org
    [m]
    hey
    I really want to use rust on android (trying to make imgui-rs work), and so far the best option I found is using vulkano
    I was able to fix this compilation error: vulkano-rs/vulkano#1417
    using these changes:
    I used cargo-apk to build the apk, and run the triangle example, and it runs, then immediately crashes.