by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    jdnewman85
    @jdnewman85
    @the10thWiz Hmm... sometimes it'll run for half a second, sometimes for thousands of frames
    I would have thought that either of these lines would have caused the GPU to wait for everything to be ready again, given vulkano's design:
    self.previous_frame_end[image_index].as_mut().unwrap().cleanup_finished();
    let prev = self.previous_frame_end[image_index].take().unwrap();
    jdnewman85
    @jdnewman85
    I guess the second doesn't since the value lives on as prev
    jdnewman85
    @jdnewman85
    @the10thWiz Actually, it makes sense. The only way to know that your command buffer has been released from the GPU is by waiting on the previous submit. You have to either use a new command buffer, or explicitly wait on the previous frame finishing. Put a 'future.wait(None).unwrap();' in there somewhere. Like:
    match future {
        Ok(future) => {
             future.wait(None).unwrap();
             self.previous_frame_end[image_index] = Some(Box::new(future) as Box<_>);
        }
    Matthew Pomes
    @the10thWiz
    After reading into the vulkano implementation, it would appear that the command_buffer is protecting itself from getting executed in parallel. I think I also just figured out the other issue I was having. Basically, after the previous_frame_end future was created, every frame would call then_exec, present, and then fence_and_flush. The GPU future that results from this can contain the GPU futures from many previous frames. If enough frames are submitted to the GPU before it releases a command buffer, the vulkano implementation will deadlock attempting to check buffer access for the command buffers.
    Interestingly, you can avoid this issue by not waiting for the previous frame to end on the GPU or CPU side. You have to tell vulkano that the command buffers can be used in parallel, to disable to vulkano protections. As long as you wait for the image to be ready, it shouldn't be a problem.
    jdnewman85
    @jdnewman85
    @the10thWiz So were you able to get the parallel version to run without crashing? Was that related to the future accumulation? Interested
    Rather... non-wait version
    left_adjoint
    @leftadjoint
    PersistentDescriptorSet has the DescriptorSet trait for storing a trait object. Unfortunately, there appears to be no counterpart for PersistentDescriptorSetBuilder or PersistentDescriptorSetBuilderArray.
    Specifically, I need to add a sampler array where the number of samplers is not known at compile time. But since the type of the result changes with each added descriptor, I can't use fold or any typical methods. Any recommendations?
    jdnewman85
    @jdnewman85
    @leftadjoint PersistentDescriptorSetBuilder has 'addSampler()' which returns another PersistentDescriptorSetBuilder. Same type? Do you have an example?
    Wylie Кулик
    @kulicuu
    I'm working on a terrain server as a separate Rust process that would stay alive and keep loaded terrain in memory while my main development looped through a compilation.
    I was looking into shared memory on host, but research found that it's possible for distinct processes to access Vulkan device memory in a way that both can utilize the data.
    This led to the question of direct access to the Vulkan API. I'm not sure if I've asked this before or in this form or forum, but how does one go about direct Vulkan interfacing via/around/alongside of Vulkano ?
    I'm guessing Vk-Sys has most of it, but don't see any example usage or documentation on that one. I'm reading the source code, but slow going.
    Slow because it's introducing me to new parts of Rust, like the macro definitions syntax, that I need to go research.
    left_adjoint
    @leftadjoint
    @jdnewman85 PersistentDescriptorSetBuilder and PersistentDescriptorSetBuilderArray track the layout of the descriptor set in a type parameter, which means every time you add a descriptor, it changes the type.
    PersistentDescriptorSet implements the DescriptorSet trait, so you can store it in an Arc<dyn DescriptorSet>, but there seems to be no trait I can use for the builders.
    Here's an example that uses buffers instead of samplers, but the same issue applies.
        let set_a = 
            PersistentDescriptorSet::start(layout.clone())
                .enter_array()
                .unwrap();
    
        let buffers = vec![data.clone(),data.clone()];
    
        let set_b = buffers.iter().fold(set_a, |acc, x| {
            acc.add_buffer(x).unwrap()
        } );
    This results in a type error for the reasons I mentioned above:
    note: expected struct `vulkano::descriptor::descriptor_set::persistent::PersistentDescriptorSetBuilderArray<()>`
                  found struct `vulkano::descriptor::descriptor_set::persistent::PersistentDescriptorSetBuilderArray<((), vulkano::descriptor::descriptor_set::persistent::PersistentDescriptorSetBuf<&std::sync::Arc<vulkano::buffer::cpu_access::CpuAccessibleBuffer<[f32]>>>)>`
    left_adjoint
    @leftadjoint
    Thinking about this a little more, to make this work, the type of the builder would depend on the value of the vector , requiring dependent types :-/
    So I guess the solution has to be a custom descriptor set implementation
    jdnewman85
    @jdnewman85
    @leftadjoint Yeah... I'm rather new to Rust and Vulkan, so it's not saying much, but I believe you are correct. I would think that all libraries using strongly typed builder patterns would have this issue, and that someone would have written about it somewhere.
    We could write a run-time builder that uses trait objects behind the scenes, and trade the compile time safety for run-time checks and such?
    I know Vulkano's original design was to prevent incorrect usage and undefined behavior; but I wonder if that's really even possible, and if we're not shutting out a set of vulkan programs that need more options at run-time.
    left_adjoint
    @leftadjoint
    @jdnewman85 actually for me the issues goes even deeper as I need to use the GL_EXT_nonuniform_qualifier GLSL extension, and the vulkano-shaders code doesn't recognize; I tried adding the capability for it to the enum in vulkano-shaders, but it results in some instructions/decorators(?) used in the SPIRV that aren't presently supported. I thought about working on adding it, but that's more than I can really chew right now.
    I've gotten this to work through simply compiling the GLSL to SPIRV in a build script and loading the SPIRV at runtime without the static checks, and generating pipeline and descriptor layouts without the builders.
    left_adjoint
    @leftadjoint
    As a side-note, I thought that providing an explicit array length as a specialization constant should work. However, that failed. I'm not sure if the error emanated from the shaderc-rs compiler(indicating lack of support for this in GLSL) or from the parse code in vulkano-shaders. But even if it's allowed by GLSL and the problem is in vulkano-shaders, the solution is the same -- runtime loading of SPIRV.
    left_adjoint
    @leftadjoint
    @kulicuu I haven't done this explicitly, but I have poked around in vk-sys for a bit as I eventually want to use raytracing extensions. If you're looking for an extension that isn't covered by vk-sys already, you need to add the identifiers (structure types, etc) as well as add macros to generate the function bindings. If you look at vk-sys and the reference pages for the structures of interest you should get a decent idea.
    left_adjoint
    @leftadjoint
    As for calling the direct vulkan bindings alongside, the real issue appears to be getting the raw handles from vulkano structs -- the handles for your device, images, etc. For that, check out the VulkanObject, ImageInner and similar traits.
    Eva Wong
    @suddenly-eva
    Hi, I'm completely new to everything here and I'm running into an issue right away while following the basic setup guide.
    When I make a Vulkan instance it crashes out with an IncompatibleDriver error. However, it looks like I can run vulkaninfo and vulkan-smoketest in the commnad line so I have no idea what to look for to get the compatible drivers.
    Any help would be appreciated c:
    left_adjoint
    @leftadjoint
    @suddenly-eva I haven't encountered this before, but, checking out the comment for that particular error suggeststhat your vulkan implementation doesn't support the version of vulkan required by vulkano. Maybe try installing the vulkan sdk itself, and ensure the relevant envars point to that location. You'll need to make sure to use MoltenVK on MacOS.
    Matthew Pomes
    @the10thWiz
    Does Vulkan explicitly define behavior for Signalling two fences in a row? E.g.
    gpu_future.then_signal_fence().then_signal_fence()
    I am curious because this could be shortcircuited by Vulkano, so the second then_signal_fence() could always just return the previous fence. (I think? The then_signal_fence() type signature might need to change slightly)
    Maxim Baz
    @maximbaz

    Hello!

    I'm trying to import a DMA-BUF frame as an image in vulkano, would really appreciate some pointers - apologies if I mix up the terminology, I'm new to GPU programming :)

    The goal is to achieve zero copy to CPU, i.e. receive a pointer to the frame in GPU via dmabuf, import it into vulkano, run some processes in GPU and read-out only the final small result.

    In EGL, there is an extension EXT_image_dma_buf_import which allows to import DMA-BUF as an EGLImage using eglCreateImage() function:

    https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_image_dma_buf_import.txt

    In Vulkan, there is an extension VK_EXT_external_memory_dma_buf that is seemingly made for this same purpose.

    When searching for some details about this, I found this thread:

    https://bugs.freedesktop.org/show_bug.cgi?id=104865

    In particular:

    In the mean time, what you're trying to do is still possible, you just have to go about it differently. Instead of creating a linear VkImage on the DMABUF, create a VkBuffer and then use vkCmdCopyBufferToImage and provide the image stride using bufferRowLength.

    Assuming I must take the same route, how would I go about creating a VkBuffer out of DMA-BUF in vulkano? Do I have to use the UnsafeBuffer? Or could I use e.g. ImmutableBuffer? But how to initialize such buffers properly with the frame contents?

    I would truly appreciate any hints, suggestions or code examples!

    left_adjoint
    @leftadjoint
    @maximbaz The details of what you're talking about are a bit out of my depth, but as you referenced, this seems to require the extensions VK_EXT_external_memory_dma_buf and VK_KHR_external_memory_fd. The underling binding information (structure ids, etc), vulkano uses to call into vulkan are located here. Taking a quick look shows that required ids are missing.
    7 replies
    Wylie Кулик
    @kulicuu
    @leftadjoint Thx!!!
    Maxim Baz
    @maximbaz

    Hello again! :)

    How does one share vulkan buffers between different rust libraries? To give you a very specific example, I want to use an API from wayland-protocols, where I create a buffer, give it to wayland via API, wayland compositor fills the buffer with image data, and then I would use vulkano to post-process the image.

    Wayland protocols have their own struct for buffers WlBuffer, which can be created e.g. using WlShmPool::create_buffer(). An example of such an API would be ZwlrScreencopyFrameV1::copy().

    Ideally I would create a buffer using vulkano and feed it to wayland-protocols functions to be filled with data, but I don't mind doing the opposite, create WlBuffer struct, fill it and later reconstruct in vulkano - eventually I simply need an image created that I can work with.

    Thanks!

    1 reply
    matrixbot
    @matrixbot

    Levans Maxim Baz : there are actually several ways to create a Wayland buffer, as an SHM memory buffer (using WlShmPool), or using dmabuf, using the Linux-dmabuf extension from wayland-protocols.

    It's then up to you to integrate the dmabuf with Vulkan / Mesa.

    Clinery
    @Clinery1
    How do you send unsized data to a shader? I am using CpuBufferPool if that helps. I have already tried sending a Vec<T> but this results in the data being zero, I have tried sending an array, this works but is undesirable for my program, I need to be able to send an unknown amount of data per shader execution.
    7 replies
    Sam Blazes
    @Tenebryo_gitlab
    Is there a way to measure the time a command created in a AutoCommandBufferBuilder takes when it executes? I was looking at UnsafeCommandBufferBuilder::write_timestamp, but there doesn't seem to be an easy way to access this in a safe way.
    Taavet Maask
    @taavetmaask
    Hi, I followed the triangle and image examples on the github. Now that I finally got an image to the screen it's mutch darker than it should be. Image here - left side my vulkan window and right side the same image opened in visual studio code. Is there some sort of simple fix, something that I'm missing or is that more complicated? I'm just a beginner, trying to make some sense of vulkan. :)
    1 reply
    Hanif Ariffin
    @hbina
    someone mentioned that vulkano is a safe wrapper over Vulkan, does it handle the synchronization of VkMemoryPropertyFlagBits too?
    reading the spec and it sounds like something that can be solved by the type system
    Nate Kent
    @neachdainn
    Hey all. Is there a way to put the store op of single_pass_renderpass behind a variable?
    I have a few passes I would like to define that differ only by the store op
    Nate Kent
    @neachdainn
    Alternatively, is there a way to make a pass that is just depth and then a pass that uses the depth information from the previous pass?
    Nate Kent
    @neachdainn
    Got my answer on Discord.