diff --git a/src/vkprocessor.rs b/src/vkprocessor.rs index e952e62f..807ebaac 100644 --- a/src/vkprocessor.rs +++ b/src/vkprocessor.rs @@ -320,7 +320,7 @@ impl<'a> VkProcessor<'a> { // We need to indicate the layout of the vertices. // The type `SingleBufferDefinition` actually contains a template parameter corresponding // to the type of each vertex. But in this code it is automatically inferred. -// .vertex_input_single_buffer() + .vertex_input_single_buffer::() // A Vulkan shader can in theory contain multiple entry points, so we have to specify // which one. The `main` word of `main_entry_point` actually corresponds to the name of // the entry point. @@ -445,9 +445,9 @@ impl<'a> VkProcessor<'a> { AutoCommandBufferBuilder::primary_one_time_submit(self.device.clone(), self.queue.family()) .unwrap() -// .dispatch([self.xy.0, self.xy.1, 1], -// self.compute_pipeline.clone(), -// self.set.clone(), ()).unwrap() + .dispatch([self.xy.0, self.xy.1, 1], + self.compute_pipeline.clone().unwrap().clone(), + self.set.clone().unwrap().clone(), ()).unwrap() // Before we can draw, we have to *enter a render pass*. There are two methods to do // this: `draw_inline` and `draw_secondary`. The latter is a bit more advanced and is // not covered here. @@ -501,13 +501,6 @@ impl<'a> VkProcessor<'a> { } } } - // Note that in more complex programs it is likely that one of `acquire_next_image`, - // `command_buffer::submit`, or `present` will block for some time. This happens when the - // GPU's queue is full and the driver has to wait until the GPU finished some work. - // - // Unfortunately the Vulkan API doesn't provide any way to not wait or to detect when a - // wait would happen. Blocking may be the desired behavior, but if you don't want to - // block you should spawn a separate thread dedicated to submissions. // Handling the window events in order to close the program when the user wants to close // it.