옛날 옛적에,>가 <…보다 빠를 때, 잠깐만?


280

멋진 OpenGL 튜토리얼을 읽고 있습니다 . 정말 대단해, ​​믿어 줘 현재 내가 다루고있는 주제는 Z- 버퍼입니다. 저자는 GL_LESS, GL_ALWAYS 등과 같은 커스텀 깊이 테스트를 수행 할 수 있다고 설명하고, 깊이 값의 실제 의미 (최상위 및 비상 위)도 설명 할 수 있다고 설명합니다. 주문을 받아서 만드는. 나는 지금까지 이해합니다. 그리고 저자는 믿을 수없는 것을 말합니다.

zNear 범위는 zFar 범위보다 클 수 있습니다. 만약 그렇다면, 윈도우 공간 값은 뷰어로부터 가장 가깝거나 가장 먼 구성의 관점에서 역전 될 것이다.

이전에는 0의 창 공간 Z 값이 가장 가깝고 1이 가장 먼 것으로 알려졌습니다. 그러나 클립 공간 Z 값이 부정되면 깊이 1은 뷰에 가장 가깝고 깊이 0은 가장 먼 거리입니다. 그러나 깊이 테스트 방향 (GL_LESS에서 GL_GREATER 등)을 뒤집 으면 동일한 결과를 얻습니다. 정말 컨벤션 일뿐입니다. 실제로 Z의 부호와 깊이 테스트를 뒤집는 것은 많은 게임에서 중요한 성능 최적화였습니다.

성능 측면에서 올바르게 이해한다면 Z의 부호와 깊이 테스트를 뒤집는 것은 <비교를 비교로 변경 하는 >것입니다. 그래서, 내가 제대로 이해하고 저자는 다음 변경, 거짓말을하거나 일을하고 있지 않은 경우 <>로 사용되는 중요한 최적화 많은 게임.

저자는, 물건을 만드는 뭔가를 오해하고, 또는 한 번 경우 참 <(느렸다 극히 보다 저자가 말한대로는) >?

이 호기심 많은 문제를 분명히 해주셔서 감사합니다!

면책 조항 : 알고리즘 복잡성이 최적화의 주요 소스라는 것을 알고 있습니다. 또한, 요즘에는 분명히 아무런 변화가 없을 것이라고 생각하며 아무것도 최적화하지 않아도됩니다. 나는 극도로, 고통스럽고, 엄청나게 호기심이 많습니다.


6
이 튜토리얼에 대한 링크는 (최근에) 사라진 것 같습니다. :(
TZHX

@TZHX : 허용 된 답변은 튜토리얼 작성자가 작성 했으므로 다시 찾을 수 있기를 바랍니다. :) 그의 대답에 내 마지막 코멘트를 참조하십시오
아르 멘 Tsirunyan

3
참조 된 OpenGL 튜토리얼은 여기에서 볼 수 있습니다 .
Fons

(a <b)는 (b> a)와 동일하므로 하드웨어에서 두 비교 작업을 모두 구현할 필요는 없습니다. 성능의 차이는 비교 작업의 결과로 발생하는 결과입니다. 이것은 모든 부작용을 설명하기 위해 길고 구불 구불 한 길이지만 여기에 몇 가지 조언이 있습니다. 깊이 테스트에 실패한 조각에 대해 더 비싼 조각 처리를 피하기 위해 깊이 버퍼를 채우는 데 사용되는 게임. 퀘이크는 게임이 항상 화면의 모든 픽셀을 채우므로 프레임 버퍼를 지우지 않기 위해 깊이 범위를 두 부분으로 나누는 데 사용되었습니다.
t0rakka

