D3D12 그래픽칩별 이런저런 현상 <intel HD520> 이전 드라이버에선 GPU메모리 사용랑이 1GB넘어가면 드라이버가 hang되어버렸음. 현재 최신 베타드라이버에선 돌아는 감. 심.각.하게 느림. GPU 에서 땡겨갈 수 있는 데디케이트 메모리가 부족해서 시스템 메모리로 스왑이 자주 일어나는게 원인일거라고 추측함. 참고로 같은 사이즈의 리소스를 사용할때 D3D12는 데디케이트 메모리를 3배쯤 쳐먹음. D3D12에선 리소스 -> 리소스 전송도 Command List를 사용하는데 이 부분도 … More D3D12엔진 개발 – 현재까지 발견한 GPU별 특징
난 메모리 새는 코드를 짜는 프로그래머는 맞아야 한다고 생각하는 사람이다. 이 얘길 하면 많이들 공감한다. 근데 막상 힙 메모리와 커널 오브젝트를 정말 깔끔하게 해제하기 위해서 어떤 노력을 하고 있는지 물어보면 아무것도 안하는 경우가 많다. Windows Application 개발의 예를 들면 CRT Heap Check도 안쓰고, Application Verifier도 안쓰고 뭐 기타 다른 방법도 준비되지 않은 상태로 개발하는 케이스를 … More 메모리는 할당하는것보다 해제하는게 더 중요하다.
며칠전 개발중인 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
https://www.usenix.org/…/ev…/atc11/tech/final_files/Kato.pdf GPU->CPU로의 이벤트 드리븐, CPU->GPU로의 call이 어떻게 구현되는지 궁금했는데 이 문서에 비교적 잘 나와있음.
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
요새는 머신에 여러개의 네트워크 장치가 붙어있다. 랜카드가 여러개인 경우도 있고, 그렇지 않더라도 VM등 가상 네트워크 디바이스가 여러개 존재하는 경우가 대부분이다. 따라서 어플리케이션이 접속을 받아야하는 경우에 어느 네트워크 장치의 IP에 bind해야할지 난감할때가 많다. 그래서 이럴때 사용할 코드를 작성했다. win32의 경우는 dns주소와 gateway가 설정된 경우를 찾아서 인터넷에 접속한걸로 간주한다. UWP의 경우 NetworkInformation::GetInternetConnectionProfile()로 인터넷에 연결된 네트워크 장치를 찾는다. … More win32 or UWP에서 인터넷에 연결된 적절한 IP가져오기
D3D12에선 온갖 렌더링 스테이트를 묶어서 ID3D12PipelineState객체 하나로 만들어둠. 렌더링하면서 렌더 스테이트를 중간에 바꿀수 있는 API가 아예 존재하지 않음. 오직 ID3D12PipelineState객체만 바꿔가면서 렌더링 할 수 있음. 이게 쉐이더 폭발보다 더 무서움. [ 알파블랜딩 경우의 수 x 쉐이더 조합의 경우의 수 x 기타(양면 렌더링 여부, Depth Enable, Depth Write여부 등등) ] 변수가 더 있을텐데 이 정도만 해도 … More D3D12엔진개발 – ID3D12PipelineState폭발…
이 날을 기다렸다. 실제로 정말 더 빠른지를 테스트해보고 싶었다. 일단 데스크탑의 경우 최대 프레임이 D3D12버전보다 D3D11쪽이 두배 정도 나왔다. 이건 상당히 아쉬운 부분인데 그냥 화면 클리어만 해도 D3D11보단 무조건 느리다. 데스크탑에서 D3D11버전이 1400프레임 정도 나올때 D3D12버전은 800프레임 정도다. 뭔가 드라이버쪽에서 개선해줄 필요가 있을것 같다. 노트북GPU에선 일단 D3D12쪽이 빠르다. GTX980M이 장착된 에일리언웨어 노트북에서 테스트했을때 D3D12버전쪽이 … More D3D12엔진 개발 – D3D11엔진과의 성능비교
댓글을 달려면 로그인해야 합니다.