Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    VimHax
    @VimHax
    How can I make it so that the triangle, in the triangle example, won't stretch when the size of the window is changed?
    VimHax
    @VimHax
    Nevermind, it has to do with aspect ratios and I think what I need to do is to transform the points correctly based on the ratio of width to height and then draw them.
    Cosmic Chip Socket
    @cosmicchipsocket
    You'll want to compute a new transform matrix when you handle window resizing, and use that as the basis for further transforms, and then pass that into your vertex shader
    antonino
    @pac85_gitlab
    Why is attachmentImage sharing mode hardcoded to exclusive?
    carado
    @carado
    hi;
    https://github.com/vulkano-rs/vulkano/blob/master/vulkano/src/pipeline/vertex/vertex.rs
    based on this, it seems like not only is vertex correspondence only checked by size, but this logic can't actually account for vertex conversion ? (like [i8; 3] → ivec3)
    Eliah Lakhin
    @eliah_lakhin_twitter
    @pac85_gitlab Are there any advantages in using Concurrent sharing?
    LastExceed
    @LastExceed
    hello, im following the guide. the moment i add vulkano-shaders to my cargo.toml i get this compile error: https://hastebin.com/quniwuyicu . any ideas?
    Ella-0
    @Ella-0
    Yea, to build shaderc you need to have cmake installed and that log doesn't look like you have.
    LastExceed
    @LastExceed
    i realized it was not in my PATH. i added it, then it asked to python, so i installed that, and now its asking for yet another thing. isn't the whole point of cargo to not have to do all this manually ?
    LastExceed
    @LastExceed

    anyway, the new error is

    no valid generator found for GNU toolchain; MSYS or MinGW must be installed

    so i googled those things (i dont even know what they are) and honestly im completely lost

    Ella-0
    @Ella-0
    It's looking for a c compiler
    LastExceed
    @LastExceed

    after several hours of troubleshooting various compile errors i switched to linux where everything just worked immediately.

    new problem: i'm getting this runtime error:

    Device extension "khr_storage_buffer_storage_class" required

    when running the compute example from the guide. what do ?

    Eric Trombly
    @etrombly
    // Now initializing the device.
    let (device, mut queues) = Device::new(
    physical,
    physical.supported_features(),
    &DeviceExtensions {
    khr_storage_buffer_storage_class: true,
    ..DeviceExtensions::none()
    },
    [(queue_family, 0.5)].iter().cloned(),
    )
    .unwrap();
    I'm assuming you're doing a compute shader, since you're using a storage buffer
    LastExceed
    @LastExceed
    that worked, thanks. so i guess the guide is outdated ?
    Eric Trombly
    @etrombly
    probably, I just used that example when I was starting out
    Faule Socke
    @faulesocke
    is loading shaders at runtime already implemented?
    Faule Socke
    @faulesocke
    I started implementing it a year ago and before I continue I wanted to make sure nobody else has already done it ;)
    Eliah Lakhin
    @eliah_lakhin_twitter
    @faulesocke If I not mistaken the only existing way of loading shaders in runtime is through unsafe code atm: https://github.com/vulkano-rs/vulkano/blob/master/examples/src/bin/runtime-shader/main.rs
    Kyle Rosenberg
    @OrangeDrangon

    Hey I was wondering how to construct a type for a pipeline object I was storing on a struct? Is there an example of this somewhere I can study? I am currently using
    pipeline: Arc<dyn GraphicsPipelineAbstract + Send + Sync>,

    This looses the type of the vertex it was constructed with when stored to the struct causing errors when I go to pass in my vertex buffer to a draw call. If someone could point me in the right direction that would be awesome.

    Thanks

    Kyle Rosenberg
    @OrangeDrangon
    I currently solved it with
    vec![Arc::new(vertex_buffer)],
    when passing the buffer into the draw call
    Cosmic Chip Socket
    @cosmicchipsocket
    Has there been any progress on any easily embeddable runtime-compiled shaders that can be used in both glium and vulkano? I'd like to be able to convert GLSL to SPIR-V as it's loaded (the GLSL files are data files included in a .zip file, loaded at runtime because this is a game engine and it's more flexible this way). But shaderc is absolutely massive (500 MiB apparently for a build), and I don't currently see any up-to-date projects to get glslang embedded, or any pure Rust implementations? There's the "glsl" crate but I don't think this goes all the way to SPIR-V yet. Surely there's a better way?
    The filesize of the transpiler needs to be small (more than 1 megabyte won't cut it). I'm still trying to understand how something like shaderc would even take up 500MiB
    Cosmic Chip Socket
    @cosmicchipsocket
    If I have to pre-compile the SPIR-V, then so be it, but I'd need to know what safety checks need to be done, and how, because this is data it's loading at runtime, and I want to not have to just blindly trust the data
    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