From 6743fe8fddf02cc09ec4aad33dd59070fdb91d03 Mon Sep 17 00:00:00 2001 From: Florian RICHER Date: Wed, 11 Dec 2024 14:03:40 +0100 Subject: [PATCH] Remove comment --- src/renderer/app.rs | 141 --------------------------------- src/renderer/render_context.rs | 55 +------------ src/renderer/scene.rs | 64 --------------- 3 files changed, 1 insertion(+), 259 deletions(-) diff --git a/src/renderer/app.rs b/src/renderer/app.rs index 55c6a31..fdf3ce2 100644 --- a/src/renderer/app.rs +++ b/src/renderer/app.rs @@ -30,16 +30,8 @@ impl App { pub fn new(event_loop: &EventLoop<()>) -> Self { let library = VulkanLibrary::new().unwrap(); - // The first step of any Vulkan program is to create an instance. - // - // 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 `Surface` for the list of extensions required to draw - // to a window. let required_extensions = Surface::required_extensions(event_loop).unwrap(); - // Now creating the instance. let instance = Instance::new( library, InstanceCreateInfo { @@ -57,69 +49,31 @@ impl App { ) .unwrap(); - // 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 mut device_extensions = DeviceExtensions { khr_swapchain: true, ..DeviceExtensions::empty() }; - // 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. let (physical_device, queue_family_index) = instance .enumerate_physical_devices() .unwrap() .filter(|p| { - // For this example, we require at least Vulkan 1.3, or a device that has the - // `khr_dynamic_rendering` extension available. p.api_version() >= Version::V1_3 || p.supported_extensions().khr_dynamic_rendering }) .filter(|p| { - // 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. p.supported_extensions().contains(&device_extensions) }) .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-world 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. p.queue_family_properties() .iter() .enumerate() .position(|(i, q)| { - // 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. q.queue_flags.intersects(QueueFlags::GRAPHICS) && p.presentation_support(i as u32, event_loop).unwrap() }) - // 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. .map(|i| (p, i as u32)) }) - // 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-world setting, you may want to use the best-scoring device only as a - // "default" or "recommended" device, and let the user choose the device themself. .min_by_key(|(p, _)| { - // We assign a lower score to device types that are likely to be faster/better. match p.properties().device_type { PhysicalDeviceType::DiscreteGpu => 0, PhysicalDeviceType::IntegratedGpu => 1, @@ -131,68 +85,36 @@ impl App { }) .expect("no suitable physical device found"); - // Some little debug infos. println!( "Using device: {} (type: {:?})", physical_device.properties().device_name, physical_device.properties().device_type, ); - // If the selected device doesn't have Vulkan 1.3 available, then we need to enable the - // `khr_dynamic_rendering` extension manually. This extension became a core part of Vulkan - // in version 1.3 and later, so it's always available then and it does not need to be - // enabled. We can be sure that this extension will be available on the selected physical - // device, because we filtered out unsuitable devices in the device selection code above. if physical_device.api_version() < Version::V1_3 { device_extensions.khr_dynamic_rendering = true; } - // Now initializing the device. This is probably the most important object of Vulkan. - // - // An iterator of created queues is returned by the function alongside the device. let (device, mut queues) = Device::new( - // Which physical device to connect to. physical_device, DeviceCreateInfo { - // The list of queues that we are going to use. Here we only use one queue, from - // the previously chosen queue family. queue_create_infos: vec![QueueCreateInfo { queue_family_index, ..Default::default() }], - - // 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 things we are going to - // need are the `khr_swapchain` extension that allows us to draw to a window, and - // `khr_dynamic_rendering` if we don't have Vulkan 1.3 available. enabled_extensions: device_extensions, - - // In order to render with Vulkan 1.3's dynamic rendering, we need to enable it - // here. Otherwise, we are only allowed to render with a render pass object, as in - // the standard triangle example. The feature is required to be supported by the - // device if it supports Vulkan 1.3 and higher, or if the `khr_dynamic_rendering` - // extension is available, so we don't need to check for support. enabled_features: DeviceFeatures { dynamic_rendering: true, ..DeviceFeatures::empty() }, - ..Default::default() }, ) .unwrap(); - // 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 iterator. let queue = queues.next().unwrap(); - let memory_allocator = Arc::new(StandardMemoryAllocator::new_default(device.clone())); - // Before we can start creating and recording command buffers, we need a way of allocating - // them. Vulkano provides a command buffer allocator, which manages raw Vulkan command - // pools underneath and provides a safe interface for them. let command_buffer_allocator = Arc::new(StandardCommandBufferAllocator::new( device.clone(), Default::default(), @@ -245,21 +167,12 @@ impl ApplicationHandler for App { WindowEvent::RedrawRequested => { let window_size = rcx.window.inner_size(); - // Do not draw the frame when the screen size is zero. On Windows, this can occur - // when minimizing the application. if window_size.width == 0 || window_size.height == 0 { return; } - // 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. rcx.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 rcx.recreate_swapchain { let (new_swapchain, new_images) = rcx .swapchain @@ -270,23 +183,11 @@ impl ApplicationHandler for App { .expect("failed to recreate swapchain"); rcx.swapchain = new_swapchain; - - // Now that we have new swapchain images, we must create new image views from - // them as well. rcx.attachment_image_views = window_size_dependent_setup(&new_images); - rcx.viewport.extent = window_size.into(); - rcx.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. let (image_index, suboptimal, acquire_future) = match acquire_next_image( rcx.swapchain.clone(), None, @@ -301,23 +202,10 @@ impl ApplicationHandler for App { Err(e) => panic!("failed to acquire next image: {e}"), }; - // `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 { rcx.recreate_swapchain = true; } - // In order to draw, we have to record a *command buffer*. The command buffer - // object holds the list of commands that are going to be executed. - // - // Recording 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. let mut builder = AutoCommandBufferBuilder::primary( self.command_buffer_allocator.clone(), self.queue.queue_family_index(), @@ -326,37 +214,18 @@ impl ApplicationHandler for App { .unwrap(); builder - // Before we can draw, we have to *enter a render pass*. We specify which - // attachments we are going to use for rendering here, which needs to match - // what was previously specified when creating the pipeline. .begin_rendering(RenderingInfo { - // As before, we specify one color attachment, but now we specify the image - // view to use as well as how it should be used. color_attachments: vec![Some(RenderingAttachmentInfo { - // `Clear` means that we ask the GPU to clear the content of this - // attachment at the start of rendering. load_op: AttachmentLoadOp::Clear, - // `Store` means that we ask the GPU to store the rendered output in - // the attachment image. We could also ask it to discard the result. store_op: AttachmentStoreOp::Store, - // The value to clear the attachment with. Here we clear it with a blue - // color. - // - // Only attachments that have `AttachmentLoadOp::Clear` are provided - // with clear values, any others should use `None` as the clear value. clear_value: Some([0.0, 0.0, 0.0, 1.0].into()), ..RenderingAttachmentInfo::image_view( - // We specify image view corresponding to the currently acquired - // swapchain image, to use for this attachment. rcx.attachment_image_views[image_index as usize].clone(), ) })], ..Default::default() }) .unwrap() - // We are now inside the first subpass of the render pass. - // - // TODO: Document state setting and how it affects subsequent draw commands. .set_viewport(0, [rcx.viewport.clone()].into_iter().collect()) .unwrap(); @@ -365,11 +234,9 @@ impl ApplicationHandler for App { } builder - // We leave the render pass. .end_rendering() .unwrap(); - // Finish recording the command buffer by calling `end`. let command_buffer = builder.build().unwrap(); let future = rcx @@ -379,14 +246,6 @@ impl ApplicationHandler for App { .join(acquire_future) .then_execute(self.queue.clone(), command_buffer) .unwrap() - // 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 - // `then_swapchain_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. .then_swapchain_present( self.queue.clone(), SwapchainPresentInfo::swapchain_image_index( diff --git a/src/renderer/render_context.rs b/src/renderer/render_context.rs index 6ae9301..097479e 100644 --- a/src/renderer/render_context.rs +++ b/src/renderer/render_context.rs @@ -22,56 +22,26 @@ impl RenderContext { pub fn new(window: Arc, surface: Arc, device: &Arc) -> Self { let window_size = window.inner_size(); - - // Before we can draw on the surface, we have to create what is called a swapchain. - // Creating a swapchain allocates the color buffers that will contain the image that will - // ultimately be visible on the screen. These images are returned alongside the swapchain. let (swapchain, images) = { - // Querying the capabilities of the surface. When we create the swapchain we can only - // pass values that are allowed by the capabilities. let surface_capabilities = device .physical_device() .surface_capabilities(&surface, Default::default()) .unwrap(); - // Choosing the internal format that the images will have. let (image_format, _) = device .physical_device() .surface_formats(&surface, Default::default()) .unwrap()[0]; - // Please take a look at the docs for the meaning of the parameters we didn't mention. Swapchain::new( device.clone(), surface, SwapchainCreateInfo { - // Some drivers report an `min_image_count` of 1, but fullscreen mode requires - // at least 2. Therefore we must ensure the count is at least 2, otherwise the - // program would crash when entering fullscreen mode on those drivers. + // 2 because with some graphics driver, it crash on fullscreen because fullscreen need to min image to works. min_image_count: surface_capabilities.min_image_count.max(2), - image_format, - - // The size of the window, only used to initially setup the swapchain. - // - // NOTE: - // On some drivers the swapchain extent is specified by - // `surface_capabilities.current_extent` and the swapchain size must use this - // extent. This extent is always the same as the window size. - // - // 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 size. - // - // Both of these cases need the swapchain to use the window size, so we just - // use that. image_extent: window_size.into(), - image_usage: ImageUsage::COLOR_ATTACHMENT, - - // 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 .into_iter() @@ -84,38 +54,15 @@ impl RenderContext { .unwrap() }; - // When creating the swapchain, we only created plain images. To use them as an attachment - // for rendering, we must wrap then in an image view. - // - // Since we need to draw to multiple images, we are going to create a different image view - // for each image. let attachment_image_views = window_size_dependent_setup(&images); - // Dynamic viewports allow us to recreate just the viewport when the window is resized. - // Otherwise we would have to recreate the whole pipeline. let viewport = Viewport { offset: [0.0, 0.0], extent: window_size.into(), depth_range: 0.0..=1.0, }; - // 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 recreate_swapchain = false; - - // In the loop below we are going to submit commands to the GPU. Submitting a command - // produces an object that implements the `GpuFuture` trait, which holds the resources for - // as long as they are in use by the GPU. - // - // Destroying the `GpuFuture` blocks until the GPU is finished executing it. In order to - // avoid that, we store the submission of the previous frame here. let previous_frame_end = Some(sync::now(device.clone()).boxed()); Self { diff --git a/src/renderer/scene.rs b/src/renderer/scene.rs index f982963..5b76973 100644 --- a/src/renderer/scene.rs +++ b/src/renderer/scene.rs @@ -34,21 +34,6 @@ pub struct Scene { impl Scene { pub fn initialize(device: &Arc, swapchain: &Arc, memory_allocator: &Arc) -> Scene { - // The next step is to create the shaders. - // - // 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` option of - // the macro. - // - // The items generated by the `shader!` macro include 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. - // - // 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/ mod vs { vulkano_shaders::shader! { ty: "vertex", @@ -63,16 +48,7 @@ impl Scene { } } - // Before we draw, we have to create what is called a **pipeline**. A pipeline describes - // how a GPU operation is to be performed. It is similar to an OpenGL program, but it also - // contains many settings for customization, all baked into a single object. For drawing, - // we create a **graphics** pipeline, but there are also other types of pipeline. let pipeline = { - // First, we load the shaders that the pipeline will use: the vertex shader and the - // fragment shader. - // - // A Vulkan shader can in theory contain multiple entry points, so we have to specify - // which one. let vs = vs::load(device.clone()) .unwrap() .entry_point("main") @@ -82,78 +58,40 @@ impl Scene { .entry_point("main") .unwrap(); - // Automatically generate a vertex input state from the vertex shader's input - // interface, that takes a single vertex buffer containing `Vertex` structs. let vertex_input_state = MyVertex::per_vertex().definition(&vs).unwrap(); - // Make a list of the shader stages that the pipeline will have. let stages = [ PipelineShaderStageCreateInfo::new(vs), PipelineShaderStageCreateInfo::new(fs), ]; - // We must now create a **pipeline layout** object, which describes the locations and - // types of descriptor sets and push constants used by the shaders in the pipeline. - // - // Multiple pipelines can share a common layout object, which is more efficient. The - // shaders in a pipeline must use a subset of the resources described in its pipeline - // layout, but the pipeline layout is allowed to contain resources that are not present - // in the shaders; they can be used by shaders in other pipelines that share the same - // layout. Thus, it is a good idea to design shaders so that many pipelines have common - // resource locations, which allows them to share pipeline layouts. let layout = PipelineLayout::new( device.clone(), - // Since we only have one pipeline in this example, and thus one pipeline layout, - // we automatically generate the creation info for it from the resources used in - // the shaders. In a real application, you would specify this information manually - // so that you can re-use one layout in multiple pipelines. PipelineDescriptorSetLayoutCreateInfo::from_stages(&stages) .into_pipeline_layout_create_info(device.clone()) .unwrap(), ) .unwrap(); - // We describe the formats of attachment images where the colors, depth and/or stencil - // information will be written. The pipeline will only be usable with this particular - // configuration of the attachment images. let subpass = PipelineRenderingCreateInfo { - // We specify a single color attachment that will be rendered to. When we begin - // rendering, we will specify a swapchain image to be used as this attachment, so - // here we set its format to be the same format as the swapchain. color_attachment_formats: vec![Some(swapchain.image_format())], ..Default::default() }; - // Finally, create the pipeline. GraphicsPipeline::new( device.clone(), None, GraphicsPipelineCreateInfo { stages: stages.into_iter().collect(), - // How vertex data is read from the vertex buffers into the vertex shader. vertex_input_state: Some(vertex_input_state), - // How vertices are arranged into primitive shapes. The default primitive shape - // is a triangle. input_assembly_state: Some(InputAssemblyState::default()), - // How primitives are transformed and clipped to fit the framebuffer. We use a - // resizable viewport, set to draw over the entire window. viewport_state: Some(ViewportState::default()), - // How polygons are culled and converted into a raster of pixels. The default - // value does not perform any culling. rasterization_state: Some(RasterizationState::default()), - // How multiple fragment shader samples are converted to a single pixel value. - // The default value does not perform any multisampling. multisample_state: Some(MultisampleState::default()), - // How pixel values are combined with the values already present in the - // framebuffer. The default value overwrites the old value with the new one, - // without any blending. color_blend_state: Some(ColorBlendState::with_attachment_states( subpass.color_attachment_formats.len() as u32, ColorBlendAttachmentState::default(), )), - // Dynamic states allows us to specify parts of the pipeline settings when - // recording the command buffer, before we perform drawing. Here, we specify - // that the viewport should be dynamic. dynamic_state: [DynamicState::Viewport].into_iter().collect(), subpass: Some(subpass.into()), ..GraphicsPipelineCreateInfo::layout(layout) @@ -162,7 +100,6 @@ impl Scene { .unwrap() }; - // We now create a buffer that will store the shape of our triangle. let vertices = [ // Triangle en haut à gauche MyVertex { @@ -247,7 +184,6 @@ impl Scene { .bind_vertex_buffers(0, self.vertex_buffer.clone()) .unwrap(); - // We add a draw command. let vertex_count = self.vertex_buffer.len() as u32; let instance_count = vertex_count / 3;