Critical Section과 SRWlock의 차이

ai가 답변한것 이상으로 제가 답변할게 있을까 모르겠네요. 저도 자세히 살펴보진 않았거든요. 다만 SRWLOCK이 조금이라도 더 간소화될 수 있는 이유중 하나는 재진입을 허용하지 않기 때문이라 생각합니다.CriticalSection은 이미지 진입한 스레드가 재진입하는걸 허용하고 있고 이를 위한 카운터변수와 스레드 핸들을 들고 있죠. srwlock은 소유자 스레드에 대해 구분하지 않습니다. 이것이 간소화된 호출경로를 가질 수 있는 이유라고 생각합니다. 그리고 재진입이 불가할 경우, 그러니까 CriticalSection을 SRWLock으로 대체하면 큰일나는 프로젝트도 있거든요. CriticalSection을 완전히 SRWLock으로 대체할 수 없는 이유이기도 하구요.

프로세스와 가상메모리의 주소 위치와 테이블 매핑

네 C언어의 문법 struct입니다. 실제로 OS의 프로세스 정보 블럭은 C언어의 struct로 구현됩니다. OS는 C로 작성되었고 프로세스의 각종 정보들이 struct로 선언된 자료구조에 담겨 있습니다.시스템 메모리에 있는 데이터라도 물리메모리와 1:1 맵핑 되지는 않습니다. 심지어 OS의 커널에서도 물리 메모리 주소를 직접 억세스하진 않습니다. os가 최초 부팅할 때 가상 메모리 억세스를 위한 메모리 페이지 테이블을 먼저 구성합니다.이것은 CPU의 MMU라 하는 기능을 사용합니다. 물리 메모리에 있는 데이터든, 디스크 장치로 페이지아웃된 데이터든 '가상주소 -> 물리주소'변환을 통해 억세스 됩니다. os에서 할당된 모든 메모리는 '가상주소'를 가지는 페이지입니다. 여기서 물리 페이지라고 하면 '가상주소'는 당연히 가지고 있고 해당 가상 주소가 '물리 메모리'에 맵핑되어있는 페이지입니다. 즉 '가상주소:물리메모리주소' 또는 '가상주소:물리메모리주소없음(디스크 페이지아웃 상태)' 이렇게 두 가지 상태를 가지는 것입니다. '가상주소만 가지고 있고 물리메모리에 맵핑되지 않은 페이지는 저장소(하드or ssd)에 존재하게 되됩니다.이 주소에 대해 억세스 하려고 하면 페이지 엔트리에 페이지아웃되었다는 표시가 있기 때문에 page fault라고 하는 인터럽트가 발생하게 됩니다. 이에 대한 인터럽트 핸들러도 미리 설정되어있으므로 page fault발생시 해당 가상주소에 대해 물리메모리를 맵핑하고 그제서야 실제로 가상주소의 메모리를 읽고 쓰게 됩니다.page fault가 발생한 페이지를 물리 메모리에 맵핑하려 하는데 만약 물리메모리가 충분치 못하다면 억세스가 빈도가 낮고 억세스된지 오랜 시간이 지난 다른 페이지를 선택헤서 '가상주소:물리주소없음' 상태로 바꾸고 그 페이지가 사용하던 물리 주소를 회수해서 page fault된 페이지에 할당합니다. 이것이 흔히 말하는 페이지 swap입니다. 가상 메모리 주소는 페이지테이블이라는 자료구조로 저장됩니다. 이것은 하드가 아닌 물리 메모리에 저장됩니다. 이것은 페이지아웃 될 수 없습니다. 반드시 물리 메모리에 위치해야합니다. 이 정보는 cpu동작과 직접적으로 연관되며 mov명령등 메모리를 읽고 쓸때 cpu의 mmu에 의해 직접 억세스 됩니다. 디스크장치에 저장되는 데이터는 페이지테이블 같은 필수 커널 데이터가 아닌, OS의 메모리매니저에 의해 할당되는 (유저모드 프로그래머가 malloc()으로 할당하는) 페이지 들입니다.

유저모드와 커널모드 차이

syscall이 하드웨어 접근이라고 하면 a = 0;이라는 코드를 어셈블리 레벨에서 보면 mov eax,0 이런식으로 컴파일되므로 cpu를 제어한다 -> 하드웨어를 제어한다. 라고 볼 수 있습니다. 그러니까 사실 메모리에 읽고 쓰는 행위도 모두 하드웨어에 접근한다고 할 수 있습니다. 하지만 통상적으로 말하는 하드웨어에 대한 '직접'접근은 이 모든 행위를 뜻하는건 아닙니다. 세부적으로 보면 CPU를 제외한 하드웨어를 제어하는걸 말합니다. cpu자체를 제어하거나 cpu를 통해 메모리를 읽고 쓰는 행위는 하드웨어 제어라고 부르진 않구요. 너무 당연한 행위니까요. cpu가 다른 장치(ssd,gpu,마우스,키보드,랜카드...등등)로부터 인터럽트를 받았을 때의 핸들링, 또는 그 장치들을 제어(cpu에 메모리 주소 선 외에 외부장치와 통신하기 위한 주소 선이 따로 있습니다)하는 행위들을 일반적으로 하드웨어 제어라 합니다. 이런 제어는 일반적으로 어셈블리어 레벨에서 in, out명령을 사용하는데 이것은 유저모드에서 호출이 불가능합니다. 이외에는 강의 진행중에 나오겠지만 메모리 억세스를 위한 페이지테이블을 설정하는 기능등을 위해 cpu에 존재하는 특수한 레지스터들(cr0등)을 억세스하는 행위도 유저모드에선 금지되어있습니다.예시를 들어 정리하자면 일반적인 유저모드 코드 - 정해진 메모리에 대한 읽기,쓰기,시스템콜을 위한 일부의 정해진 인터럽트 호출커널모드에서의 하드웨어 제어 코드 - 가상메모리 억세스를 위한 페이지테이블 설정, 다른 장치를 제어하기 위한 in,out명령 사용, 모든 인터럽트에 대한 핸들러 설정, 인터럽트 콜 이렇게 볼 수 있습니다.

