1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92

// Copyright (c) 2016 The vulkano developers
// Licensed under the Apache License, Version 2.0
// <LICENSE-APACHE or
// http://www.apache.org/licenses/LICENSE-2.0> or the MIT
// license <LICENSE-MIT or http://opensource.org/licenses/MIT>,
// at your option. All files in the project carrying such
// notice may not be copied, modified, or distributed except
// according to those terms.

//! Targets on which your draw commands are executed.
//! 
//! # Render passes and framebuffers
//!
//! There are two concepts in Vulkan:
//! 
//! - A `RenderPass` is a collection of one or multiples passes called subpasses. Each subpass
//!   contains the format and dimensions of the attachments that are part of the subpass. The
//!   render pass only defines the layout of the rendering process.
//! - A `Framebuffer` contains the list of actual images that are attached. It is created from a
//!   render pass and has to match its characteristics.
//!
//! You can create graphics pipelines from a render pass object alone.
//! A `Framebuffer` is only needed when you add draw commands to a command buffer.
//!
//! # Render passes
//!
//! In vulkano, a render pass is any object that implements the `RenderPass` trait.
//!
//! You can create a render pass by creating a `UnsafeRenderPass` object. But as its name tells,
//! it is unsafe because a lot of safety checks aren't performed.
//!
//! Instead you are encouraged to use a safe wrapper around an `UnsafeRenderPass`.
//! There are two ways to do this:   TODO add more ways
//!
//! - Creating an instance of an `EmptySinglePassRenderPass`, which describes a render pass with no
//!   attachment and with one subpass.
//! - Using the `single_pass_renderpass!` macro. See the documentation of this macro.
//!
//! Render passes have three characteristics:
//!
//! - A list of attachments with their format.
//! - A list of subpasses, that defines for each subpass which attachment is used for which
//!   purpose.
//! - A list of dependencies between subpasses. Vulkan implementations are free to reorder the
//!   subpasses, which means that you need to declare dependencies if the output of a subpass
//!   needs to be read in a following subpass.
//!
//! ## Example
//!
//! With `EmptySinglePassRenderPass`:
//!
//! ```no_run
//! use vulkano::framebuffer::EmptySinglePassRenderPass;
//!
//! # let device: std::sync::Arc<vulkano::device::Device> = unsafe { ::std::mem::uninitialized() };
//! let renderpass = EmptySinglePassRenderPass::new(&device);
//! ```
//!
//! # Framebuffers
//!
//! Creating a framebuffer is done by passing the render pass object, the dimensions of the
//! framebuffer, and the list of attachments to `Framebuffer::new()`.
//!
//! The slightly tricky part is that the type that contains the list of attachments depends on
//! the trait implementation of `RenderPass`. For example if you use an
//! `EmptySinglePassRenderPass`, you have to pass `()` for the list of attachments.
//!

pub use self::empty::EmptySinglePassRenderPass;
pub use self::framebuffer::Framebuffer;
pub use self::framebuffer::FramebufferCreationError;
pub use self::sys::UnsafeRenderPass;
pub use self::sys::RenderPassCreationError;
pub use self::traits::RenderPass;
pub use self::traits::RenderPassDesc;
pub use self::traits::RenderPassAttachmentsList;
pub use self::traits::RenderPassClearValues;
pub use self::traits::RenderPassCompatible;
pub use self::traits::RenderPassSubpassInterface;
pub use self::traits::LayoutAttachmentDescription;
pub use self::traits::LayoutPassDescription;
pub use self::traits::LayoutPassDependencyDescription;
pub use self::traits::StoreOp;
pub use self::traits::LoadOp;
pub use self::traits::Subpass;

#[macro_use]
mod macros;
mod empty;
mod framebuffer;
mod sys;
#[doc(hidden)] pub mod traits;      // TODO: pub-hidden because of that trait visibility bug