Please provide a minimal reproduction of your issue in a repo when asking for help on a specific problem.
ImmutableImage::uninitialized constructor that will return you two things: the final read-only immutable image(not initialized yet), and the Initializer image ready for writing in. Then you can submit as many mipmap transfer submissions commands for Initializer. Once all submission commands executed you get ready to use ImmutableImage(the first parameter of the uninitialized call)
@pac85_gitlab One way to do this is using
ImmutableImage::uninitializedconstructor that will return you two things: the final read-only immutable image(not initialized yet), and the Initializer image ready for writing in. Then you can submit as many mipmap transfer submissions commands for Initializer. Once all submission commands executed you get ready to use ImmutableImage(the first parameter of theuninitializedcall)
yep that is what from_buffer and from_iterator do
with_mipmaps constructor 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
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)