c 런타임 라이브러리 관련 질문

맞게 이해하셨습니다. 리눅스와 달리 Windows는 C의 함수들(POSIX함수들)을 OS의 API로 갖고 있지 않습니다. 전용의 Windows API가 있고 모든 POSIX함수들은 Windows 의 전용 API를 매개하는 역할을 합니다.

수업자료 문의의 건

1,2,3편은 소스코드가 원래 없고 4편부터 소스코드가 있는데 수업노트에 소스코드 다운로드 링크가 있습니다.

MeshObject 공용 사용 방법

네. 맞습니다. 실제로는 별도의 매쉬오브젝트를 생성하고 각각 BLAS를 가집니다.일단 주석의 "meshobject를 공용으로 쓰도록 한다."는 의미는 다음과 같습니다.1. CreateBasicMeshObject()로 생성한 CBasicMeshObject는 이름이나 id로 탐색할 수 있도록 자료구조에 넣어둡니다. 예를 들어 최초의 박스 매시를 만들때 생성한 CBasicMeshObject를 "box_mesh_obj"라는 이름으로 해시테이블에 등록할 수도 있겠죠.2. 이제 CreateBoxMeshObject()할 때마다 매번 CreateBasicMeshObject()를 호출하는 대신 자료구조에서 CBasicMeshObject를 찾아서 pMeshObj->CreateBLAS()를 호출합니다.3. 이때 pMeshObj는 이미 내부에 VetexBuffer와 IndexBuffer, 그리고 이미 공유되고 있는 texture를 다 들고 있으므로 이 리소스들을 '읽기전용'으로 하여 BLAS를 생성합니다. 이 시점에서 vertex buffer, index buffer, texture 리소스는 여러개의 BLAS resource간에 공유가 됩니다.4. BLAS resource자체도 공유가 가능한데 제 개인 프로젝트에서 BLAS resource의 공유는 instancing할 때만 사용하고 있습니다. 이 경우 TLAS를 빌드할 때 하나의 BLAS resource를 여러 개의 TLAS Instance로 넣어줍니다. 다만 TLAS Instance마다 행렬만 다르게 넣어줍니다. 이 행렬들로 위치와 스케일 회전을 제어합니다.5. 주석의 "meshobject를 공용으로 쓰도록 한다."라고 하는 것은 1,2,3번에 해당하는 얘기입니다. 당초 예제를 작성할 때는 vertex buffer와 index buffer를 공유시킬 예정이었으나 예제로 사용하기에 코드가 너무 복잡해지는 감이 있어서 공유하지 않도록 최종 작성되었습니다.혼란을 드려 죄송합니다. 지적 감사합니다.참고로 다음의 영상을 참고하시면 매시공유가 어떤 의미인지 이해하기 쉬울겁니다.https://www.youtube.com/live/ALcVb5b68Zw?si=GHNimcScnm0dkd_p&t=3384

BuildBLAS 할당 리소스 사이즈

그렇습니다. info.ResultDataMaxSizeInBytes가 맞습니다. 소스코드 수정해서 올렸습니다. 감사합니다.

ConstnatBufferPool관련 질문

말씀하신대로 sizeof(CONSTANT_BUFFER_TYPE_RAY_TRACING)가 아니라 sizeof(CONSTANT_BUFFER_RAY_TRACING)가 맞습니다.이것이 문제없이 돌아갔던 이유는 constant buffer의 기본 align 사이즈가 256바이트이고, 버퍼를 만들때 256바이트 align하도록 했기 때문입니다. sizeof(CONSTANT_BUFFER_TYPE_RAY_TRACING)는 4지만 256바이트 align 하면 256이 되므로 sizeof(CONSTANT_BUFFER_RAY_TRACING)보다 충분히 큰 사이즈라 돌아가는데는 문제가 없었습니다. 어쨌든 코드는 잘못되었으므로 수정해서 다시 업로드했습니다. 감사합니다.

7강 스레드제어 강의, 26분경 질문입니다.

말씀하신대로 0이 맞습니다.제가 실수했네요.

CommandList의 GraphicsCommandList 변경이유

ID3D12CommandList는 그래픽스 커맨드 레코딩이 불가능합니다. 작동이 아예 불가하기 ID3D12CommandList로 사용했던 적이 없을텐데 이상하네요. 코드 라인을 긁어서 질문해주시면 좀더 자세하게 답변해드릴 수 있을것 같습니다.