got it working again. Finally clicked with me what was going on with the functions & how to specify their generic types
This commit is contained in:
@@ -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.
|
||||||
|
|||||||
Reference in New Issue
Block a user