VkSubmitInfo2에 대해 질문드립니다.

안녕하세요?VkSubmitInfo2와 VkSubmitInfo의 차이는 VkSubmitFlags flags가 있냐 없냐의 차이입니다. 원래는 있어야 했는데 스펙을 정의하면서 빼먹은 것이죠... VkSubmitFlags를 지정하지 않을 것이면 VkSubmitInfo 를 쓰셔도 무방합니다.일반적으로는 Gracphis Queue에서 모든 작업이 가능합니다. 하지만 특수한 경우에는 Graphics Queue, Present Queue, Copy Queue를 따로 잡아서 사용해야 하는 경우가 생깁니다. 이 경우 각각 Queue끼리의 동기화가 필요합니다. Present Queue에서 쓰고 있는데 Graphics Queue에서 특정 계산을 수행하면 안되니까요.Queue를 제출할 때, 세마포어가 2개 필요한 이유는 간단합니다. 하나는 지금 제출하는 커맨드 버퍼가 실행되기 전에 반드시 수행되어야 하는 세마포어 그리고 다른 하나는 다른 커맨드 버퍼가 현재 제출한 커맨드 버퍼가 실행되고 나서 처리되어야 하는데 이 시점을 알려주기 위한 세마포어입니다.감사합니다.

수업 진행 중에 궁금한 부분이 생겼습니다.

CMake에는 Debug인지 Release인지 32bit인지 64bit인지 기본 값이 설정되어 있습니다.CMake에서 빌드를 할 때, --config로 Debug 또는 Release를 결정할 수 있습니다.예시: cmake --build . --config Release아키텍쳐는 컴파일러마다 설정하는 방법이 다릅니다.MSVC64비트: -A x6432비트: -A Win32Clang 64비트: -DCMAKE_C_FLAGS=-m6432비트: -DCMAKE_C_FLAGS=-m32감사합니다.

VkImageLayout 열거형에 대해 질문드립니다.

두 레이아웃은 복사를 할 때 사용됩니다.VK_IMAGE_LAYOUT_TRANSFER_SRC_OPTIMAL은 복사할 내용을 가지고 있는 리소스,VK_IMAGE_LAYOUT_TRANSFER_DST_OPTIMAL은 복사가 될 리소스입니다.즉, memcpy(src, dst)에서 src는 VK_IMAGE_LAYOUT_TRANSFER_SRC_OPTIMAL이어야 하고 dst는 VK_IMAGE_LAYOUT_TRANSFER_DST_OPTIMAL여야 합니다.이렇게 레이아웃이 설정이 되면 DMA를 통해 복사가 빠르게 진행 될 수 있습니다.이 레이아웃이 아니어도 복사는 되는데, 이 경우 컴퓨트 쉐이더로 구현된 파이프라인에 의해 복사가 느리게 진행 됩니다.

Build_SHARED_LIBS 질문

안녕하세요?BUILD_SHARED_LIBS을 사용하면 add_library시 라이브러리 타입을 지정하지 않은 타겟에 일괄적으로 적용되게 됩니다.add_library( foo STATIC src/foo.cpp )처럼 라이브러리 타입을 정적으로 지정한 경우에는 BUILD_SHARED_LIBS을 TRUE로 설정하더라도 동적 라이브러리로 빌드가 되지 않는 것을 의미합니다.감사합니다.

예제 코드 (on_vkQueueWaitIdle)로그 관련

Validation Layer 문제일 수 있는데요. 어떤 로그가 발생하는지 알려주시겠어요?

FetchContent로 가져온 외부 라이브러리를 사전에 빌드하는 방법이 있을까요?

아쉽게도 Configure, Generate 단계에 타겟을 빌드할 수는 없습니다. 현재 구성하신 상태로는 OpenGLProject 빌드시 glad도 빌드가 되는 것으로 보입니다. 만약 OpenGLProject 빌드시 glad를 포함해서 빌드하고 싶지 않다면 vcpkg나 conan을 사용하셔야 합니다. 아니면 미리 컴파일을 하고 빌드 결과물로 타겟을 구성해서 사용하셔야 합니다.

