Please provide a minimal reproduction of your issue in a repo when asking for help on a specific problem.
Result::unwrap()
on an Err
value: SyncCommandBufferBuilderError(Conflict { command1_name: "vkCmdBindDescriptorSets", command1_param: "Image bound to descriptor 1 of set 0", command1_offset: 3, command2_name: "vkCmdBindDescriptorSets", command2_param: "Image bound to descriptor 1 of set 0", command2_offset: 8 })', /mnt/void/home/archdata/cose/GameKernel/src/game_kernel/subsystems/video/renderer/mod.rs:1470:22
@pac85_gitlab The error message is also showing something strange. It's saying there is something with descriptor 1 of set 0. I suppose it should complain about descriptor No 3, but anyway there is something with descriptors and layouts. The set's layout itself described here: https://gitlab.com/pac85/GameKernel/-/blob/master/data/engine/shaders/third_pbr/frag.glsl#L10 First thing that seem to be mistaken here is numeration of bindings. The bindings should start with Zero, not with One. The might be a cause of a strange numeration in the error.
Most likely what really happened is that first time you run the frame you read an image from iterator here: https://gitlab.com/pac85/GameKernel/-/blob/master/src/game_kernel/subsystems/video/renderer/mod.rs#L1429 So, the entire number of entries was 3(as required by the shader's layout) and Vulkan/Vulkano somehow resolved it. The second time you run this code the iterator(or a source of the iterator) was already exceeded/emptied so the descriptor set was described with 2 entries only, which contradicts shader's layout.
The resolution is you need to somehow pass a sampler attachment in both cases of that condition. Even if you don't have an image you need to put a dummy image(like 1x1 pixel) to fill the gap in the layout, or use different shader with the different layout. Also, if you want to change "albedo" texture sampler often and don't want to touch "diffuse" and "specular" as often as "albedo", you can split descriptor set into two independent sets, and describe them independently too caching the first set(with diffuse and specular). It would be more efficient than recreating descriptor sets every frame which is expensive operation per se.
path
.
@pac85_gitlab The error message is also showing something strange. It's saying there is something with descriptor 1 of set 0. I suppose it should complain about descriptor No 3, but anyway there is something with descriptors and layouts. The set's layout itself described here: https://gitlab.com/pac85/GameKernel/-/blob/master/data/engine/shaders/third_pbr/frag.glsl#L10 First thing that seem to be mistaken here is numeration of bindings. The bindings should start with Zero, not with One. The might be a cause of a strange numeration in the error.
Most likely what really happened is that first time you run the frame you read an image from iterator here: https://gitlab.com/pac85/GameKernel/-/blob/master/src/game_kernel/subsystems/video/renderer/mod.rs#L1429 So, the entire number of entries was 3(as required by the shader's layout) and Vulkan/Vulkano somehow resolved it. The second time you run this code the iterator(or a source of the iterator) was already exceeded/emptied so the descriptor set was described with 2 entries only, which contradicts shader's layout.
The resolution is you need to somehow pass a sampler attachment in both cases of that condition. Even if you don't have an image you need to put a dummy image(like 1x1 pixel) to fill the gap in the layout, or use different shader with the different layout. Also, if you want to change "albedo" texture sampler often and don't want to touch "diffuse" and "specular" as often as "albedo", you can split descriptor set into two independent sets, and describe them independently too caching the first set(with diffuse and specular). It would be more efficient than recreating descriptor sets every frame which is expensive operation per se.
sorry i just saw this, the purpose of that condition was to allow materials that either have or haven't a texture, in my case it always evaluated true because I only had a material with a texture
assert_eq!
statement is failing. It doesn't seem like the buffer is properly being copied over, as the dest
buffer still contains zeroes after executing the command buffer.
RawDeviceExtensions
instead of DeviceExtensions
to intialise a device, anyone got examples of this?So I got everything working, but having a weird issue with the memory layout. Not sure what I'm doing wrong. If I run it with this general code:
#[derive(Default, Debug, Copy, Clone)]
pub struct PointVk {
pub position: [f32; 3],
}
#[derive(Default, Debug, Copy, Clone)]
pub struct LineVk {
pub p1: PointVk,
pub p2: PointVk,
}
#version 450
layout(local_size_x = 128, local_size_y = 1, local_size_z = 1) in;
struct Line {
vec3 p1;
vec3 p2;
};
layout(set = 0, binding = 0) buffer LineVk {
Line line[];
} lines;
void main() {
uint idx = gl_GlobalInvocationID.x;
lines.line[idx].p1 = vec3(1, 2, 3);
lines.line[idx].p2 = vec3(4, 5, 6);
}"
}
}
I get output like:
LineVk { p1: PointVk { position: [1.0, 2.0, 3.0,] }, p2: PointVk { position: [0.0, 4.0, 5.0,] } }
So it looks like it's outputting as a vec4, not vec3. If I change PointVk to [f32;4] and change everything to vec4 with a dummy value for the 4th element everything is aligned correctly. Any idea whats going on?
I'm trying to complete the guide on the vulkano website --- the windowed part that's incomplete.
I managed to figure out how to get vulkan to render to a winit window, but the performance is pretty poor on resizing. Is someone willing to take a look at my code and tell me what I'm doing wrong? :D
https://gist.github.com/AtheMathmo/3fed0665400fd6850cf0d144bb9b9070
I'm trying to put together a basic render pipeline but there's one thing (at least) that is still really tripping me up. I can't figure out how to handle my graphics pipelines. Sorry for message length.
I've looked through all the examples now and took a lot of inspiration from them (especially the deferred rendering one). But I want to be able to draw multiple meshes and I can't figure out how to organize the pipelines.
If I understand correctly, generally, each rendered mesh needs its own graphics pipeline as they may use different shaders. The pipeline may also need to be recreated if the window size changes. The teapot example says as much, but then uses .viewports_dynamic_scissors_irrelevant(1)
which I think implies a dynamic viewport?
@pac85_gitlab I think this function might be helpful: https://docs.rs/vulkano/0.19.0/vulkano/command_buffer/struct.AutoCommandBufferBuilder.html#method.copy_image_to_buffer_dimensions
that only allows me to copy one mip level as I said, that won't do beacuse after that I can't write to the image any more
I've noticed that commits suddently stoppeted on the 12th of June, is everything alright with the project?
@pac85_gitlab Well, I'm not a maintainer of the project, just an active user and a minor contributor. @AustinJ235 has disappeared, unfortunately. I didn't see any activity in his own projects too for the past time. Hopefully, he will get back, but in worst case I think we can ask Tomaka to assign another one maintainer, or maybe even do our own fork. But in this moment there are no urgent PR pendings or bugs to be fixed urgently. The codebase is quite stable.
vulkano::swapchain::acquire_next_image()
, my entire desktop freezes for a few seconds and then it errors with "no image is available for acquiring yet". Then I have to kill the process manually, which freezes my desktop for several seconds again, despite it being a panic. How should I go about troubleshooting this?