got it working again. Finally clicked with me what was going on with the functions & how to specify their generic types

master
mitchellhansen 5 years ago
parent a71958e815
commit 3f79b276a9

@ -320,7 +320,7 @@ impl<'a> VkProcessor<'a> {
// We need to indicate the layout of the vertices. // We need to indicate the layout of the vertices.
// The type `SingleBufferDefinition` actually contains a template parameter corresponding // The type `SingleBufferDefinition` actually contains a template parameter corresponding
// to the type of each vertex. But in this code it is automatically inferred. // to the type of each vertex. But in this code it is automatically inferred.
// .vertex_input_single_buffer() .vertex_input_single_buffer::<tVertex>()
// A Vulkan shader can in theory contain multiple entry points, so we have to specify // 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 // which one. The `main` word of `main_entry_point` actually corresponds to the name of
// the entry point. // the entry point.
@ -445,9 +445,9 @@ impl<'a> VkProcessor<'a> {
AutoCommandBufferBuilder::primary_one_time_submit(self.device.clone(), self.queue.family()) AutoCommandBufferBuilder::primary_one_time_submit(self.device.clone(), self.queue.family())
.unwrap() .unwrap()
// .dispatch([self.xy.0, self.xy.1, 1], .dispatch([self.xy.0, self.xy.1, 1],
// self.compute_pipeline.clone(), self.compute_pipeline.clone().unwrap().clone(),
// self.set.clone(), ()).unwrap() self.set.clone().unwrap().clone(), ()).unwrap()
// Before we can draw, we have to *enter a render pass*. There are two methods to do // 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 // this: `draw_inline` and `draw_secondary`. The latter is a bit more advanced and is
// not covered here. // 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 // Handling the window events in order to close the program when the user wants to close
// it. // it.

Loading…
Cancel
Save