ko-translate rendering

CDDing · CDDing · commit 94dc44023f44 · 2025-04-22T01:44:32.000+09:00
diff --git a/guide/translations/ko-KR/src/rendering/README.md b/guide/translations/ko-KR/src/rendering/README.md
@@ -1,3 +1,3 @@
-# Rendering
+# 렌더링
 
-This section implements Render Sync, the Swapchain loop, performs Swapchain image layout transitions, and introduces [Dynamic Rendering](https://docs.vulkan.org/samples/latest/samples/extensions/dynamic_rendering/README.html). Originally Vulkan only supported [Render Passes](https://docs.vulkan.org/tutorial/latest/03_Drawing_a_triangle/02_Graphics_pipeline_basics/03_Render_passes.html), which are quite verbose to setup, require somewhat confusing subpass dependencies, and are ironically _less_ explicit: they can perform implicit layout transitions on their framebuffer attachments. They are also tightly coupled to Graphics Pipelines, you need a separate pipeline object for each Render Pass, even if they are identical in all other respects. This RenderPass/Subpass model was primarily beneficial for GPUs with tiled renderers, and in Vulkan 1.3 Dynamic Rendering was promoted to the core API (previously it was an extension) as an alternative to using Render Passes.
+여기서는 렌더 싱크, 스왑체인 루프의 구현, 스왑체인 이미지의 레이아웃 전환을 수행하고, [동적 렌더링(Dynamic Rendering)](https://docs.vulkan.org/samples/latest/samples/extensions/dynamic_rendering/README.html)을 소개합니다. 초기 Vulkan은 [렌더 패스(Render Passes)](https://docs.vulkan.org/tutorial/latest/03_Drawing_a_triangle/02_Graphics_pipeline_basics/03_Render_passes.html)만을 지원했습니다. 렌더 패스는 설정이 장황하고, (subpass 의존성 같은) 다소 혼란스러운 요소들을 요구하며, 아이러니하게도 오히려 명시적이지 않은 부분이 있습니다. 예를 들어 렌더패스는 프레임버퍼 어태치먼트의 레이아웃을 암시적으로 전환할 수 있습니다. 또한 렌더 패스는 그래픽스 파이프라인과 밀접하게 결합되어 있어, 다른 모든 조건이 같더라도 렌더 패스마다 별도의 파이프라인 객체가 필요합니다. 이 렌더 패스/서브 패스 모델은 타일 기반 렌더러를 사용하는 GPU에 주로 유리한 모델이었습니다. 그리고 Vulkan 1.3에서는 동적 렌더링이 렌더 패스를 대체하는 핵심 API로 부상했습니다(이전에는 확장일 뿐이었습니다).
diff --git a/guide/translations/ko-KR/src/rendering/dynamic_rendering.md b/guide/translations/ko-KR/src/rendering/dynamic_rendering.md
@@ -1,8 +1,8 @@
-# Dynamic Rendering
+# 동적 렌더링
 
-Dynamic Rendering enables us to avoid using Render Passes, which are quite a bit more verbose (but also generally more performant on tiled GPUs). Here we tie together the Swapchain, Render Sync, and rendering. We are not ready to actually render anything yet, but can clear the image to a particular color.
+동적 렌더링을 활성화하면 비교적 복잡한 렌더 패스를 사용하지 않아도 됩니다. 다만 렌더 패스는 타일 기반 GPU에서 조금 더 이점을 갖습니다. 여기서는 스왑체인, 렌더 싱크, 그리고 렌더링 자체를 하나로 묶는 작업을 진행하겠습니다. 아직 실제로 화면에 무언가를 렌더링할 준비가 된 것은 아니지만, 특정 색상으로 이미지를 초기화할 수는 있습니다.
 
-Add these new members to `App`:
+아래와 같은 멤버를 `App`에 추가하겠습니다.
 
 ```cpp
 auto acquire_render_target() -> bool;
@@ -17,7 +17,7 @@ glm::ivec2 m_framebuffer_size{};
 std::optional<RenderTarget> m_render_target{};
 ```
 
-The main loop can now use these to implement the Swapchain and rendering loop:
+이제 메인 루프는 이 멤버들을 활용하여 스왑체인과 렌더링 루프를 구현할 수 있습니다.
 
 ```cpp
 while (glfwWindowShouldClose(m_window.get()) == GLFW_FALSE) {
@@ -31,7 +31,7 @@ while (glfwWindowShouldClose(m_window.get()) == GLFW_FALSE) {
 }
 ```
 
-Before acquiring a Swapchain image, we need to wait for the current frame's fence. If acquisition is successful, reset the fence ('un'signal it):
+스왑체인 이미지를 받아오기 전에, 현재 프레임의 펜스를 대기해야 합니다. 이미지를 받아오는 것이 성공하면 해당 펜스를 리셋(unsignal)합니다.
 
 ```cpp
 auto App::acquire_render_target() -> bool {
@@ -67,7 +67,7 @@ auto App::acquire_render_target() -> bool {
 }
 ```
 
-Since the fence has been reset, a queue submission must be made that signals it before continuing, otherwise the app will deadlock on the next wait (and eventually throw after 3s). Begin Command Buffer recording:
+펜스가 리셋되었기 때문에, 다음 동작을 진행하기 전에 해당 펜스를 signal하도록 반드시 큐에 커맨드 버퍼가 제출되어야 합니다. 그렇지 않으면 다음 루프에서 펜스를 기다리는 과정에서 교착 상태에 빠지고, 결국 3초 후 예외가 발생하게 됩니다. 이제 커맨드 버퍼 기록을 시작하겠습니다.
 
 ```cpp
 auto App::begin_frame() -> vk::CommandBuffer {
@@ -81,7 +81,7 @@ auto App::begin_frame() -> vk::CommandBuffer {
 }
 ```
 
-Transition the image for rendering, ie Attachment Optimal layout. Set up the image barrier and record it:
+렌더링에 사용할 이미지의 레이아웃을 AttachmentOptimal 레이아웃으로 전환합니다. 이를 위해 이미지 배리어를 설정하고 커맨드 버퍼에 기록합니다.
 
 ```cpp
 void App::transition_for_render(vk::CommandBuffer const command_buffer) const {
@@ -102,7 +102,7 @@ void App::transition_for_render(vk::CommandBuffer const command_buffer) const {
 }
 ```
 
-Create a Rendering Attachment Info using the acquired image as the color target. We use a red clear color, make sure the Load Op clears the image, and Store Op stores the results (currently just the cleared image). Set up a Rendering Info object with the color attachment and the entire image as the render area. Finally, execute the render:
+받아온 이미지를 색상 타겟으로 사용하는 RenderingAttachmentInfo를 생성합니다. 빨간 색을 초기화 색상으로 사용하고, LoadOp가 이미지를 초기화하며, StoreOp는 결과를 담도록 해야 합니다(현재는 초기화된 이미지만 저장합니다). 이 colorAttachment와 전체 이미지를 렌더링 영역으로 설정한 RenderingInfo 구조체를 생성합니다. 마지막으로 렌더링을 실행합니다.
 
 ```cpp
 void App::render(vk::CommandBuffer const command_buffer) {
@@ -126,7 +126,7 @@ void App::render(vk::CommandBuffer const command_buffer) {
 }
 ```
 
-Transition the image for presentation:
+렌더링이 끝나면 이미지를 표시하기 위해 레이아웃을 전환합니다.
 
 ```cpp
 void App::transition_for_present(vk::CommandBuffer const command_buffer) const {
@@ -147,7 +147,7 @@ void App::transition_for_present(vk::CommandBuffer const command_buffer) const {
 }
 ```
 
-End the command buffer and submit it. The `draw` Semaphore will be signaled by the Swapchain when the image is ready, which will trigger this command buffer's execution. It will signal the `present` Semaphore and `drawn` Fence on completion, with the latter being waited on the next time this virtual frame is processed. Finally, we increment the frame index, pass the `present` semaphore as the one for the subsequent present operation to wait on:
+커맨드 버퍼를 끝내고(End) 이를 제출합니다. 스왑체인 이미지를 사용할 준비가 되면 `draw`세마포어가 시그널 되고, 이로 인해 커맨드 버퍼가 실행됩니다. 렌더링이 완료되면 `present` 세마포어와 `drawn` 펜스가 시그널됩니다. 이후 동일한 가상 프레임이 다시 처리될 때 이 펜스를 기다리게 됩니다. 마지막으로 프레임 인덱스를 증가시키고, 다음 표시 작업이 대기할 수 있도록 `present` 세마포어를 전달합니다.
 
 ```cpp
 void App::submit_and_present() {
@@ -183,19 +183,19 @@ void App::submit_and_present() {
 }
 ```
 
-> Wayland users: congratulaions, you can finally see and interact with the window!
+> Wayland 사용자라면 이제 마침내 창과 상호작용할 수 있습니다!
 
 ![Cleared Image](./dynamic_rendering_red_clear.png)
 
-## Render Doc on Wayland
+## Wayland에서의 RenderDoc
 
-At the time of writing, RenderDoc doesn't support inspecting Wayland applications. Temporarily force X11 (XWayland) by calling `glfwInitHint()` before `glfwInit()`:
+이 글을 작성하는 시점에서는 RenderDoc이 Wayland 애플리케이션을 지원하지 않습니다. `glfwInit()` 이전에 `glfwInitHint()`를 호출하여 임시로 X11(XWayland)를 사용하도록 강제할 수 있습니다.
 
 ```cpp
 glfwInitHint(GLFW_PLATFORM, GLFW_PLATFORM_X11);
 ```
 
-Setting up a command line option to conditionally call this is a simple and flexible approach: just set that argument in RenderDoc itself and/or pass it whenever an X11 backend is desired:
+커맨드라인 옵션을 활용해 이 설정을 조건적으로 적용하는 것이 간단하고 유연한 방식입니다. RenderDoc에서 해당 인자를 설정하거나, X11 백엔드를 사용하고자 할 때마다 넘겨주는 식으로 처리하면 됩니다.
 
 ```cpp
 // main.cpp
diff --git a/guide/translations/ko-KR/src/rendering/render_sync.md b/guide/translations/ko-KR/src/rendering/render_sync.md
@@ -1,6 +1,6 @@
-# Render Sync
+# 렌더 싱크
 
-Create a new header `resource_buffering.hpp`:
+새로운 헤더 `resource_buffering.hpp`를 생성합니다.
 
 ```cpp
 // Number of virtual frames.
@@ -11,7 +11,7 @@ template <typename Type>
 using Buffered = std::array<Type, buffering_v>;
 ```
 
-Add a private `struct RenderSync` to `App`:
+`App`에 private 멤버 `struct RenderSync`를 추가합니다.
 
 ```cpp
 struct RenderSync {
@@ -26,7 +26,7 @@ struct RenderSync {
 };
 ```
 
-Add the new members associated with the Swapchain loop:
+스왑체인 루프와 관련있는 새로운 멤버를 추가합니다.
 
 ```cpp
 // command pool for all render Command Buffers.
@@ -37,7 +37,7 @@ Buffered<RenderSync> m_render_sync{};
 std::size_t m_frame_index{};
 ```
 
-Add, implement, and call the create function:
+생성 함수를 추가하고, 구현한 다음 호출합니다.
 
 ```cpp
 void App::create_render_sync() {
diff --git a/guide/translations/ko-KR/src/rendering/swapchain_loop.md b/guide/translations/ko-KR/src/rendering/swapchain_loop.md
@@ -1,28 +1,30 @@
-# Swapchain Loop
+# 스왑체인 루프
 
-One part of rendering in the main loop is the Swapchain loop, which at a high level comprises of these steps:
+렌더링 루프의 핵심 요소 중 하나는 스왑체인 루프입니다. 이는 다음과 같은 고수준 단계로 구성됩니다.
 
-1. Acquire a Swapchain Image
-1. Render to the acquired Image
-1. Present the Image (this releases the image back to the Swapchain)
+1. 스왑체인으로부터 이미지를 받아옵니다.
+2. 받아온 이미지에 렌더링합니다.
+3. 렌더링이 끝난 이미지를 표시합니다(이미지를 다시 스왑체인으로 돌려줍니다).
 
 ![WSI Engine](./wsi_engine.png)
 
-There are a few nuances to deal with, for instance:
+여기서 몇 가지 고려해야할 점이 있습니다.
 
-1. Acquiring (and/or presenting) will sometimes fail (eg because the Swapchain is out of date), in which case the remaining steps need to be skipped
-1. The acquire command can return before the image is actually ready for use, rendering needs to be synchronized to only start after the image is ready
-1. Similarly, presentation needs to be synchronized to only occur after rendering has completed
-1. The images need appropriate Layout Transitions at each stage
+1. 이미지를 받아오거나 표시하는 과정은 실패할 수 있습니다(스왑체인을 사용할 수 없는 경우). 이 때 남은 단계들은 생략해야 합니다.
+2. 받아오는 명령은 이미지가 실제로 사용할 준비가 되기 전에 반환될 수 있으며, 렌더링은 해당 이미지를 받아온 이후에 시작하도록 동기화되어야 합니다.
+3. 마찬가지로, 표시하는 작업 또한 렌더링이 끝난 이후에 수행되도록 동기화해야 합니다.
+4. 이미지들은 각 단계에 맞는 적절한 레이아웃으로 전환되어야 합니다.
 
-Additionally, the number of swapchain images can vary, whereas the engine should use a fixed number of _virtual frames_: 2 for double buffering, 3 for triple (more is usually overkill). More info is available [here](https://docs.vulkan.org/samples/latest/samples/performance/swapchain_images/README.html#_double_buffering_or_triple_buffering). It's also possible for the main loop to acquire the same image before a previous render command has finished (or even started), if the Swapchain is using Mailbox Present Mode. While FIFO will block until the oldest submitted image is available (also known as vsync), we should still synchronize and wait until the acquired image has finished rendering.
+또한, 스왑체인의 이미지의 수는 시스템에 따라 달라질 수 있지만, 엔진은 일반적으로 고정된 개수의 가상 프레임을 사용합니다. 더블 버퍼링에는 2개의 가상 프레임, 트리플 버퍼링에는 3개(보통은 3개로 충분합니다). 자세한 내용은 [여기](https://docs.vulkan.org/samples/latest/samples/performance/swapchain_images/README.html#_double_buffering_or_triple_buffering)서 확인할 수 있습니다. 또한 스왑체인이 (Vsync라 알려진)Mailbox Present 모드를 사용중이라면 메인 루프 중에 이전 렌더링 명령이 끝나기 전 동일한 이미지를 가져오는 것도 가능합니다.
 
-## Virtual Frames
+## 가상 프레임
 
-All the dynamic resources used during the rendering of a frame comprise a virtual frame. The application has a fixed number of virtual frames which it cycles through on each render pass. For synchronization, each frame will be associated with a [`vk::Fence`](https://docs.vulkan.org/spec/latest/chapters/synchronization.html#synchronization-fences) which will be waited on before rendering to it again. It will also have a pair of [`vk::Semaphore`](https://docs.vulkan.org/spec/latest/chapters/synchronization.html#synchronization-semaphores)s to synchronize the acquire, render, and present calls on the GPU (we don't need to wait for them on the CPU side / in C++). For recording commands, there will be a [`vk::CommandBuffer`](https://docs.vulkan.org/spec/latest/chapters/cmdbuffers.html) per virtual frame, where all rendering commands for that frame (including layout transitions) will be recorded.
+프레임마다 사용되는 모든 동적 자원들은 가상 프레임에 포함됩니다. 애플리케이션은 고정된 개수의 가상 프레임을 가지고 있으며, 매 렌더 패스마다 이를 순환하며 사용합니다. 동기화를 위해 각 프레임은 이전 프레임의 렌더링이 끝날 때 까지 대기하게 만드는 [`vk::Fence`](https://docs.vulkan.org/spec/latest/chapters/synchronization.html#synchronization-fences)가 있어야 합니다. 또한 GPU에서의 이미지를 받아오고, 렌더링, 화면에 나타내는 작업을 동기화하기 위한 2개의[`vk::Semaphore`](https://docs.vulkan.org/spec/latest/chapters/synchronization.html#synchronization-semaphores)가 필요합니다(이 작업들은 CPU측에서 대기할 필요는 없습니다). 명령을 기록하기 위해 가상 프레임마다 [`vk::CommandBuffer`](https://docs.vulkan.org/spec/latest/chapters/cmdbuffers.html)를 두어 해당 프레임의 (레이아웃 전환을 포함한) 모든 렌더링 명령을 기록할 것입니다.
 
-## Image Layouts
+## 이미지 레이아웃
 
-Vulkan Images have a property known as [Image Layout](https://docs.vulkan.org/spec/latest/chapters/resources.html#resources-image-layouts). Most operations on images and their subresources require them to be in certain specific layouts, requiring transitions before (and after). A layout transition conveniently also functions as a Pipeline Barrier (think memory barrier on the GPU), enabling us to synchronize operations before and after the transition.
 
-Vulkan Synchronization is arguably the most complicated aspect of the API, a good amount of research is recommended. Here is an [article explaining barriers](https://gpuopen.com/learn/vulkan-barriers-explained/).
+Vulkan 이미지에는 [이미지 레이아웃](https://docs.vulkan.org/spec/latest/chapters/resources.html#resources-image-layouts)이라 알려진 속성이 있습니다. 대부분의 이미지 작업과 이미지의 서브리소스는 특정 레이아웃에서만 수행될 수 있으므로, 작업 전후에 레이아웃 전환이 필요합니다. 레이아웃 전환은 파이프라인 배리어(GPU의 메모리 배리어를 생각하세요)역할도 수행하며, 전환 전후의 작업을 동기화할수 있게 합니다.
+
+Vulkan 동기화는 아마도 API의 가장 복잡한 부분 중 하나일 것입니다. 충분한 학습이 권장되며, [이 글](https://gpuopen.com/learn/vulkan-barriers-explained/)에서 배리어에 대해 자세히 설명하고 있습니다.
+
diff --git a/guide/translations/ko-KR/src/rendering/swapchain_update.md b/guide/translations/ko-KR/src/rendering/swapchain_update.md
