Please provide a minimal reproduction of your issue in a repo when asking for help on a specific problem.
if the mipmap data is there it should just work am I right?
If it was submitted properly with uninitialized constructor, then yes. At least I can confirm it works this way in my project
@pac85_gitlab Well, I'm not sure if
with_mipmapsconstructor was ever work since there is no way to submit actual mipmap images. If you improve the constructor even with signature breaking changes IMO it would be fine. But I'm not a maintainer, better to ask @AustinJ235 . Anyway even if he doesn't accept breaking changes you can rename it to the new constructor
also vulkano usually exposes two ways of uploading images, either using an iterator or using a buffer. Which one of those two should with_mipmaps take if we modify it's signature?
fn draw(
&mut self,
render_pass: Arc<dyn RenderPassAbstract + Send + Sync>,
dynamic_state: &mut DynamicState,
device: Arc<Device>,
queue: Arc<Queue>,
pipeline: Arc<dyn GraphicsPipelineAbstract + Send + Sync + 'static>,
vertex_buffer: Vec<Arc<CpuAccessibleBuffer<[Vertex]>>>,
) {
// draw code... its same as whats in the draw function in event.run
}expected trait object `dyn vulkano::buffer::traits::BufferAccess`, found struct `vulkano::buffer::cpu_access::CpuAccessibleBuffer`
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.
- Posting questions here Vs as issues on the repo, which is preffered?
- I've got a bit stuck trying to pass
RawDeviceExtensionsinstead ofDeviceExtensionsto intialise a device, anyone got examples of this? - Has anyone used many GLSL extensions with Vulkano? Does Vulkano handle these or are they simply handled by the underlying shaderc? (pretty much if I've got an issue with one, where do I need to start working to fix it)
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