Please provide a minimal reproduction of your issue in a repo when asking for help on a specific problem.
@Syntaxxor Hi Syntaxxor. Sorry, this chat is rarely maintaining. In the future you can raise questions and suggestions in the repo's Issues section. They are watching by me and the community more frequently.
Regarding your question. Currently examples is probably the main source of truth for new comers. Site's tutorial is a bit outdated, but it also could be a place to start learning. If you want to refresh the Tutorial, this is very welcome and will be very beneficial for the community! Anyway, please raise this topic in the Issues section first.
Hi, I'm having some trouble with a AccessError(AlreadyInUse) when executing a command buffer. I'm using a compute pipeline and need to copy a new image at the beginning of the queue, generate mip map levels for that image, process it through a shader, then copy the image buffer back to the host. The program worked prior to adding the mipmap generation steps, but adding the blit_image steps for mipmap generation causes the proceeding shader dispatch command to fail. (AccessError { error: AlreadyInUse, command_name: "vkCmdBindDescriptorSets", command_param: "Image bound to descriptor 0 of set 0", command_offset: 9 }')
The execution is as follows:
- write image to buffer (host side)
- copy buffer to image
- generate mip map levels
- dispatch shader <-- this fails
- copy image to buffer
- read buffer (host side)
It seems like this could be caused by a pipeline barrier issue, but vulkano appears to abstract those away. Any hints on how I should proceed? I can post code if that would help.
pipeline.layout().descriptor_set_layout(0).unwrap() it panics
layout(set = 0, binding = 0) uniform usampler3D
vkGetSemaphoreFdKHR into vulkano, which necessitates the device extension VK_KHR_external_semaphore_fd. When I try to call that function, I get the FeatureNotPresent error. I believe no features should be needed to call this function. However, I am not too familiar with the Vulkan documentation. Could someone help me confirm that using this vulkan function requires no extra feature to be enabled?
Do you want me to raise an issue with the codes updated or create a pull request?
I am having a super hard time figuring out how to take pixel data from the CPU, put it into a Vulkan image, and then blit that onto the screen. I'm trying to use a ImmutableImage, but that seems pretty hard-wired to be used later in a shader, not in blits. (Which… makes sense, as a first use-case.)
I think I almost have it. Things compile & run, but I get memory garbage on the screen where the blit should be.
I captured it in RenderDoc, and there, the blit is "Undefined" repeated.
It seems like I'm hitting this passage in the Vulkan spec:
When performing a layout transition on an image subresource, the old layout value must either equal the current layout of the image subresource (at the time the transition executes), or else be
VK_IMAGE_LAYOUT_UNDEFINED(implying that the contents of the image subresource need not be preserved). The new layout used in a transition must not beVK_IMAGE_LAYOUT_UNDEFINEDorVK_IMAGE_LAYOUT_PREINITIALIZED.
On the color pass, there is a VkImageMemoryBarrier for it in RenderDoc, but the oldLayout on it is VK_IMAGE_LAYOUT_UNDEFINED, which, as I understand it, would discard the image data. (And thus, "memory garbage" makes sense as the result.)
It seems like vulkano should be setting this up to be a transition from whatever the current layout of the image is (which I think should be VK_IMAGE_LAYOUT_TRANSFER_DST_OPTIMAL from when we uploaded data from the CpuAccessibleBuffer into the image). But, it isn't, hence garbage. That's where I've gotten stuck.
One thing I noticed was https://docs.rs/vulkano/0.21.0/src/vulkano/image/immutable.rs.html#89 : SubImage::new seems to ignore layout, and always stores ImageLayout::ShaderReadOnlyOptimal, which doesn't seem right.
vulkano itself, through vulkano::Handle thinks handles are u64 …
Oooh, now I get errors though, instead of rendered garbage.
Sometimes:
thread 'main' panicked at 'then_execute failed: AccessError { error: UnexpectedImageLayout { allowed: TransferSrcOptimal, requested: PresentSrc }, command_name: "vkCmdBlitImage", command_param: "source", command_offset: 11 }', src/main.rs:531:10In ImmutableImage::try_gpu_lock
Sometimes,
thread 'main' panicked at 'then_execute failed: AccessError { error: UnexpectedImageLayout { allowed: PresentSrc, requested: TransferSrcOptimal }, command_name: "vkCmdBeginRenderPass", command_param: "attachment 0", command_offset: 0 }', src/main.rs:531:10But from somewhere else that I don't know about. Probably the SwapchainImage.
And sometimes it runs but renders garbage like before…
…but "PresentSrc" being requested on the ImmutableImage sounds 9001% wrong? It's not the swapchain image? But I'm not trying to present it, I'm trying to blit from it, to the swapchain image?
But also… why are we requesting TransferSrcOptimal on the swapchain… that also sounds wrong. It should be TransferDestOptimal, maybe…?
I am new to this library too, but this chat room is too quiet, and I think I can answer your question.
If you're doing something like <future>.then_execute(queue, cb), the second argument there should allow you to pass an Arc.
Specifically, it takes: https://docs.rs/vulkano/0.24.0/vulkano/command_buffer/trait.PrimaryCommandBuffer.html#impl-PrimaryCommandBuffer-1 (and more specifically, that impl should allow an Arc.)
I think when you call, e.g., AutoCommandBufferBuild::primary, you'll also need to supply an appropriate usage there.
ImmutableImage crash down. When the command buffer is finalizing self.resources, the resulting final_resources_states depends on the order of self.resources. Since self.resources is a hash map, this smells like a bug, and the key in both the original map and the final map has custom PartialEq and Hash impls.I guess I need to see if I can MVCE it.
fn create_descriptor_sets(
pool: &Arc<Mutex<FixedSizeDescriptorSetsPool<Arc<GraphicsPipelineAbstract + Send + Sync>>>>,
uniform_buffers: &[Arc<CpuAccessibleBuffer<UniformBufferObject>>],
) -> Vec<Arc<FixedSizeDescriptorSet<Arc<GraphicsPipelineAbstract + Send + Sync>, ((), vulkano::descriptor::descriptor_set::PersistentDescriptorSetBuf<std::sync::Arc<vulkano::buffer::CpuAccessibleBuffer<UniformBufferObject>>>)>>>
{
uniform_buffers
.iter()
.map(|uniform_buffer|
Arc::new(
pool
.lock()
.unwrap()
.next()
.add_buffer(uniform_buffer.clone())
.unwrap()
.build()
.unwrap()
)
)
.collect()
}
hi, im trying to follow the outdated guide on vulkano.rs
and i made it to to the mandelbrot set compute shader, but when i try call add_image on my PersistentDescriptorSetBuilder i get this compilation error:
error[E0277]: the trait bound `vulkano::image::StorageImage: SafeDeref` is not satisfied
--> src/main.rs:111:82
|
111 | let set = Arc::new(PersistentDescriptorSet::start(layout.clone())).add_image(image.clone()).unwrap().build().unwrap();
| ^^^^^^^^^^^^^ the trait `SafeDeref` is not implemented for `vulkano::image::StorageImage`
|
= note: required because of the requirements on the impl of `ImageViewAbstract` for `vulkano::image::StorageImage`
= note: 1 redundant requirements hidden
= note: required because of the requirements on the impl of `ImageViewAbstract` for `Arc<vulkano::image::StorageImage>`i am creating the image like this:
let image = StorageImage::new(
device.clone(),
ImageDimensions::Dim2d {
width: 1024,
height: 1024,
array_layers: 1,
},
Format::R8G8B8A8Unorm,
[queue.family()],
)
.unwrap();SafeDeref should be present
I think it's not that it's not SafeDeref per se (I would guess you're saying that since it's an Arc, the Arc is SafeDeref — and I'd agree), but that there is also a requirement on ImageViewAbstract that T::Target be ImageViewAbstract.
That is, T (== Arc<StorageImage> must be SafeDeref. You've got that.T::Target (== StorageImage must be ImageViewAbstract, which it is not)
