Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Dylan Blanchard
    @Tskken
    what do you mean but install it? i followed the directions on the readme so if there is something else other then adding the export's to your .bash_profile then ya i didn't do it. is there some other thing you have to do for installing the sdks that is not in the readme that you have to do?
    im running the examples off of a git clone of the master branch of vulkano
    Dylan Blanchard
    @Tskken
    so given what you said i tried running the vulkan_sdk install_vulkan.py file and i get this error
    Traceback (most recent call last):
      File "./install_vulkan.py", line 142, in <module>
        main()
      File "./install_vulkan.py", line 131, in main
        os.symlink(absolute_copy_files[key]["Link"], os.path.join(absolute_copy_files[key]["Dest"], os.path.basename(key)))
    OSError: [Errno 17] File exists
    not sure if thats what you ment by installing but that doesnt seem to work ether
    Dylan Blanchard
    @Tskken
    nvm i got it i had to go through and remove some old moltinvk installs aparently because the install_vulkan.py doesnt work if a file with the name it is trying to create already exists
    somehow when i tried to do this before i guess the setup got broken and was breaking everything else annoyingly
    wizzard
    @simdimdim
    gratz. On a different topic, does anyone have or happen to know where I can find a simple example of feeding the output of a compute pipeline? I'm pretty confident it should be very doable to just chain the operations, but end up having formats mismatch
    wizzard
    @simdimdim
    nvm, got it working ( yet to figure out how tho xD)
    Austin Johnson
    @AustinJ235
    @wizzard
    There is an open issue about dropping type checking on the buffers. I think there could be some work around formats to make them friendly to use but also just an unsafe function to type cast into anything with having to transmute the buffer tyoe to get around the type checking
    Would like to know how your experience has been and your thoughts on the current interface for this. I know I have had issues with it in the past.
    Killian
    @KillianDS
    I'm using vulkan_shaders with external files instead of inlining the shaders. However, I have now run into the problem that cargo doesn't detect a shader file change as a reason to recompile. I couldn't find something (easily), but is there a way to make rustc (or cargo) aware to rebuild a crate if only a shader changed, or do I always have to clean the crate manually first?
    wizzard
    @simdimdim

    @KillianDS

    mod fs {
        vulkano_shaders::shader! {ty: "fragment", path:"shaders/frag.glsl"}
    }
    // Used to force recompilation of shader change
    #[allow(dead_code)]
    const SHADER1: &str = include_str!("../shaders/frag.glsl");

    how to force check file changes

    wizzard
    @simdimdim
    @AustinJ235 for the time being I just ended up creating a new buffer from the old one, I'm neither a great dev (yet), nor do I have much experience with the library itself, I was planning to looking for how other people have done that, and would definitely check your repo(s) since apparently you've already dealt with the issue before :) given the choice instead of dropping it altogether I rather have an alternative to the default behavior, or a way to disable it on demand. Maybe it would be nice to have safe casting between compatible types, but no idea how that can work out. as for your last question, I don't think I have even seen the current interface on how to do it the normal/expected/supposed to way, but would be very thankful for an example of how other people have done that if you happen to have one :)
    Killian
    @KillianDS
    Thanks, I didn't think of doing a dead code workaround with the include macros. It will not work everywhere because of the path lookup differences, but is good enough for the time being.
    Nils Martel
    @sombrastudios

    Hi, I ran into a little problem, while following the guide on Vulkano.rs

    Ive got this code:

    use vulkano::instance::{Instance, InstanceExtensions, PhysicalDevice};
    
    fn main() {
        let instance = Instance::new(None, &InstanceExtensions::none(), None).expect("no instance");
    
        let devices = PhysicalDevice::enumerate(&instance).collect::<Vec<_>>();
        dbg!(&devices);
    
        for family in devices.queue_families() {
            println!(
                "Found a queue family with {:?} queue(s)",
                family.queues_count()
            );
        }
    }

    Now, there's an error message popping up, because the method queue_families can't be found. Does anyone know, how to import it?

    Killian
    @KillianDS
    You are reading queue_families on a Vec, you should read it on an element of the Vec.
    Nils Martel
    @sombrastudios
    Geez luise, thank you!
    That was insanely fast help and perfectly the right one :)
    alex5nader
    @alex5nader
    I'm not sure what's going wrong with my code. I'm doing the example compute operations from here: https://github.com/vulkano-rs/vulkano-www/blob/master/examples/guide-compute-operations.rs and every time I run, the assertions fail. I've tried printing everything in the buffer, and it turns out it is never being modified by the shader. I did have to lower the size of the buffer to 16384 because my graphics card's uniform buffer size limit is 65536, so it can only handle a size of 16384.
    I also had to enable the khr_storage_buffer_storage_class device extension, as originally it was panicking telling me to enable it.
    wizzard
    @simdimdim
    @alex5nader look at the compute example in latest git commit of the repo (and possibly switch your project to build from git too, there were some changes in SBO due to spriv(?) version bump
    alex5nader
    @alex5nader
    would that be the example here: https://github.com/vulkano-rs/vulkano/blob/master/examples/src/bin/basic-compute-shader.rs?
    alex5nader
    @alex5nader
    Using the example I linked, the same error occurs (buffer data is unchanged).
    wizzard
    @simdimdim

    did you

    vulkano={git="https://github.com/simdimdim/vulkano"}
    vulkano-win={git="https://github.com/simdimdim/vulkano"}
    vulkano-shaders={git="https://github.com/simdimdim/vulkano"}
    vk-sys ={git = "https://github.com/simdimdim/vulkano", branch = "master" }

    ? cuz I had the same issue and that fixed it entirely

    alex5nader
    @alex5nader
    ahhh
    I had only changed vulkano to use master, not the other crates
    thanks a bunch!
    wizzard
    @simdimdim
    np
    Austin Johnson
    @AustinJ235
    yes the spirv deprecated the old ext so that one is needed now
    wizzard
    @simdimdim
    how do you guys collect the result of a compute shader/pipeline and pass them on to a vertex shader?
    wizzard
    @simdimdim
    Cant seem to find a single implementation online
    stevenkucera
    @stevenkucera
    Hi Thanks for Vulkano, I tried the Triangle example, and it works but is choppy (5-6 fps) on my Linux Mint 19, both moving and resizing the window. I commented out the swapchain recreation code, and get a nice 60fps for moving the window and about 30 fps for resizing on my nVidia card. How to get a smooth framerate, or is it even possible? One way I thought is to keep around a large size framebuffer, and simply scale it down when the user resizes down. Is there any other way without wasting GPU memory?
    stevenkucera
    @stevenkucera
    I managed to fix this by changing PresentMode from "Fifo" to "Immediate", however, surely likely to be tearing?
    wizzard
    @simdimdim
    @stevenkucera what drivers and loader you got? such low fps on such trivial example is really not normal
    Austin Johnson
    @AustinJ235
    wonder it is something in the example or not. Have you tried a different compositor? If you like you could run the basalt example. I have had an nvidia gpu in the past without issues.
    https://github.com/AustinJ235/basalt is my personal project
    varomix
    @varomix
    Hello, can anyone tell me how to choose my second GPU, is trying to run on my intel gpu on my laptop, I want it to run on my Nvidia GPU
    thanks
    Killian
    @KillianDS
    when you enumerate the devices don't just pick the first one but find the one where type (call ty()) is PhysicalDeviceType::DiscreteGpu. Or more specifically select it by name.
    varomix
    @varomix
    hi, so I manage to run it on my nvidia gpu, but now my computer get super laggy, can't even move the mouse 1 core is always at 100% and I'm just running the triangle example
    Oh I just read that @stevenkucera changed the PresentMode, ok that work, but why does a simple triangle requires 1 CPU core to be always at 100% and GPU at 98% ?seems too much for me
    Eliah Lakhin
    @eliah_lakhin_twitter
    @varomix This is happening, perhaps, because you are continuously polling window events in a loop: https://github.com/vulkano-rs/vulkano/blob/master/examples/src/bin/triangle.rs#L443 So, the CPU core is actually overloaded by winit, not by Vulkano. Alternatively you can use https://docs.rs/winit/0.18.0/winit/struct.EventsLoop.html#method.run_forever method that wakes up the thread only when the user interacts with the window, but in this case frame rate will also depend on the user interaction. To bypass this issue you can put rendering in a separate OS thread and/or use EventsLoopProxy to synchronize rendering thread and user interaction(winit window) thread
    varomix
    @varomix
    I compiled the LunarG C++ example vkCube and I can have that running and there's minimal to no CPU usage and the GPU is at most 3% and I'm not even sure that's because of the example
    @eliah_lakhin_twitter what about the 98% GPU usage? is that because of winit as well?
    Eliah Lakhin
    @eliah_lakhin_twitter
    @varomix I think GPU is also overloaded because the loop forces continuous rendering(i.e. there are much more than the normal 60 FPS). I faced the same issue when I started learning Vulkano first time. Triangle and other examples are just toy examples that demonstrate the base concepts of the API, and are not optimized at all. Moving things to separate threads accurately and limiting a number of frame rates(for example with timeouts) are fixing these issues.
    varomix
    @varomix
    actually, this makes me NOT want to use it further, why would that be the first thing someone will run? at least mention this, so people is are aware of this and provide an optimized version maybe :D
    is there any example that does this?
    Eliah Lakhin
    @eliah_lakhin_twitter
    @varomix I understand your frustration very well :) Vulkano's current example set is definitely a subject for improvement. But personally I like the library because the API itself is not so bad(at least comparing to other Rust alternatives), and it is also quite thoughtful alignment of Vulkan's native API to Rust ecosystem. Talking about more advanced examples I would recommend to take a look at @AustinJ235 's project: https://github.com/AustinJ235/basalt/blob/master/src/window/winit.rs Here is something close to what I described above.
    Eliah Lakhin
    @eliah_lakhin_twitter
    Generally speaking, Vulkan itself is a low-level API that requires more efforts from the developer to set things up in the beginning. No matter what wrapper you use. Talking about Vulkano specifically it actually already hides a lot of boilerplate stuff inside, but yet it doesn't hide/alter actual Vulkan workflow. So it's not too difficult to understand what it does by reading original Vulkan documentation/tutorials and C++ examples too. Some other Rust alternatives are hiding much more, so when something goes wrong it might be difficult to understand what's going on. In other words Vulkano doesn't hide Vulkan's internals too much, it just makes it safe in the Rust ecosystem.