옵티머스,엔듀로 이런게 평소에는 내장 gpu를 사용하다가 필요할때 dGPU를 쓰는 기술이다. 엔듀로는 요새 많이 안쓰는거 같고 요새 나오는 GPU특화된 대부분의 노트북들은 옵티머스 기술이 적용되어있다. 이 빌.어.먹.을 옵티머스가 DirectX 9/11세대에서도 많은 문제를 일으켜왔는데 DirectX 12에선 진짜 꽤 치명적인 문제를 안고 있고 아직 해결되지 않고 있다. 우선 Windows 10의 현재 정식빌드인 th2(10586)에서 Present()를 호출하면 간헐적으로 에러를 발생시킨다. 옵티머스 … More D3D12 – 옵티머스 장비에서의 문제점
Voxel Object각각 Octree를 빌드하도록 했다. Voxel Object는 16x16x16짜리 1 bit table자료구졸르 사용한다. 그러니까 총 512바이트의 메모리가 필요하다. 이 자료구조를 그대로 Octree로 빌드한다. picking과 충돌처리용 삼각형 탐색은 이 Octree를 사용할 것이다. 코드는 빨리 짰는데 사소한 실수를 해서 밤을 샜다. 메모리 아끼려고 sub node각각의 인덱스나 포인터를 가지고 있는 대신, sub node를 8개씩 인접한 메모리블럭으로 할당하도록 했다. 순서대로 … More Game Dev – Octree for Voxel Object
미리 말해둔다. D3D12 렌더러 작업을 시작하기 전, 그러니까 지금 D3D12렌더러의 원형이었던 D3D11렌더러는 Single-Thread기반이었다. 게임엔진 자체는 여기저기서 멀티스레드를 사용하고 있지만 렌더링-그래픽 API사용 계층은 싱글 스레드로만 동작했다. 이전 포스트에서도 언급했듯이 그럼에도 불구하고 GPU 점유율 90%이상의 괜찮은 성능을 보여주었다. 그런데 D3D12렌더러를 만들면서 이전의 작동방식은 GPU를 펑펑 놀게 하는 결과를 가져왔다. 그래서 별로 내키지는 않지만 렌더러를 멀티스레드 체계로 바꿨다. … More D3D12엔진개발 – Multi-Thread 렌더링, Wait줄이기
똑같은 상황에서 메모리 사용 현황 DX11 – System: 579,608 KB , GPU Dedicated: 279,536 KB DX12 – System: 598,608 KB , GPU Dedicated: 553,136 KB 그리고 VS2015 Graphics Debugger에서 프레임을 캡쳐해서 현재 D3D 오브젝트들이 사용하는 메모리 사이즈를 다 합산해봄. 202665770 Bytes -> 193MB 1. 시스템 메모리 사용량은 D3D11, D3D12엔진 모두 비슷. GPU Dedicated메모리 사용량은 DX12가 … More D3D12엔진에서 GPU Dedicated 메모리를 쳐묵쳐묵하고 있는 건에 대해서.
D3D12 그래픽칩별 이런저런 현상 <intel HD520> 이전 드라이버에선 GPU메모리 사용랑이 1GB넘어가면 드라이버가 hang되어버렸음. 현재 최신 베타드라이버에선 돌아는 감. 심.각.하게 느림. GPU 에서 땡겨갈 수 있는 데디케이트 메모리가 부족해서 시스템 메모리로 스왑이 자주 일어나는게 원인일거라고 추측함. 참고로 같은 사이즈의 리소스를 사용할때 D3D12는 데디케이트 메모리를 3배쯤 쳐먹음. D3D12에선 리소스 -> 리소스 전송도 Command List를 사용하는데 이 부분도 … More D3D12엔진 개발 – 현재까지 발견한 GPU별 특징
며칠전 개발중인 D3D12렌더러에 Compute Shader를 이용한 Hi-Z Occlusion Culling을 만들어넣었었다. 물론 Occlusion Culling에 걸리는 시간으로만 보면 Hi-Z Occlusion Culling이 훨씬 빠르다. 그러나 Hi-Z Culling은 Bounding Sphere를 가지고 테스트 하기 때문에 정확도가 많이 떨어진다. 보이지 않는 오브젝트도 보인다고 판정할 확률이 높다. 그래서 이전 D3D11렌더러에서도 Hi-Z Culling이후에 D3DQUERY를 이용한 Occlusion Culling을 사용했다. D3DQUERY Occlusion Culling을 추가로 사용하면 … More D3D12엔진개발 – D3DQUERY를 이용한 Occlusion Culling
D3D11버전에서 구현했던 Compute Shader를 이용한 Hi-Z Occlusion Culling을 D3D12엔진에서 구현했다. 기본 개념과 구현에 대해서는 자세히 적지 않겠다. 예전에 KASA에서 밝표했던 내용이 있으므로 발표자료를 첨부한다. Hierachical z Map Occlusion Culling from YEONG-CHEON YOU D3D12에서 Compute Shader를 사용하려면 어떤 API들을 사용해야하는지 찾느라 좀 애먹었다. Compute Shader를 위한 ID3DPipelineState를 만들려면D3D12_GRAPHICS_PIPELINE_STATE_DESC구조체 대신 D3D12_COMPUTE_PIPELINE_STATE_DESC를 사용해야한다. 또한 CreateGraphicsPipelineState()대신 ID3D12Device::CreateComputePipelineState()를 사용한다. 이거 … More D3D12엔진개발 – Hierachical z Map Occlusion Culling
D3D12렌더러 개발을 시작하면서 한번 언급했던 내용이다. PipelineState폭발. D3D12에선 Render State의 각 항목들을 개별적으로 바꿀 방법이 없다. 무슨 소린고 하니 A라는 VertexShader를 사용해서 렌더링했다가 모든 Render State를 그대로 유지한 상태에서 B라는 VertexShader로 바꿔서 렌더링하고 싶다…이런거 불가능하다. 알파블랜딩 상태도 마찬가지이고 Z-Write를 끌지 켤지, Z-Test를 할지 말지도 마찬가지다. 이 모든 상태들은 ID3D12PipelineState객체 한개로 묶어서 처리된다. D3D12_GRAPHICS_PIPELINE_STATE_DESC구조체 각 상태들을 설정해서 ID3D12PipelineState객체를 … More D3D12엔진개발 – PipelineState 조합(폭발) 처리
절대로 움직이지 않는 static한 오브젝트들은 Light Map을 사용한다. Graphics API를 사용하는 계층 말고 그 위의 상위 계층에서 Light Map의 좌표를 부여하고 각 Texel의 광도를 계산한다. 렌더러에서는 이미지 데이타로 받아서 Light Map Texture를 생성하고 렌더링할 뿐이다. 따라서 D3D11 -> D3D12로 전환되어도 Light Map처리 자체가 바뀌진 않는다. D3D Resource로서의 Light Texture 다루는 방법만 바뀔 뿐. Light Texture는 … More D3D12엔진개발 – Light Map Object를 위한 Texture Update
D3D12에선 온갖 렌더링 스테이트를 묶어서 ID3D12PipelineState객체 하나로 만들어둠. 렌더링하면서 렌더 스테이트를 중간에 바꿀수 있는 API가 아예 존재하지 않음. 오직 ID3D12PipelineState객체만 바꿔가면서 렌더링 할 수 있음. 이게 쉐이더 폭발보다 더 무서움. [ 알파블랜딩 경우의 수 x 쉐이더 조합의 경우의 수 x 기타(양면 렌더링 여부, Depth Enable, Depth Write여부 등등) ] 변수가 더 있을텐데 이 정도만 해도 … More D3D12엔진개발 – ID3D12PipelineState폭발…
yuchi's development 
댓글을 달려면 로그인해야 합니다.