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 질문

영상도 수정했습니다.

CMake 커맨드 - target_include_directories 질문

bar 타겟이 맞습니다. 스크립트를 작성하면서 제가 실수를 했네요. 제보 감사합니다.

descriptorCount 에 대한 질문

네 여러개가 될 수 있습니다. 하지만 대부분 1만 사용합니다. 2 이상인 경우는 좀 더 벌칸을 깊게 사용할때 필요한데요. 리소스가 2D_ARRAY와 같이 배열인 경우에 2D로 바인딩할때 count가 2 이상이 될 수 있습니다. 이후에 고급 강좌에서 이에 대한 내용도 다뤄보겠습니다.

descriptorSet에 대한 질문들

안녕하세요? 김종수님,벌칸이 조금 어렵죠? ㅎㅎ 그래도 자주 접하시다보면 익숙해지실 꺼에요.파이팅입니다. descriptorSet을 descriptorPool에서 할당 받아서 사용하는 이유가 뭔가요?멀티 쓰레드를 보장하기 위함인데요. VkDescriptorPool을 쓰레드마다 생성해서 동기화 객체 없이 VkDescriptorSet을 할당 받기 위함입니다. 커맨드풀도 동일한 이유입니다.buffer와 memory에 대한 질문입니다. 예를 들면 device와 physicalDevice 처럼 buffer는 논리적인 개념이고 memory는 물리적인 개념인가요?메모리도 논리적인 개념입니다. 메모리의 물리적인 개념은 DRAM, VRAM이죠. 메모리도 버퍼와 같은 리소스라고 생각하시면 됩니다. 버퍼와 메모리를 따로 나눈 이유는 메모리 할당이 매우 무거운 작업이기 때문입니다. 메모리를 한번 할당하고 버퍼를 생성했다 파괴했다하면서 재활용하는게 더 효율적이거든요.pipelineLayout을 생성할 때 info 구조체에 setLayoutCount 값을 설정합니다.pipelineLayout으로 생성하는 graphics pipeline은 1개 이고, 그 graphics pipeline을 구성하는 vtx-frm shader에는 몇 개의 uniform을 사용하는지 이미 고정되어 있는데요.그러면 하나의 setLayoutCount만 사용하면 될 것 같은데, setLayoutCount를 따로 설정해주는 이유가 있나요?파이프라인 레이아웃을 어떻게 구성할지는 개발자의 몫입니다. 셋을 하나만 사용해도 되고 여러개 사용해도 됩니다. 하지만 목적에 따라 셋을 여러개 사용하는게 좋습니다. 이건 좀 더 벌칸을 이해해야지 이해할 수 있는 내용인데요. 지금 당장 이해가 되지 않더라도 이런 경우가 있을 수 있구나라고 읽고 넘어가셔도 됩니다. 셋에다가 리소스를 바인딩하기 위해서는 디스크립터 셋이 필요합니다. 디스크립터 셋에 리소스를 바인딩하는 작업은 매우 무거운 작업입니다. 렌더링을 할 때, 라이팅과 카메라는 장면을 렌더링할 때 모두 동일해서 한번만 업데이트 하면 됩니다. 하지만 오브젝트의 위치는 오브젝트마다 업데이트가 되어야합니다. 이런 경우에 셋을 하나만 사용하면 업데이트가 필요하지 않은 라이팅과 카메라까지 업데이트를 해야합니다. 그럼 업데이트양이 많아서 성능이 느려지겠죠? 라이팅과 카메라를 위한 첫번째 셋, 오브젝트를 위한 두번째 셋을 구분한다면 업데이트를 최소화해서 성능을 높힐 수 있습니다.descriptorSet은 이런 흐름으로 생성하고 사용하는 게 맞나요?- descriptorSetLayout으로 그래픽스 파이프라인에서 몇 개의 uniform이 사용될지 미리 알림- descriptorPool로 descriptorSet을 사용 가능한 할당- descriptorSet을 writeDescriptorSet으로 갱신해서 cpu->gpu로 데이터를 송부하는 용도로 사용하도록 설정 (readDescriptorSet는 검색해보니 없나보네요...ㅎㅎ)- 미리 uniform buffer를 업데이트 (render()의 1. 위치 정보 갱신)- vkCmdBindDescriptorSets() 을 호출하면 갱신된 위치 정보가 gpu에도 전송됨dlgmlals3 님이 잘 설명해 주셨습니다.

질문이 있습니다.

답변 1)G 버퍼 목적으로 스왑체인 이미지를 사용해서는 안됩니다. 스왑체인 이미지는 말 그대로 화면에 나가는 이미지입니다. G 버퍼는 화면에 나가는 이미지가 아니기 때문에 이미지를 생성하시고 그 이미지를 기반으로 프레임버퍼를 만들어서 G 버퍼에 필요한 데이터를 렌더링해야 합니다.답변 2)맞습니다. 렌더 패스 호환성은 VkLoadOp, VkStoreOp가 달라도 사용할 수 있도록 하는데 있습니다.

병렬 동작 지원 여부

CMake는 빌드 시스템 제너레이터입니다. 빌드 시스템이 병렬 빌드를 지원해야 됩니다. 거의 모든 빌드 시스템이 지원하고 있어 CMake도 병렬 빌드 인터페이스를 제공합니다. -j 옵션으로 병렬 빌드를 지정하시면 됩니다.

섹션2-6 vulkan device 질문

안녕하세요?dlgmlals3님이 잘 답변해주셨습니다. 감사합니다.제 답변을 남기면 아래와 같습니다.먼저 vkCreateDevice로 VkDevice를 만들게 되면 인텔, 엔비디아, AMD에 상관 없이 동일한 디바이스로 생각하시면 됩니다. 좀 더 부연설명을 드리면 GPU A와 GPU B가 있다고 가정해 보겠습니다. GPU A는 특수한 기능이 있습니다. 이 경우 두 GPU를 VkPhysicalDevice로 얻어오면 디바이스의 속성이 다르게 됩니다. 왜냐하면 GPU A는 특수한 기능이 있기 때문이죠. 이때, 특수한 기능을 포기하고 VkDevice를 만들게 되면 GPU A에서 돌아가는 어플리케이션이 GPU B에서도 돌아갈 수 있게 되는 것입니다. 이렇게함으로써 하드웨어를 추상화 시키는 것이죠. 또 나중에 여러개의 GPU를 묶어서 사용할 수 있는데, Logical하게 GPU가 같다면 모든 GPU를 같은 GPU라고 생각하고 사용할 수 있는 것이죠.그렇습니다. GPU에는 여러개의 Queue가 존재합니다. VK_QUEUE_GRAPHICS_BIT을 검사한 이유는 우리가 렌더링을 위해 기록한 커맨드를 처리할 수 있는 Queue를 선택하기 위함입니다.감사합니다.