Please provide a minimal reproduction of your issue in a repo when asking for help on a specific problem.
hi, i'm trying to port some code from an online tutorial to vulkano v0.19. the code looks like:
fn create_command_buffers(&mut self) {
let queue_family = self.graphics_queue.family();
self.command_buffers = self.swapchain_framebuffers.iter()
.map(|framebuffer| {
let vertices = BufferlessVertices { vertices: 3, instances: 1 };
Arc::new(AutoCommandBufferBuilder::primary_simultaneous_use(self.device.clone(), queue_family)
.expect("failed to initialise command buffer builder")
.begin_render_pass(framebuffer.clone(), false, vec![[0.0, 0.0, 1.0].into()])
.expect("failed to begin render pass")
.draw(self.graphics_pipeline.clone(), &DynamicState::none(), vertices, (), ())
.expect("failed to draw")
.end_render_pass()
.expect("failed to end render pass")
.build()
.expect("failed to build render pass"))
})
.collect();
}the full source is here: https://github.com/bwasty/vulkan-tutorial-rs/blob/master/src/bin/14_command_buffers.rs
error[E0507]: cannot move out of a mutable reference
.expect("failed to end render pass"), and the reason is "because value has type vulkano::command_buffer::AutoCommandBufferBuilder, which does not implement the Copy trait". any ideas?
@cosmicchipsocket Hi!
Regarding maintenance issue, I put a comment here: vulkano-rs/vulkano#1435 Basically, we are currently on our own. But if someone wants to merge something into the repo, if he needs and wants to fix something he can do so and I can help with merging the PR as I was granted PRs merging access recently.
AutoCommandBufferBuilder is not Copy, yes. I think maybe you forgot to put let mut in front of buffer builder variable declaration? Also since AutoCommandBufferBuilder accepting commands by &mut self you have to call each command on separate line. And in the end call .build() by value, not by reference: https://docs.rs/vulkano/0.19.0/vulkano/command_buffer/struct.AutoCommandBufferBuilder.html#method.build
fn create_command_buffers(&mut self) {
let queue_family = self.graphics_queue.family();
self.command_buffers = self.swapchain_framebuffers.iter()
.map(|framebuffer| {
let vertices = BufferlessVertices { vertices: 3, instances: 1 };
let mut builder = AutoCommandBufferBuilder::primary_simultaneous_use(self.device.clone(), queue_family)
.expect("failed to initialise command buffer builder");
builder.begin_render_pass(framebuffer.clone(), false, vec![[0.0, 0.0, 1.0].into()])
.expect("failed to begin render pass")
.draw(self.graphics_pipeline.clone(), &DynamicState::none(), vertices, (), ())
.expect("failed to draw")
.end_render_pass()
.expect("failed to end render pass");
let command_buffer = builder.build().expect("failed to build render pass"));
Arc::new(command_buffer)
})
.collect();
}
Hi, I'm rendering a scene twice and the second time i render it I use Equal for depth testing. It works until I put a compute dispatch in between the two, the depth gets all corrupted so I guess the layout isn't being transitioned. For the second pass on the scene I'm binding it to the frame buffer but not writing to it. Any ideas?
does anyone rember this? As it been fixed?
let framebuffer = Framebuffer::start(render_pass.clone())
.add(**Here**).unwrap()
.build().unwrap();
@OniDaito Hi!
Sorry for delay with the answer.
Yes, Runtime shader example is one of the options. Current primary use-case of Vulkano is to use precompiled shaders(built in compile time through the shader! macros), but there is a way to load them manually too in which case one will have to configure all descriptors and layouts manually(which is unsafe).
On general note, Vulkano is following a principle(but is not enforces it too strongly) that all shaders normally should be loaded in the beginning and be prepared beforehand. In this case the end-user can gain maximal benefits of GPU capabilities through Vulkan API. GPUs themselves are not very tolerate to shader programs reloading, as it breaks the entire pipeline and all related stuff set up by the device on pipeline creation. Basically GPUs are designed for static programs. That's why Vulkano in turn trying to follow the same approach.
This is, however, not always possible, and there could be edge cases when the API user might want to generate shader's code on the fly. One of the possibility as I mentioned is to use the approach from Runtime shader example. But it could be difficult to maintain. Another approach(a limited one, though) is to use Specialization Constants. The API user in fact can prepare large code of the shader that would specialize depending on Specialization Constants values. One can even organize branching depending on the values of constants, the shader loader will optimizes particular specialization statically and eliminate dead code control flows not covered by particular specilization.
Just as an idea for you. Please take a look at the specialization constants examples in repository for more details.
@OniDaito, @shiraori:matrix.org , @derivator
Dear fellows,
I have to apologize I'm not able to maintain the chat regularly. I'm visiting it rarely and noticing new topics came days if not weeks ago. This is my bad, but I just don't have enough resources to response on time. Perhaps, it would be more beneficial for you and for the community if you raise questions and topics in Vulkano repository Issues section. Me and other regular users are watching it more regularly.
SyncCommandBufferBuilderError(Conflict { command1_name: "vkCmdBeginRenderPass", command1_param: "attachment 5", command1_offset: 88, command2_name: "vkCmdBindDescriptorSets", command2_param: "Image bound to descriptor 0 of set 0", command2_offset: 92 })'. Do you have any idea what could I have done wrong?
1 reply
assert_eq!(num, 0); at vulkano's src/command_buffer/synced/commands.rs:1046 is failing for me, and i'm not sure what that means, anyone got any idea ?
copy_buffer, and now the panic!(); at src/command_buffer/synced/commands.rs:2247 is being called
@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.