옛날에는 >가 <...>보다 빨랐을 때무엇이 기다리니?

옛날에는 >가 <...>보다 빨랐을 때무엇이 기다리니?

멋진 OpenGL 튜토리얼을 읽고 있습니다.정말 대단해요, 절 믿으세요.제가 지금 하고 있는 주제는 Z버퍼입니다.이 모든 것을 설명하는 것 외에 GL_LESS, GL_ALWAYS 등의 커스텀 깊이 테스트를 실행할 수 있다고 저자는 말합니다.또한 깊이 값(최고값과 그렇지 않은 값)의 실제 의미도 커스터마이즈할 수 있다고 합니다.아직까지는 이해한다.그리고 작가는 믿을 수 없는 말을 한다.

zNear 범위는 zFar 범위보다 클 수 있습니다.zNear 범위보다 클 경우 뷰어에서 가장 가깝거나 가장 먼 범위로 창 공간 값이 반전됩니다.

앞서 창 공간 Z 값 0이 가장 가깝고 1이 가장 멀다고 했습니다.그러나 클립 공간 Z 값이 음수인 경우 깊이 1이 뷰에 가장 가깝고 깊이 0이 가장 멀게 됩니다.단, 깊이 테스트의 방향(GL_LESS에서 GL_GREATER 등)을 뒤집어도 같은 결과가 됩니다.그러니까 이건 그냥 관례에 불과해요.실제로 Z의 기호와 깊이 테스트를 뒤집는 것은 많은 게임에서 한때 중요한 성능 최적화였습니다.

내가 제대로 이해했다면, 성능 면에서, Z의 부호를 뒤집는 것과 깊이 테스트는 단지 한 가지 변경일 뿐입니다.<와의 비교>비교.그래서 내가 제대로 이해한 것 같은데, 작가가 거짓말을 하거나 지어낸 것이 아니라면, 그러면 바뀐다.<로.>많은 게임에 필수적인 최적화였습니다.

작가가 지어낸 말인가, 내가 오해하고 있는 말인가, 아니면 실제로 한번은 그런 말인가?<(저자가 말한 것처럼) 더 느렸다>?

이 매우 신기한 문제에 대해 설명해 주셔서 감사합니다!

_{면책사항:알고리즘의 복잡성이 최적화의 주된 원인임을 충분히 인식하고 있습니다.게다가 요즘은 전혀 차이가 없을 것 같고, 최적화를 요구하는 것도 아닙니다.나는 단지 극도로, 고통스럽게, 어쩌면 엄청나게 궁금할 뿐이다.}

퍼포먼스 면에서는 Z의 부호와 깊이 테스트를 바꾸는 것은 <비교>의 비교를 바꾸는 것에 지나지 않습니다.그래서 제가 제대로 이해하고 있고, 저자가 거짓말을 하거나 지어낸 것이 아니라면, <에서>로 변경하는 것은 많은 게임에서 필수적인 최적화였습니다.

별로 중요하지 않아서 잘 설명하지 못했어요.나는 단지 그것이 추가하기에 흥미로운 사소한 것이라고 느꼈다.알고리즘에 대해 자세히 설명하려고 한 건 아니에요

단, 컨텍스트가 중요합니다.비교가 비교보다 빠르다고는 말하지 않았습니다.주의: 그래픽스 하드웨어의 깊이 테스트를 말하는 것이지 CPU가 아닙니다.operator<.

제가 말한 것은 하나의 프레임을 사용하는 오래된 최적화입니다.GL_LESS[0, 0.5] 범위로 설정합니다.다음 프레임은 다음과 같이 렌더링합니다.GL_GREATER[1.0, 0.5] 범위로 설정합니다.모든 프레임을 왔다 갔다 하면서 문자 그대로 "Z 기호와 깊이 테스트"를 넘깁니다.

이렇게 하면 깊이 정밀도가 1비트 떨어집니다만, 깊이 버퍼를 클리어할 필요가 없었습니다.이것은 옛날에는 꽤 느린 조작이었습니다.요즘은 심도 청소가 무료일 뿐만 아니라 실제로 이 기술보다 빠르기 때문에 사람들은 더 이상 그것을 하지 않는다.

답은 칩+드라이버가 어떤 형태로 사용되든 계층형 Z는 한 방향으로만 작동한다는 것입니다. 이것은 옛날에는 꽤 흔한 문제였습니다.저레벨 어셈블리/브런칭은 이와 무관합니다.Z 버퍼링은 고정기능 하드웨어에서 실행되며 파이프라인 처리됩니다.따라서 추측이 없으므로 분기 예측이 없습니다.

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

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

언급URL : https://stackoverflow.com/questions/7338858/once-upon-a-time-when-was-faster-than-wait-what