2
@ 폰스 다시 링크 죽은 것처럼 보인다 :(
nalzok

답변:


350

성능 측면에서 올바르게 이해한다면 Z의 부호와 깊이 테스트를 뒤집는 것은 <비교를> 비교로 변경하는 것입니다. 따라서 내가 올바르게 이해하고 저자가 거짓말을하거나 물건을 만들고 있지 않다면 <에서>로 변경하면 많은 게임에서 중요한 최적화가되었습니다.

중요하지 않기 때문에 특히 잘 설명하지 못했습니다. 방금 추가해야 할 재미있는 퀴즈라고 생각했습니다. 나는 알고리즘을 구체적으로 다루지 않았습니다.

그러나 컨텍스트가 핵심입니다. 나는 <비교가> 비교보다 빠르다고 말한 적이 없다. 우리는 CPU가 아닌 그래픽 하드웨어 깊이 테스트에 대해 이야기하고 있습니다. 아닙니다 operator<.

내가 언급 한 것은 하나의 프레임이 GL_LESS[0, 0.5] 범위에서 사용되는 특정 오래된 최적화였습니다 . 다음 프레임에서는 GL_GREATER[1.0, 0.5] 범위로 렌더링 합니다. 매 프레임마다 문자 그대로 "Z 표시와 수심 테스트 표시"를 앞뒤로 이동합니다.

이것은 1 비트의 심도 정밀도를 잃지 만, 한 번에 다소 느린 조작 인 심도 버퍼를 지울 필요는 없습니다. 심도 제거는 요즘 무료이며이 기술보다 실제로 더 빠르기 때문에 사람들은 더 이상 그렇게하지 않습니다.


1
오늘날 깊이 버퍼를 지우는 이유는 GPU가 계층 적 깊이 버퍼를 사용한다는 사실에 근거한 두 가지 이유가 있습니다. 따라서 타일 상태를 클리어로 설정하기 만하면 (빠른) 깊이 비교 부호를 변경하지만 비교 부호에 따라 최소 또는 최대 값 만 저장하므로 전체 HiZ 버퍼를 플러시해야합니다.
Jasper Bekkers 2016 년

3
@ NicolBolas : PerTZHX의 의견, 내 질문에 대한 자습서 링크가 사라졌습니다. 튜토리얼이 어디로 이동하고 선택적으로 질문을 편집했는지 알려주십시오.
Armen Tsirunyan

2
튜토리얼은 웹 아카이브에서 사용할 수 있습니다. @NicolBolas가 허용하면 더 접근하기 쉬운 위치로 이동할 수 있다면 커뮤니티에 도움이 될 것입니다. 아마도 GitHub 또는 무엇인가. web.archive.org/web/20150215073105/http://arcsynthesis.org/...
ApoorvaJ

3

대답은 거의 확실하게 칩 + 드라이버의 화신이 사용 된 경우 계층 Z가 한 방향으로 만 작동한다는 것입니다. 이것은 그 당시 꽤 흔한 문제였습니다. 낮은 수준의 조립 / 분기는 그것과 아무 관련이 없습니다. Z- 버퍼링은 고정 기능 하드웨어에서 수행되며 파이프 라인입니다-추측이 없으므로 분기 예측이 없습니다.


0

이와 같은 최적화는 프레임 버퍼 해상도를 덜 효율적으로 만들기 때문에 많은 임베디드 그래픽 솔루션의 성능을 저하시킵니다. 버퍼를 비우는 것은 비닝 할 때 버퍼를 저장 및 복원 할 필요가 없다는 드라이버에 신호입니다.

작은 배경 정보 : 타일링 / 바 이닝 래스터 라이저는 온칩 메모리에 맞는 매우 작은 타일로 화면을 처리합니다. 이렇게하면 외부 메모리에 대한 쓰기 및 읽기가 줄어들어 메모리 버스의 트래픽이 줄어 듭니다. 프레임이 완료되면 (스왑이 호출되거나 FIFO가 꽉 찼기 때문에 플러시, 프레임 버퍼 바인딩 변경 등) 프레임 버퍼가 해결되어야합니다. 즉, 모든 출력 함이 차례로 처리됩니다.

드라이버는 이전 내용을 보존해야한다고 가정해야합니다. 보존은 저장소가 외부 메모리에 기록되고 나중에 저장소가 다시 처리 될 때 외부 메모리에서 복원되어야 함을 의미합니다. 클리어 조작은 드라이버에게 빈의 내용이 명확하게 정의되어 있음을 알려줍니다. 이것은 최적화하기가 쉽지 않은 상황입니다. 버퍼 내용을 "삭제"하는 확장 기능도 있습니다.


-8

고도로 조정 된 어셈블리에서 플래그 비트와 관련이 있습니다.

x86에는 jl 및 jg 명령어가 있지만 대부분의 RISC 프로세서에는 jl 및 jz 만 있습니다 (jg 없음).


2
이것이 답이라면 새로운 질문을 제기합니다. 초기 RISC 프로세서에서 "분기 실행"이 "분기 무시"보다 느렸습니까? 내가 아는 한 측정 가능한 방식으로 지금은 그렇지 않습니다. 당신은 쓰기로되어 있었다 for무조건 분기 뒤로하고 루프를 종료하려면 앞으로 조건, 거의 취해지지 분기와 루프? 어색하게 들린다.
Pascal Cuoq

54
-1 :이 질문은 CPU와 관련없습니다 . GL_LESS 및 GL_GREATER는 GPU에서 실행되는 깊이 비교 작업입니다.
니콜 볼 라스

8
제목에 맞지만 실제 질문과는 거의 관련이없는 답변에 대해 얼마나 많은 담당자가 답변을받을 수 있는지에 대해서는 재밌습니다.
Joshua

7
+1 아니요,이 답변은 질문의 적어도 일부에 맞습니다. 문제는 "작가가 물건을 만들어 내고 있는가, 내가 잘못 이해하고 있는가, 또는 실제로 한 번 <작가가 말한대로>보다 느리다는 것입니까?"입니다. 세 가지 옵션이 있습니다. 이 답변은 옵션 3의 가능성에 대한 답변입니다.이 기사의 어느 곳에서도 CPU / GPU 기술이 없으며 GPU (CPU의 첫 3D 게임)가 아니어야합니다. 좋아 ... RISC에는 3D 게임이 많지 않은 것 같아 :-)
xanatos

3
(GPU 태그는 20:34에 추가되었습니다. 첫 번째 개정에는 CPU 태그 만있었습니다.이 응답은 18:44에 작성되었습니다)
xanatos
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.