2016-03-26 09:17:37 +00:00
|
|
|
// Copyright (c) 2016 The vulkano developers
|
|
|
|
// Licensed under the Apache License, Version 2.0
|
|
|
|
// <LICENSE-APACHE or
|
2020-11-10 17:03:50 +00:00
|
|
|
// https://www.apache.org/licenses/LICENSE-2.0> or the MIT
|
|
|
|
// license <LICENSE-MIT or https://opensource.org/licenses/MIT>,
|
2016-03-26 09:17:37 +00:00
|
|
|
// at your option. All files in the project carrying such
|
|
|
|
// notice may not be copied, modified, or distributed except
|
|
|
|
// according to those terms.
|
|
|
|
|
2016-04-29 08:28:20 +00:00
|
|
|
// Welcome to the triangle example!
|
|
|
|
//
|
|
|
|
// This is the only example that is entirely detailed. All the other examples avoid code
|
|
|
|
// duplication by using helper functions.
|
|
|
|
//
|
|
|
|
// This example assumes that you are already more or less familiar with graphics programming
|
|
|
|
// and that you want to learn Vulkan. This means that for example it won't go into details about
|
|
|
|
// what a vertex or a shader is.
|
|
|
|
|
2022-03-06 19:30:49 +00:00
|
|
|
use bytemuck::{Pod, Zeroable};
|
2021-05-23 16:09:50 +00:00
|
|
|
use std::sync::Arc;
|
2022-03-06 19:30:49 +00:00
|
|
|
use vulkano::{
|
|
|
|
buffer::{BufferUsage, CpuAccessibleBuffer, TypedBufferAccess},
|
2022-04-24 01:16:19 +00:00
|
|
|
command_buffer::{
|
|
|
|
AutoCommandBufferBuilder, CommandBufferUsage, RenderPassBeginInfo, SubpassContents,
|
|
|
|
},
|
2022-03-06 19:30:49 +00:00
|
|
|
device::{
|
2022-09-10 06:00:08 +00:00
|
|
|
physical::PhysicalDeviceType, Device, DeviceCreateInfo, DeviceExtensions, QueueCreateInfo,
|
2022-03-06 19:30:49 +00:00
|
|
|
},
|
|
|
|
image::{view::ImageView, ImageAccess, ImageUsage, SwapchainImage},
|
|
|
|
impl_vertex,
|
|
|
|
instance::{Instance, InstanceCreateInfo},
|
|
|
|
pipeline::{
|
|
|
|
graphics::{
|
|
|
|
input_assembly::InputAssemblyState,
|
|
|
|
vertex_input::BuffersDefinition,
|
|
|
|
viewport::{Viewport, ViewportState},
|
|
|
|
},
|
|
|
|
GraphicsPipeline,
|
|
|
|
},
|
|
|
|
render_pass::{Framebuffer, FramebufferCreateInfo, RenderPass, Subpass},
|
|
|
|
swapchain::{
|
2022-09-24 06:45:06 +00:00
|
|
|
acquire_next_image, AcquireError, Swapchain, SwapchainAbstract,
|
|
|
|
SwapchainCreateInfo, SwapchainCreationError, SwapchainPresentInfo,
|
2022-03-06 19:30:49 +00:00
|
|
|
},
|
|
|
|
sync::{self, FlushError, GpuFuture},
|
2022-07-30 06:53:52 +00:00
|
|
|
VulkanLibrary,
|
2022-02-20 09:55:34 +00:00
|
|
|
};
|
2018-10-28 03:02:29 +00:00
|
|
|
use vulkano_win::VkSurfaceBuild;
|
2022-03-06 19:30:49 +00:00
|
|
|
use winit::{
|
|
|
|
event::{Event, WindowEvent},
|
|
|
|
event_loop::{ControlFlow, EventLoop},
|
|
|
|
window::{Window, WindowBuilder},
|
|
|
|
};
|
2018-10-27 21:16:30 +00:00
|
|
|
|
2016-02-18 08:33:06 +00:00
|
|
|
fn main() {
|
2018-09-02 04:18:22 +00:00
|
|
|
// The first step of any Vulkan program is to create an instance.
|
2020-01-23 07:37:12 +00:00
|
|
|
//
|
|
|
|
// When we create an instance, we have to pass a list of extensions that we want to enable.
|
|
|
|
//
|
|
|
|
// All the window-drawing functionalities are part of non-core extensions that we need
|
|
|
|
// to enable manually. To do so, we ask the `vulkano_win` crate for the list of extensions
|
|
|
|
// required to draw to a window.
|
2022-07-30 06:53:52 +00:00
|
|
|
let library = VulkanLibrary::new().unwrap();
|
|
|
|
let required_extensions = vulkano_win::required_extensions(&library);
|
2016-04-29 08:28:20 +00:00
|
|
|
|
2020-01-23 07:37:12 +00:00
|
|
|
// Now creating the instance.
|
2022-07-30 06:53:52 +00:00
|
|
|
let instance = Instance::new(
|
|
|
|
library,
|
|
|
|
InstanceCreateInfo {
|
|
|
|
enabled_extensions: required_extensions,
|
|
|
|
// Enable enumerating devices that use non-conformant vulkan implementations. (ex. MoltenVK)
|
|
|
|
enumerate_portability: true,
|
|
|
|
..Default::default()
|
|
|
|
},
|
|
|
|
)
|
2022-02-14 09:32:27 +00:00
|
|
|
.unwrap();
|
2016-02-18 08:33:06 +00:00
|
|
|
|
2016-04-29 08:28:20 +00:00
|
|
|
// The objective of this example is to draw a triangle on a window. To do so, we first need to
|
|
|
|
// create the window.
|
|
|
|
//
|
|
|
|
// This is done by creating a `WindowBuilder` from the `winit` crate, then calling the
|
|
|
|
// `build_vk_surface` method provided by the `VkSurfaceBuild` trait from `vulkano_win`. If you
|
|
|
|
// ever get an error about `build_vk_surface` being undefined in one of your projects, this
|
2016-05-03 13:56:52 +00:00
|
|
|
// probably means that you forgot to import this trait.
|
2016-02-18 08:59:54 +00:00
|
|
|
//
|
2018-02-13 13:29:36 +00:00
|
|
|
// This returns a `vulkano::swapchain::Surface` object that contains both a cross-platform winit
|
2016-04-29 08:28:20 +00:00
|
|
|
// window and a cross-platform Vulkan surface that represents the surface of the window.
|
2020-01-23 07:37:12 +00:00
|
|
|
let event_loop = EventLoop::new();
|
2020-05-10 00:36:20 +00:00
|
|
|
let surface = WindowBuilder::new()
|
|
|
|
.build_vk_surface(&event_loop, instance.clone())
|
|
|
|
.unwrap();
|
2018-08-30 01:37:51 +00:00
|
|
|
|
2021-06-28 06:24:44 +00:00
|
|
|
// Choose device extensions that we're going to use.
|
|
|
|
// In order to present images to a surface, we need a `Swapchain`, which is provided by the
|
|
|
|
// `khr_swapchain` extension.
|
|
|
|
let device_extensions = DeviceExtensions {
|
|
|
|
khr_swapchain: true,
|
2022-09-05 20:16:40 +00:00
|
|
|
..DeviceExtensions::empty()
|
2021-06-28 06:24:44 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
// We then choose which physical device to use. First, we enumerate all the available physical
|
|
|
|
// devices, then apply filters to narrow them down to those that can support our needs.
|
2022-09-10 06:00:08 +00:00
|
|
|
let (physical_device, queue_family_index) = instance
|
|
|
|
.enumerate_physical_devices()
|
|
|
|
.unwrap()
|
|
|
|
.filter(|p| {
|
2021-06-28 06:24:44 +00:00
|
|
|
// Some devices may not support the extensions or features that your application, or
|
|
|
|
// report properties and limits that are not sufficient for your application. These
|
|
|
|
// should be filtered out here.
|
2022-09-05 20:16:40 +00:00
|
|
|
p.supported_extensions().contains(&device_extensions)
|
2021-06-28 06:24:44 +00:00
|
|
|
})
|
|
|
|
.filter_map(|p| {
|
|
|
|
// For each physical device, we try to find a suitable queue family that will execute
|
|
|
|
// our draw commands.
|
|
|
|
//
|
|
|
|
// Devices can provide multiple queues to run commands in parallel (for example a draw
|
|
|
|
// queue and a compute queue), similar to CPU threads. This is something you have to
|
|
|
|
// have to manage manually in Vulkan. Queues of the same type belong to the same
|
|
|
|
// queue family.
|
|
|
|
//
|
|
|
|
// Here, we look for a single queue family that is suitable for our purposes. In a
|
|
|
|
// real-life application, you may want to use a separate dedicated transfer queue to
|
|
|
|
// handle data transfers in parallel with graphics operations. You may also need a
|
|
|
|
// separate queue for compute operations, if your application uses those.
|
2022-09-10 06:00:08 +00:00
|
|
|
p.queue_family_properties()
|
|
|
|
.iter()
|
|
|
|
.enumerate()
|
|
|
|
.position(|(i, q)| {
|
2021-06-28 06:24:44 +00:00
|
|
|
// We select a queue family that supports graphics operations. When drawing to
|
|
|
|
// a window surface, as we do in this example, we also need to check that queues
|
|
|
|
// in this queue family are capable of presenting images to the surface.
|
2022-09-10 06:00:08 +00:00
|
|
|
q.queue_flags.graphics && p.surface_support(i as u32, &surface).unwrap_or(false)
|
2021-06-28 06:24:44 +00:00
|
|
|
})
|
|
|
|
// The code here searches for the first queue family that is suitable. If none is
|
|
|
|
// found, `None` is returned to `filter_map`, which disqualifies this physical
|
|
|
|
// device.
|
2022-09-10 06:00:08 +00:00
|
|
|
.map(|i| (p, i as u32))
|
2021-06-28 06:24:44 +00:00
|
|
|
})
|
|
|
|
// All the physical devices that pass the filters above are suitable for the application.
|
|
|
|
// However, not every device is equal, some are preferred over others. Now, we assign
|
|
|
|
// each physical device a score, and pick the device with the
|
|
|
|
// lowest ("best") score.
|
|
|
|
//
|
|
|
|
// In this example, we simply select the best-scoring device to use in the application.
|
|
|
|
// In a real-life setting, you may want to use the best-scoring device only as a
|
|
|
|
// "default" or "recommended" device, and let the user choose the device themselves.
|
|
|
|
.min_by_key(|(p, _)| {
|
2022-05-29 16:53:36 +00:00
|
|
|
// We assign a lower score to device types that are likely to be faster/better.
|
2021-08-09 13:44:58 +00:00
|
|
|
match p.properties().device_type {
|
2021-06-28 06:24:44 +00:00
|
|
|
PhysicalDeviceType::DiscreteGpu => 0,
|
|
|
|
PhysicalDeviceType::IntegratedGpu => 1,
|
|
|
|
PhysicalDeviceType::VirtualGpu => 2,
|
|
|
|
PhysicalDeviceType::Cpu => 3,
|
|
|
|
PhysicalDeviceType::Other => 4,
|
2022-09-05 20:16:40 +00:00
|
|
|
_ => 5,
|
2021-06-28 06:24:44 +00:00
|
|
|
}
|
2020-05-10 00:36:20 +00:00
|
|
|
})
|
2022-05-29 16:53:36 +00:00
|
|
|
.expect("No suitable physical device found");
|
2016-02-18 08:33:06 +00:00
|
|
|
|
2021-06-28 06:24:44 +00:00
|
|
|
// Some little debug infos.
|
|
|
|
println!(
|
|
|
|
"Using device: {} (type: {:?})",
|
2021-08-09 13:44:58 +00:00
|
|
|
physical_device.properties().device_name,
|
|
|
|
physical_device.properties().device_type,
|
2021-06-28 06:24:44 +00:00
|
|
|
);
|
|
|
|
|
2016-04-29 08:28:20 +00:00
|
|
|
// Now initializing the device. This is probably the most important object of Vulkan.
|
|
|
|
//
|
2021-05-24 10:00:12 +00:00
|
|
|
// The iterator of created queues is returned by the function alongside the device.
|
2020-05-10 00:36:20 +00:00
|
|
|
let (device, mut queues) = Device::new(
|
2022-02-14 09:32:27 +00:00
|
|
|
// Which physical device to connect to.
|
2021-06-28 06:24:44 +00:00
|
|
|
physical_device,
|
2022-02-14 09:32:27 +00:00
|
|
|
DeviceCreateInfo {
|
|
|
|
// A list of optional features and extensions that our program needs to work correctly.
|
|
|
|
// Some parts of the Vulkan specs are optional and must be enabled manually at device
|
|
|
|
// creation. In this example the only thing we are going to need is the `khr_swapchain`
|
|
|
|
// extension that allows us to draw to a window.
|
2022-07-18 13:11:43 +00:00
|
|
|
enabled_extensions: device_extensions,
|
2022-02-14 09:32:27 +00:00
|
|
|
|
|
|
|
// The list of queues that we are going to use. Here we only use one queue, from the
|
|
|
|
// previously chosen queue family.
|
2022-09-10 06:00:08 +00:00
|
|
|
queue_create_infos: vec![QueueCreateInfo {
|
|
|
|
queue_family_index,
|
|
|
|
..Default::default()
|
|
|
|
}],
|
2022-02-14 09:32:27 +00:00
|
|
|
|
|
|
|
..Default::default()
|
|
|
|
},
|
2020-05-10 00:36:20 +00:00
|
|
|
)
|
|
|
|
.unwrap();
|
2016-02-18 08:33:06 +00:00
|
|
|
|
2021-05-24 10:00:12 +00:00
|
|
|
// Since we can request multiple queues, the `queues` variable is in fact an iterator. We
|
|
|
|
// only use one queue in this example, so we just retrieve the first and only element of the
|
2021-06-28 06:24:44 +00:00
|
|
|
// iterator.
|
2016-05-12 15:40:31 +00:00
|
|
|
let queue = queues.next().unwrap();
|
2016-02-18 08:33:06 +00:00
|
|
|
|
|
|
|
// Before we can draw on the surface, we have to create what is called a swapchain. Creating
|
2016-02-18 08:59:54 +00:00
|
|
|
// a swapchain allocates the color buffers that will contain the image that will ultimately
|
2021-05-24 10:00:12 +00:00
|
|
|
// be visible on the screen. These images are returned alongside the swapchain.
|
2018-10-27 21:16:30 +00:00
|
|
|
let (mut swapchain, images) = {
|
2016-04-29 08:28:20 +00:00
|
|
|
// Querying the capabilities of the surface. When we create the swapchain we can only
|
|
|
|
// pass values that are allowed by the capabilities.
|
2022-09-10 06:00:08 +00:00
|
|
|
let surface_capabilities = device
|
|
|
|
.physical_device()
|
2022-02-20 09:55:34 +00:00
|
|
|
.surface_capabilities(&surface, Default::default())
|
|
|
|
.unwrap();
|
2016-04-29 08:28:20 +00:00
|
|
|
|
|
|
|
// Choosing the internal format that the images will have.
|
2022-02-20 09:55:34 +00:00
|
|
|
let image_format = Some(
|
2022-09-10 06:00:08 +00:00
|
|
|
device
|
|
|
|
.physical_device()
|
2022-02-20 09:55:34 +00:00
|
|
|
.surface_formats(&surface, Default::default())
|
|
|
|
.unwrap()[0]
|
|
|
|
.0,
|
|
|
|
);
|
2018-10-28 03:02:29 +00:00
|
|
|
|
2016-04-29 08:28:20 +00:00
|
|
|
// Please take a look at the docs for the meaning of the parameters we didn't mention.
|
2022-02-20 09:55:34 +00:00
|
|
|
Swapchain::new(
|
|
|
|
device.clone(),
|
|
|
|
surface.clone(),
|
|
|
|
SwapchainCreateInfo {
|
|
|
|
min_image_count: surface_capabilities.min_image_count,
|
|
|
|
|
|
|
|
image_format,
|
|
|
|
// The dimensions of the window, only used to initially setup the swapchain.
|
|
|
|
// NOTE:
|
|
|
|
// On some drivers the swapchain dimensions are specified by
|
|
|
|
// `surface_capabilities.current_extent` and the swapchain size must use these
|
|
|
|
// dimensions.
|
|
|
|
// These dimensions are always the same as the window dimensions.
|
|
|
|
//
|
|
|
|
// However, other drivers don't specify a value, i.e.
|
|
|
|
// `surface_capabilities.current_extent` is `None`. These drivers will allow
|
|
|
|
// anything, but the only sensible value is the window
|
|
|
|
// dimensions.
|
|
|
|
//
|
|
|
|
// Both of these cases need the swapchain to use the window dimensions, so we just
|
|
|
|
// use that.
|
|
|
|
image_extent: surface.window().inner_size().into(),
|
|
|
|
|
2022-09-05 20:16:40 +00:00
|
|
|
image_usage: ImageUsage {
|
|
|
|
color_attachment: true,
|
|
|
|
..ImageUsage::empty()
|
|
|
|
},
|
2022-02-20 09:55:34 +00:00
|
|
|
|
|
|
|
// The alpha mode indicates how the alpha value of the final image will behave. For
|
|
|
|
// example, you can choose whether the window will be opaque or transparent.
|
|
|
|
composite_alpha: surface_capabilities
|
|
|
|
.supported_composite_alpha
|
|
|
|
.iter()
|
|
|
|
.next()
|
|
|
|
.unwrap(),
|
|
|
|
|
|
|
|
..Default::default()
|
|
|
|
},
|
|
|
|
)
|
|
|
|
.unwrap()
|
2016-02-18 08:33:06 +00:00
|
|
|
};
|
|
|
|
|
2016-02-18 08:59:54 +00:00
|
|
|
// We now create a buffer that will store the shape of our triangle.
|
2021-11-24 14:19:57 +00:00
|
|
|
// We use #[repr(C)] here to force rustc to not do anything funky with our data, although for this
|
|
|
|
// particular example, it doesn't actually change the in-memory representation.
|
|
|
|
#[repr(C)]
|
2022-03-06 19:30:49 +00:00
|
|
|
#[derive(Clone, Copy, Debug, Default, Zeroable, Pod)]
|
2021-07-05 04:19:32 +00:00
|
|
|
struct Vertex {
|
|
|
|
position: [f32; 2],
|
|
|
|
}
|
2022-03-06 19:30:49 +00:00
|
|
|
impl_vertex!(Vertex, position);
|
2016-04-29 08:28:20 +00:00
|
|
|
|
2022-03-06 19:30:49 +00:00
|
|
|
let vertices = [
|
|
|
|
Vertex {
|
|
|
|
position: [-0.5, -0.25],
|
|
|
|
},
|
|
|
|
Vertex {
|
|
|
|
position: [0.0, 0.5],
|
|
|
|
},
|
|
|
|
Vertex {
|
|
|
|
position: [0.25, -0.1],
|
|
|
|
},
|
|
|
|
];
|
2022-09-05 20:16:40 +00:00
|
|
|
let vertex_buffer = CpuAccessibleBuffer::from_iter(
|
|
|
|
device.clone(),
|
|
|
|
BufferUsage {
|
|
|
|
vertex_buffer: true,
|
|
|
|
..BufferUsage::empty()
|
|
|
|
},
|
|
|
|
false,
|
|
|
|
vertices,
|
|
|
|
)
|
|
|
|
.unwrap();
|
2016-02-18 08:33:06 +00:00
|
|
|
|
2018-10-28 07:29:41 +00:00
|
|
|
// The next step is to create the shaders.
|
|
|
|
//
|
2022-07-13 10:26:47 +00:00
|
|
|
// The raw shader creation API provided by the vulkano library is unsafe for various
|
|
|
|
// reasons, so The `shader!` macro provides a way to generate a Rust module from GLSL
|
|
|
|
// source - in the example below, the source is provided as a string input directly to
|
|
|
|
// the shader, but a path to a source file can be provided as well. Note that the user
|
|
|
|
// must specify the type of shader (e.g., "vertex," "fragment, etc.") using the `ty`
|
2022-07-18 13:11:43 +00:00
|
|
|
// option of the macro.
|
2018-10-28 07:29:41 +00:00
|
|
|
//
|
2022-07-13 10:26:47 +00:00
|
|
|
// The module generated by the `shader!` macro includes a `load` function which loads
|
|
|
|
// the shader using an input logical device. The module also includes type definitions
|
|
|
|
// for layout structures defined in the shader source, for example, uniforms and push
|
|
|
|
// constants.
|
2018-10-28 07:29:41 +00:00
|
|
|
//
|
2022-07-13 10:26:47 +00:00
|
|
|
// A more detailed overview of what the `shader!` macro generates can be found in the
|
|
|
|
// `vulkano-shaders` crate docs. You can view them at https://docs.rs/vulkano-shaders/
|
2018-10-28 07:29:41 +00:00
|
|
|
mod vs {
|
2020-05-10 00:36:20 +00:00
|
|
|
vulkano_shaders::shader! {
|
2018-10-28 07:29:41 +00:00
|
|
|
ty: "vertex",
|
|
|
|
src: "
|
2020-01-23 07:37:12 +00:00
|
|
|
#version 450
|
2018-10-28 07:29:41 +00:00
|
|
|
|
2020-01-23 07:37:12 +00:00
|
|
|
layout(location = 0) in vec2 position;
|
2018-10-28 07:29:41 +00:00
|
|
|
|
2020-01-23 07:37:12 +00:00
|
|
|
void main() {
|
|
|
|
gl_Position = vec4(position, 0.0, 1.0);
|
|
|
|
}
|
|
|
|
"
|
2018-10-28 07:29:41 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
mod fs {
|
2020-05-10 00:36:20 +00:00
|
|
|
vulkano_shaders::shader! {
|
2018-10-28 07:29:41 +00:00
|
|
|
ty: "fragment",
|
|
|
|
src: "
|
2020-01-23 07:37:12 +00:00
|
|
|
#version 450
|
2018-10-28 07:29:41 +00:00
|
|
|
|
2020-01-23 07:37:12 +00:00
|
|
|
layout(location = 0) out vec4 f_color;
|
2018-10-28 07:29:41 +00:00
|
|
|
|
2020-01-23 07:37:12 +00:00
|
|
|
void main() {
|
|
|
|
f_color = vec4(1.0, 0.0, 0.0, 1.0);
|
|
|
|
}
|
|
|
|
"
|
2018-10-28 07:29:41 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-11-13 15:06:16 +00:00
|
|
|
let vs = vs::load(device.clone()).unwrap();
|
|
|
|
let fs = fs::load(device.clone()).unwrap();
|
2016-02-18 08:33:06 +00:00
|
|
|
|
|
|
|
// At this point, OpenGL initialization would be finished. However in Vulkan it is not. OpenGL
|
2018-09-02 04:18:22 +00:00
|
|
|
// implicitly does a lot of computation whenever you draw. In Vulkan, you have to do all this
|
2016-02-18 08:33:06 +00:00
|
|
|
// manually.
|
|
|
|
|
2016-04-29 08:28:20 +00:00
|
|
|
// The next step is to create a *render pass*, which is an object that describes where the
|
2016-02-18 08:33:06 +00:00
|
|
|
// output of the graphics pipeline will go. It describes the layout of the images
|
|
|
|
// where the colors, depth and/or stencil information will be written.
|
2021-11-02 20:33:58 +00:00
|
|
|
let render_pass = vulkano::single_pass_renderpass!(
|
|
|
|
device.clone(),
|
|
|
|
attachments: {
|
|
|
|
// `color` is a custom name we give to the first and only attachment.
|
|
|
|
color: {
|
|
|
|
// `load: Clear` means that we ask the GPU to clear the content of this
|
|
|
|
// attachment at the start of the drawing.
|
|
|
|
load: Clear,
|
|
|
|
// `store: Store` means that we ask the GPU to store the output of the draw
|
|
|
|
// in the actual image. We could also ask it to discard the result.
|
|
|
|
store: Store,
|
|
|
|
// `format: <ty>` indicates the type of the format of the image. This has to
|
|
|
|
// be one of the types of the `vulkano::format` module (or alternatively one
|
|
|
|
// of your structs that implements the `FormatDesc` trait). Here we use the
|
|
|
|
// same format as the swapchain.
|
2022-02-20 09:55:34 +00:00
|
|
|
format: swapchain.image_format(),
|
2022-07-13 10:26:47 +00:00
|
|
|
// `samples: 1` means that we ask the GPU to use one sample to determine the value
|
|
|
|
// of each pixel in the color attachment. We could use a larger value (multisampling)
|
|
|
|
// for antialiasing. An example of this can be found in msaa-renderpass.rs.
|
2021-11-02 20:33:58 +00:00
|
|
|
samples: 1,
|
2016-02-28 16:21:01 +00:00
|
|
|
}
|
2021-11-02 20:33:58 +00:00
|
|
|
},
|
|
|
|
pass: {
|
|
|
|
// We use the attachment named `color` as the one and only color attachment.
|
|
|
|
color: [color],
|
|
|
|
// No depth-stencil attachment is indicated with empty brackets.
|
|
|
|
depth_stencil: {}
|
|
|
|
}
|
|
|
|
)
|
|
|
|
.unwrap();
|
2016-02-18 08:33:06 +00:00
|
|
|
|
2016-04-29 08:28:20 +00:00
|
|
|
// Before we draw we have to create what is called a pipeline. This is similar to an OpenGL
|
|
|
|
// program, but much more specific.
|
2021-11-02 20:33:58 +00:00
|
|
|
let pipeline = GraphicsPipeline::start()
|
2022-05-29 16:53:36 +00:00
|
|
|
// We have to indicate which subpass of which render pass this pipeline is going to be used
|
|
|
|
// in. The pipeline will only be usable from this particular subpass.
|
|
|
|
.render_pass(Subpass::from(render_pass.clone(), 0).unwrap())
|
2021-11-02 20:33:58 +00:00
|
|
|
// We need to indicate the layout of the vertices.
|
2021-12-05 20:30:56 +00:00
|
|
|
.vertex_input_state(BuffersDefinition::new().vertex::<Vertex>())
|
2022-05-29 16:53:36 +00:00
|
|
|
// The content of the vertex buffer describes a list of triangles.
|
|
|
|
.input_assembly_state(InputAssemblyState::new())
|
2021-11-02 20:33:58 +00:00
|
|
|
// A Vulkan shader can in theory contain multiple entry points, so we have to specify
|
2021-12-05 20:30:56 +00:00
|
|
|
// which one.
|
2021-11-13 15:06:16 +00:00
|
|
|
.vertex_shader(vs.entry_point("main").unwrap(), ())
|
2021-11-02 20:33:58 +00:00
|
|
|
// Use a resizable viewport set to draw over the entire window
|
|
|
|
.viewport_state(ViewportState::viewport_dynamic_scissor_irrelevant())
|
|
|
|
// See `vertex_shader`.
|
2021-11-13 15:06:16 +00:00
|
|
|
.fragment_shader(fs.entry_point("main").unwrap(), ())
|
2021-11-02 20:33:58 +00:00
|
|
|
// Now that our builder is filled, we call `build()` to obtain an actual pipeline.
|
|
|
|
.build(device.clone())
|
|
|
|
.unwrap();
|
2016-02-18 08:59:54 +00:00
|
|
|
|
2018-10-27 21:16:30 +00:00
|
|
|
// Dynamic viewports allow us to recreate just the viewport when the window is resized
|
|
|
|
// Otherwise we would have to recreate the whole pipeline.
|
2021-08-27 06:24:16 +00:00
|
|
|
let mut viewport = Viewport {
|
|
|
|
origin: [0.0, 0.0],
|
|
|
|
dimensions: [0.0, 0.0],
|
|
|
|
depth_range: 0.0..1.0,
|
2020-05-10 00:36:20 +00:00
|
|
|
};
|
2018-10-27 21:16:30 +00:00
|
|
|
|
2016-04-29 08:28:20 +00:00
|
|
|
// The render pass we created above only describes the layout of our framebuffers. Before we
|
|
|
|
// can draw we also need to create the actual framebuffers.
|
2016-02-18 08:33:06 +00:00
|
|
|
//
|
2016-02-18 08:59:54 +00:00
|
|
|
// Since we need to draw to multiple images, we are going to create a different framebuffer for
|
|
|
|
// each image.
|
2021-08-27 06:24:16 +00:00
|
|
|
let mut framebuffers = window_size_dependent_setup(&images, render_pass.clone(), &mut viewport);
|
2016-02-18 08:33:06 +00:00
|
|
|
|
|
|
|
// Initialization is finally finished!
|
|
|
|
|
2017-07-26 15:58:40 +00:00
|
|
|
// In some situations, the swapchain will become invalid by itself. This includes for example
|
|
|
|
// when the window is resized (as the images of the swapchain will no longer match the
|
|
|
|
// window's) or, on Android, when the application went to the background and goes back to the
|
|
|
|
// foreground.
|
|
|
|
//
|
|
|
|
// In this situation, acquiring a swapchain image or presenting it will return an error.
|
|
|
|
// Rendering to an image of that swapchain will not produce any error, but may or may not work.
|
|
|
|
// To continue rendering, we need to recreate the swapchain by creating a new swapchain.
|
|
|
|
// Here, we remember that we need to do this for the next loop iteration.
|
|
|
|
let mut recreate_swapchain = false;
|
|
|
|
|
2016-05-08 11:16:21 +00:00
|
|
|
// In the loop below we are going to submit commands to the GPU. Submitting a command produces
|
2017-02-13 15:18:10 +00:00
|
|
|
// an object that implements the `GpuFuture` trait, which holds the resources for as long as
|
|
|
|
// they are in use by the GPU.
|
2016-04-29 08:28:20 +00:00
|
|
|
//
|
2017-02-13 15:18:10 +00:00
|
|
|
// Destroying the `GpuFuture` blocks until the GPU is finished executing it. In order to avoid
|
2017-05-21 17:04:14 +00:00
|
|
|
// that, we store the submission of the previous frame here.
|
2020-05-12 23:05:09 +00:00
|
|
|
let mut previous_frame_end = Some(sync::now(device.clone()).boxed());
|
2017-07-26 15:58:40 +00:00
|
|
|
|
2020-01-23 07:37:12 +00:00
|
|
|
event_loop.run(move |event, _, control_flow| {
|
|
|
|
match event {
|
2020-05-10 00:36:20 +00:00
|
|
|
Event::WindowEvent {
|
|
|
|
event: WindowEvent::CloseRequested,
|
|
|
|
..
|
|
|
|
} => {
|
2020-01-23 07:37:12 +00:00
|
|
|
*control_flow = ControlFlow::Exit;
|
2020-05-10 00:36:20 +00:00
|
|
|
}
|
|
|
|
Event::WindowEvent {
|
|
|
|
event: WindowEvent::Resized(_),
|
|
|
|
..
|
|
|
|
} => {
|
2018-02-14 07:51:52 +00:00
|
|
|
recreate_swapchain = true;
|
2020-05-10 00:36:20 +00:00
|
|
|
}
|
2020-01-23 07:37:12 +00:00
|
|
|
Event::RedrawEventsCleared => {
|
2022-05-09 12:25:26 +00:00
|
|
|
// Do not draw frame when screen dimensions are zero.
|
|
|
|
// On Windows, this can occur from minimizing the application.
|
|
|
|
let dimensions = surface.window().inner_size();
|
|
|
|
if dimensions.width == 0 || dimensions.height == 0 {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2020-01-23 07:37:12 +00:00
|
|
|
// It is important to call this function from time to time, otherwise resources will keep
|
|
|
|
// accumulating and you will eventually reach an out of memory error.
|
|
|
|
// Calling this function polls various fences in order to determine what the GPU has
|
|
|
|
// already processed, and frees the resources that are no longer needed.
|
|
|
|
previous_frame_end.as_mut().unwrap().cleanup_finished();
|
|
|
|
|
|
|
|
// Whenever the window resizes we need to recreate everything dependent on the window size.
|
|
|
|
// In this example that includes the swapchain, the framebuffers and the dynamic state viewport.
|
|
|
|
if recreate_swapchain {
|
2022-05-09 12:25:26 +00:00
|
|
|
// Use the new dimensions of the window.
|
2022-02-20 09:55:34 +00:00
|
|
|
|
2020-05-10 00:36:20 +00:00
|
|
|
let (new_swapchain, new_images) =
|
2022-02-20 09:55:34 +00:00
|
|
|
match swapchain.recreate(SwapchainCreateInfo {
|
2022-05-09 12:25:26 +00:00
|
|
|
image_extent: dimensions.into(),
|
2022-02-20 09:55:34 +00:00
|
|
|
..swapchain.create_info()
|
|
|
|
}) {
|
2020-05-10 00:36:20 +00:00
|
|
|
Ok(r) => r,
|
|
|
|
// This error tends to happen when the user is manually resizing the window.
|
|
|
|
// Simply restarting the loop is the easiest way to fix this issue.
|
2022-02-20 09:55:34 +00:00
|
|
|
Err(SwapchainCreationError::ImageExtentNotSupported { .. }) => return,
|
2020-05-10 00:36:20 +00:00
|
|
|
Err(e) => panic!("Failed to recreate swapchain: {:?}", e),
|
|
|
|
};
|
2020-01-23 07:37:12 +00:00
|
|
|
|
|
|
|
swapchain = new_swapchain;
|
|
|
|
// Because framebuffers contains an Arc on the old swapchain, we need to
|
|
|
|
// recreate framebuffers as well.
|
2020-05-10 00:36:20 +00:00
|
|
|
framebuffers = window_size_dependent_setup(
|
|
|
|
&new_images,
|
|
|
|
render_pass.clone(),
|
2021-08-27 06:24:16 +00:00
|
|
|
&mut viewport,
|
2020-05-10 00:36:20 +00:00
|
|
|
);
|
2020-01-23 07:37:12 +00:00
|
|
|
recreate_swapchain = false;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Before we can draw on the output, we have to *acquire* an image from the swapchain. If
|
|
|
|
// no image is available (which happens if you submit draw commands too quickly), then the
|
|
|
|
// function will block.
|
|
|
|
// This operation returns the index of the image that we are allowed to draw upon.
|
|
|
|
//
|
|
|
|
// This function can block if no image is available. The parameter is an optional timeout
|
|
|
|
// after which the function call will return an error.
|
2022-09-24 06:45:06 +00:00
|
|
|
let (image_index, suboptimal, acquire_future) =
|
2022-03-06 19:30:49 +00:00
|
|
|
match acquire_next_image(swapchain.clone(), None) {
|
2020-05-10 00:36:20 +00:00
|
|
|
Ok(r) => r,
|
|
|
|
Err(AcquireError::OutOfDate) => {
|
|
|
|
recreate_swapchain = true;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
Err(e) => panic!("Failed to acquire next image: {:?}", e),
|
|
|
|
};
|
2020-01-23 07:37:12 +00:00
|
|
|
|
2020-01-29 07:44:28 +00:00
|
|
|
// acquire_next_image can be successful, but suboptimal. This means that the swapchain image
|
|
|
|
// will still work, but it may not display correctly. With some drivers this can be when
|
|
|
|
// the window resizes, but it may not cause the swapchain to become out of date.
|
|
|
|
if suboptimal {
|
|
|
|
recreate_swapchain = true;
|
|
|
|
}
|
|
|
|
|
2020-01-23 07:37:12 +00:00
|
|
|
// In order to draw, we have to build a *command buffer*. The command buffer object holds
|
|
|
|
// the list of commands that are going to be executed.
|
|
|
|
//
|
|
|
|
// Building a command buffer is an expensive operation (usually a few hundred
|
|
|
|
// microseconds), but it is known to be a hot path in the driver and is expected to be
|
|
|
|
// optimized.
|
|
|
|
//
|
|
|
|
// Note that we have to pass a queue family when we create the command buffer. The command
|
|
|
|
// buffer will only be executable on that given queue family.
|
2021-04-26 14:53:18 +00:00
|
|
|
let mut builder = AutoCommandBufferBuilder::primary(
|
2020-05-10 00:36:20 +00:00
|
|
|
device.clone(),
|
2022-09-10 06:00:08 +00:00
|
|
|
queue.queue_family_index(),
|
2021-04-26 14:53:18 +00:00
|
|
|
CommandBufferUsage::OneTimeSubmit,
|
2020-05-10 00:36:20 +00:00
|
|
|
)
|
|
|
|
.unwrap();
|
|
|
|
|
2020-06-01 14:41:42 +00:00
|
|
|
builder
|
2022-04-24 01:16:19 +00:00
|
|
|
// Before we can draw, we have to *enter a render pass*.
|
2020-11-10 17:01:13 +00:00
|
|
|
.begin_render_pass(
|
2022-04-24 01:16:19 +00:00
|
|
|
RenderPassBeginInfo {
|
|
|
|
// A list of values to clear the attachments with. This list contains
|
|
|
|
// one item for each attachment in the render pass. In this case,
|
|
|
|
// there is only one attachment, and we clear it with a blue color.
|
|
|
|
//
|
|
|
|
// Only attachments that have `LoadOp::Clear` are provided with clear
|
|
|
|
// values, any others should use `ClearValue::None` as the clear value.
|
|
|
|
clear_values: vec![Some([0.0, 0.0, 1.0, 1.0].into())],
|
2022-09-24 06:45:06 +00:00
|
|
|
..RenderPassBeginInfo::framebuffer(
|
|
|
|
framebuffers[image_index as usize].clone(),
|
|
|
|
)
|
2022-04-24 01:16:19 +00:00
|
|
|
},
|
|
|
|
// The contents of the first (and only) subpass. This can be either
|
|
|
|
// `Inline` or `SecondaryCommandBuffers`. The latter is a bit more advanced
|
|
|
|
// and is not covered here.
|
2020-11-10 17:01:13 +00:00
|
|
|
SubpassContents::Inline,
|
|
|
|
)
|
2020-06-01 14:41:42 +00:00
|
|
|
.unwrap()
|
|
|
|
// We are now inside the first subpass of the render pass. We add a draw command.
|
|
|
|
//
|
|
|
|
// The last two parameters contain the list of resources to pass to the shaders.
|
|
|
|
// Since we used an `EmptyPipeline` object, the objects have to be `()`.
|
2021-08-27 06:24:16 +00:00
|
|
|
.set_viewport(0, [viewport.clone()])
|
|
|
|
.bind_pipeline_graphics(pipeline.clone())
|
|
|
|
.bind_vertex_buffers(0, vertex_buffer.clone())
|
|
|
|
.draw(vertex_buffer.len() as u32, 1, 0, 0)
|
2020-06-01 14:41:42 +00:00
|
|
|
.unwrap()
|
2022-05-29 16:53:36 +00:00
|
|
|
// We leave the render pass. Note that if we had multiple
|
|
|
|
// subpasses we could have called `next_subpass` to jump to the next subpass.
|
2020-06-01 14:41:42 +00:00
|
|
|
.end_render_pass()
|
|
|
|
.unwrap();
|
|
|
|
|
|
|
|
// Finish building the command buffer by calling `build`.
|
|
|
|
let command_buffer = builder.build().unwrap();
|
|
|
|
|
2020-05-10 00:36:20 +00:00
|
|
|
let future = previous_frame_end
|
|
|
|
.take()
|
|
|
|
.unwrap()
|
2020-01-23 07:37:12 +00:00
|
|
|
.join(acquire_future)
|
2020-05-10 00:36:20 +00:00
|
|
|
.then_execute(queue.clone(), command_buffer)
|
|
|
|
.unwrap()
|
2020-01-23 07:37:12 +00:00
|
|
|
// The color output is now expected to contain our triangle. But in order to show it on
|
|
|
|
// the screen, we have to *present* the image by calling `present`.
|
|
|
|
//
|
|
|
|
// This function does not actually present the image immediately. Instead it submits a
|
|
|
|
// present command at the end of the queue. This means that it will only be presented once
|
|
|
|
// the GPU has finished executing the command buffer that draws the triangle.
|
2022-09-17 07:38:32 +00:00
|
|
|
.then_swapchain_present(
|
|
|
|
queue.clone(),
|
2022-09-24 06:45:06 +00:00
|
|
|
SwapchainPresentInfo::swapchain_image_index(swapchain.clone(), image_index),
|
2022-09-17 07:38:32 +00:00
|
|
|
)
|
2020-01-23 07:37:12 +00:00
|
|
|
.then_signal_fence_and_flush();
|
|
|
|
|
|
|
|
match future {
|
|
|
|
Ok(future) => {
|
2020-05-12 23:05:09 +00:00
|
|
|
previous_frame_end = Some(future.boxed());
|
2020-05-10 00:36:20 +00:00
|
|
|
}
|
2020-01-23 07:37:12 +00:00
|
|
|
Err(FlushError::OutOfDate) => {
|
|
|
|
recreate_swapchain = true;
|
2020-05-12 23:05:09 +00:00
|
|
|
previous_frame_end = Some(sync::now(device.clone()).boxed());
|
2020-01-23 07:37:12 +00:00
|
|
|
}
|
|
|
|
Err(e) => {
|
|
|
|
println!("Failed to flush future: {:?}", e);
|
2020-05-12 23:05:09 +00:00
|
|
|
previous_frame_end = Some(sync::now(device.clone()).boxed());
|
2020-01-23 07:37:12 +00:00
|
|
|
}
|
|
|
|
}
|
2020-05-10 00:36:20 +00:00
|
|
|
}
|
|
|
|
_ => (),
|
2018-02-14 07:51:52 +00:00
|
|
|
}
|
2020-01-23 07:37:12 +00:00
|
|
|
});
|
2016-02-18 08:33:06 +00:00
|
|
|
}
|
2018-10-27 21:16:30 +00:00
|
|
|
|
2018-10-28 03:02:29 +00:00
|
|
|
/// This method is called once during initialization, then again whenever the window is resized
|
2018-10-27 21:16:30 +00:00
|
|
|
fn window_size_dependent_setup(
|
|
|
|
images: &[Arc<SwapchainImage<Window>>],
|
2021-04-10 11:09:03 +00:00
|
|
|
render_pass: Arc<RenderPass>,
|
2021-08-27 06:24:16 +00:00
|
|
|
viewport: &mut Viewport,
|
2021-11-02 20:33:58 +00:00
|
|
|
) -> Vec<Arc<Framebuffer>> {
|
|
|
|
let dimensions = images[0].dimensions().width_height();
|
2021-08-27 06:24:16 +00:00
|
|
|
viewport.dimensions = [dimensions[0] as f32, dimensions[1] as f32];
|
2020-05-10 00:36:20 +00:00
|
|
|
|
|
|
|
images
|
|
|
|
.iter()
|
|
|
|
.map(|image| {
|
2022-02-27 06:18:14 +00:00
|
|
|
let view = ImageView::new_default(image.clone()).unwrap();
|
2022-02-20 00:14:16 +00:00
|
|
|
Framebuffer::new(
|
|
|
|
render_pass.clone(),
|
|
|
|
FramebufferCreateInfo {
|
|
|
|
attachments: vec![view],
|
|
|
|
..Default::default()
|
|
|
|
},
|
|
|
|
)
|
|
|
|
.unwrap()
|
2020-05-10 00:36:20 +00:00
|
|
|
})
|
|
|
|
.collect::<Vec<_>>()
|
2018-10-27 21:16:30 +00:00
|
|
|
}
|