th2빌드는 현재 Windows 10의 공식 빌드이다. Redstone은 7월 릴리즈가 예정된 Windows 10의 베타 빌드이다. 개발중인 D3D12 엔진을 Redsone과 th2에서 돌려보면 조금 다르게 돌아간다. 렌더링이 다른게 아니고 에러 발생 여부가 다르다. 대부분 ResourceBarrier관련인데 th2와 Redstone 모두 렌더링은 정상적으로 되고 있던 것들이다. th2빌드에선 에러가 나지 않았는데 Redstone에선 에러가 발생하고 DX Control Panel에서 에러 발생시 브레이크를 걸도록 하면 … More Windows 10 Redstone빌드와 th2빌드의 DirectX 12 차이점
옵티머스,엔듀로 이런게 평소에는 내장 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
yuchi's development 
댓글을 달려면 로그인해야 합니다.