|
31 | 31 | //! |
32 | 32 | //! There are two levels of command buffers: |
33 | 33 | //! |
34 | | -//! - [`PrimaryCommandBuffer`] can be executed on a queue, and is the main command buffer type. |
35 | | -//! It cannot be executed within another command buffer. |
36 | | -//! - [`SecondaryCommandBuffer`] can only be executed within a primary command buffer, not directly |
37 | | -//! on a queue. |
| 34 | +//! - [`PrimaryCommandBufferAbstract`] can be executed on a queue, and is the main command buffer |
| 35 | +//! type. It cannot be executed within another command buffer. |
| 36 | +//! - [`SecondaryCommandBufferAbstract`] can only be executed within a primary command buffer, |
| 37 | +//! not directly on a queue. |
38 | 38 | //! |
39 | 39 | //! Using secondary command buffers, there is slightly more overhead than using primary command |
40 | 40 | //! buffers alone, but there are also advantages. A single command buffer cannot be recorded |
|
48 | 48 | //! # Recording a command buffer |
49 | 49 | //! |
50 | 50 | //! To record a new command buffer, the most direct way is to create a new |
51 | | -//! [`CommandBufferBuilder`]. You can then call methods on this object to record new commands to |
| 51 | +//! [`AutoCommandBufferBuilder`]. You can then call methods on this object to record new commands to |
52 | 52 | //! the command buffer. When you are done recording, you call [`build`] to finalise the command |
53 | | -//! buffer and turn it into either a [`PrimaryCommandBuffer`] or a [`SecondaryCommandBuffer`]. |
| 53 | +//! buffer and turn it into either a [`PrimaryCommandBufferAbstract`] or a |
| 54 | +//! [`SecondaryCommandBufferAbstract`]. |
54 | 55 | //! |
55 | | -//! Using the standard `CommandBufferBuilder`, you must enter synchronization commands such as |
56 | | -//! [pipeline barriers], to ensure that there are no races and memory access hazards. This can be |
57 | | -//! difficult to do manually, so Vulkano also provides an alternative builder, |
58 | | -//! [`AutoCommandBufferBuilder`]. Using this builder, you do not have to worry about managing |
59 | | -//! synchronization, but the end result may not be quite as efficient. |
| 56 | +// //! Using the standard `CommandBufferBuilder`, you must enter synchronization commands such as |
| 57 | +// //! [pipeline barriers], to ensure that there are no races and memory access hazards. This can be |
| 58 | +// //! difficult to do manually, so Vulkano also provides an alternative builder, |
| 59 | +// //! [`AutoCommandBufferBuilder`]. Using this builder, you do not have to worry about managing |
| 60 | +// //! synchronization, but the end result may not be quite as efficient. |
60 | 61 | //! |
61 | 62 | //! # Submitting a primary command buffer |
62 | 63 | //! |
|
108 | 109 | //! [`GpuFuture`]: crate::sync::GpuFuture |
109 | 110 |
|
110 | 111 | #[doc(no_inline)] |
111 | | -pub use self::standard::{CommandBufferBuilder, PrimaryCommandBuffer, SecondaryCommandBuffer}; |
| 112 | +pub(crate) use self::standard::{PrimaryCommandBuffer, SecondaryCommandBuffer}; |
112 | 113 | pub use self::{ |
113 | 114 | auto::{ |
114 | 115 | AutoCommandBufferBuilder, BuildError, CommandBufferBeginError, PrimaryAutoCommandBuffer, |
@@ -154,7 +155,7 @@ pub mod allocator; |
154 | 155 | mod auto; |
155 | 156 | mod commands; |
156 | 157 | pub mod pool; |
157 | | -pub mod standard; |
| 158 | +pub(crate) mod standard; |
158 | 159 | pub mod synced; |
159 | 160 | pub mod sys; |
160 | 161 | mod traits; |
|
0 commit comments