ExternalProject_Add 관련 질문

안녕하세요? 이 기술들은 사장된 기술들인가요?사장된 기술은 아니고 계속 사용하셔도 됩니다. 하지만 CMake 2.X에 나온 add_dependencies와 같은 함수들의 사용은 권장되지 않습니다. 모던 빌드 시스템을 기반으로 빌드 스크립트를 작성하셔야지 확장이 쉽고 유지보수가 가능합니다. 강의 예제에서는 target_include_directories, target_link_directories, add_dependencies 를 사용하지 않는 이유가 궁금합니다.target_xxx 함수들은 사용합니다. 하지만 글로벌하게 영향을 주는 add_dependencies는 사용하지 않습니다. 이유는 모던 빌드 시스템에 위배되기 때문이죠. 참고로 모던 빌드 시스템을 따르지 않고 기존의 방식으로 빌드 스크립트를 작성하셔도 됩니다.스크립트를 매우 잘 작성하면 되지만 기존의 방식에서는 실수를 하기 매우 쉽습니다.실수가 쌓이면 나중에는 유지보수하기 매우 힘든 상황이 오기 마련입니다.모던 빌드 시스템은 이러한 문제들을 근본적으로 해결하기 때문에,저는 강의에서 모든 빌드 시스템을 근간으로 만들어진 함수들을 사용하라고 권장하고 있습니다. 감사합니다.

ExternalProject_Add 관련 질문

안녕하세요? 이 기술들은 사장된 기술들인가요?사장된 기술은 아니고 계속 사용하셔도 됩니다. 하지만 CMake 2.X에 나온 add_dependencies와 같은 함수들의 사용은 권장되지 않습니다. 모던 빌드 시스템을 기반으로 빌드 스크립트를 작성하셔야지 확장이 쉽고 유지보수가 가능합니다. 강의 예제에서는 target_include_directories, target_link_directories, add_dependencies 를 사용하지 않는 이유가 궁금합니다.target_xxx 함수들은 사용합니다. 하지만 글로벌하게 영향을 주는 add_dependencies는 사용하지 않습니다. 이유는 모던 빌드 시스템에 위배되기 때문이죠. 참고로 모던 빌드 시스템을 따르지 않고 기존의 방식으로 빌드 스크립트를 작성하셔도 됩니다.스크립트를 매우 잘 작성하면 되지만 기존의 방식에서는 실수를 하기 매우 쉽습니다.실수가 쌓이면 나중에는 유지보수하기 매우 힘든 상황이 오기 마련입니다.모던 빌드 시스템은 이러한 문제들을 근본적으로 해결하기 때문에,저는 강의에서 모든 빌드 시스템을 근간으로 만들어진 함수들을 사용하라고 권장하고 있습니다. 감사합니다.

FetchContent를 캐시 처리할 수 있나요?

안녕하세요?강의가 도움이 되셨다니 정말 다행입니다. 감사합니다. 말씀하셨다시피 FetchContent는 외부에서 다운을 받는 명령어입니다.컨테이너에 해당 모듈이 미리 다운로드 되어 있지 않으면 컨테이너 실행시마다 매번 다운로드 되게 됩니다.그러므로 FetchContent를 사용해서는 하늘구름님이 직면하신 문제를 해결할 수 없습니다. 저라면 vcpkg를 사용하겠습니다.그리고 vcpkg도 해당 모듈을 컴파일 한다면 로컬 vcpkg 서버를 둬서 미리 컴파일된 모듈을 사용하도록 하겠습니다.이것도 어렵다면 컨테이너 이미지에 해당 모듈을 설치한 상태로 컨테이너 이미지를 굽는 것입니다. 감사합니다.

CMake 커맨드 - target_include_directories 질문

영상도 수정했습니다.