최신 하드웨어가 실시간을 유지하면서 도달 할 수있는 장면의 다각형 수는 몇 개입니까?

어떤면에서는 상당히 기본적인 질문이지만, 많은 사람들이 자신이 포함시킨 질문에 대한 답을 실제로 모릅니다. GPU 제조업체는 종종 매우 높은 숫자를 인용하며 다양한 게임 엔진이 지원한다고 주장하는 다각형 수의 확산은 종종 여러 자릿수에 걸쳐 있으며 여전히 많은 변수에 크게 의존합니다.

나는 이것이 광범위하고 개방적인 질문이라는 것을 알고 있으며, 사과드립니다. 그럼에도 불구하고 여기에있는 것이 귀중한 질문이라고 생각했습니다.

나는 실시간이 대화식 이상의 모든 것 인 것이 일반적으로 받아 들여 진다고 생각합니다. 그리고 대화 형은 "입력에 응답하지만 애니메이션이 엉망인 것 같다"는 말은 부드럽 지 않습니다.
따라서 실시간은 우리가 표현해야하는 움직임의 속도에 달려 있습니다. 시네마는 24 FPS로 투사되며 많은 경우에 충분한 실시간입니다.

그러면 기계를 처리 할 수있는 다각형의 수를 직접 확인하여 쉽게 확인할 수 있습니다. 간단한 테스트 및 FPS 카운터로 약간의 VBO 패치를 만들면 많은 DirectX 또는 OpenGL 샘플이이 벤치 마크를위한 완벽한 테스트 베드를 제공 할 것입니다.

약 100 만 개의 다각형을 실시간으로 표시 할 수있는 고급 그래픽 카드가 있는지 확인할 수 있습니다. 그러나 말했듯이 엔진은 실제 장면 데이터로 인해 다각형 수와 관련이없는 여러 성능 문제가 발생할 수 있으므로 지원을 쉽게 요구하지 않습니다.

당신은 :

• 충전율
  • 텍스처 샘플링
  • ROP 출력
• 전화를 걸다
• 렌더 타겟 스위치
• 버퍼 업데이트 (균일 또는 기타)
• 오버 드로우
• 쉐이더 복잡성
• 파이프 라인 복잡성 (모든 피드백 사용, 반복 지오메트리 쉐이딩, 폐색?)
• CPU와의 동기 점 (픽셀 판독 값?)
• 다각형 풍부

특정 그래픽 카드의 약점과 장점에 따라 이러한 점 중 하나 이상이 병목 현상이 발생합니다. "그게 그거야"라고 확실히 말할 수있는 것은 아닙니다.

편집하다:

하나의 특정 카드의 GFlops 스펙 그림을 사용할 수 없으며 다각형 푸시 용량에 선형으로 매핑 할 수 없습니다. https://fgiesen.wordpress.com/2011/07/03/a-trip-through-the-graphics에 자세히 설명 된대로 다각형 처리가 그래픽 파이프 라인에서 순차적 병목 현상을 거쳐야한다는 사실 때문에 -pipeline-2011-part-3 /
TLDR : 정점은 기본적으로 순차적 인 것 (정점 버퍼 순서가 중요 함) 인 기본 어셈블리 이전의 작은 캐시에 맞아야합니다.

GeForce 7800 (9 세)을 올해의 980과 비교하면 초당 가능한 작업 수가 1,000 배 증가한 것 같습니다. 그러나 다각형을 천 번 더 빠르게 밀어 넣지 않을 것입니다 (이 간단한 메트릭으로 초당 약 2 천억 개가 될 것입니다).

EDIT2 :

"상태 스위치 및 기타 오버 헤드에서 너무 많은 효율을 잃지 않기"와 같이 "엔진을 최적화하기 위해 무엇을 할 수 있는가"라는 질문에 답하기 위해.
그것은 엔진 자체만큼 오래된 질문입니다. 그리고 역사가 진행됨에 따라 더욱 복잡해지고 있습니다.

실제로 실제 상황에서 일반적인 장면 데이터에는 많은 재질, 많은 텍스처, 다양한 셰이더, 많은 렌더 대상 및 패스 및 많은 정점 버퍼 등이 포함됩니다. 내가 작업 한 엔진은 패킷 개념으로 작동했습니다.

하나의 패킷은 하나의 드로우 콜로 렌더링 될 수 있습니다.
여기에는 다음과 같은 식별자가 포함됩니다.

• 정점 버퍼
• 인덱스 버퍼
• 카메라 (통과 및 렌더링 대상 제공)
• 재질 ID (쉐이더, 텍스처 및 UBO 제공)
• 눈까지의 거리
• 보인다

따라서 각 프레임의 첫 번째 단계는 가시성, 통과, 재료, 형상 및 거리에 우선 순위를 부여하는 연산자로 정렬 기능을 사용하여 패킷 목록에서 빠른 정렬을 실행하는 것입니다.

가까운 물체를 그리면 초기 Z 컬링이 극대화됩니다.
패스는 고정 단계이므로, 우리는 그들을 존중할 수밖에 없습니다.
머티리얼은 렌더 타겟 후 상태 전환하는 데 가장 비싼 것입니다.

서로 다른 머티리얼 ID 사이에서도 휴리스틱 기준을 사용하여 서브 오더링을 수행하여 셰이더 변경 횟수 (소재 상태 전환 작업에서 가장 비싸다)와 두 번째로 텍스처 바인딩 변경을 줄일 수 있습니다.

이 순서를 모두 수행 한 후 필요하다고 판단되는 경우 메가 텍스처링, 가상 텍스처링 및 속성없는 렌더링 ( link )을 적용 할 수 있습니다 .

엔진 API에 대해서도 하나의 공통점은 클라이언트가 요구하는 상태 설정 명령의 발행을 연기하는 것입니다. 클라이언트가 "set camera 0"을 요청하면이 요청을 저장하는 것이 가장 좋으며 나중에 클라이언트가 "set camera 1"을 호출하지만 그 사이에 다른 명령이없는 경우 엔진은 첫 번째 명령의 쓸모없는 것을 감지하여 삭제할 수 있습니다 . 이는 "완전히 보유 된"패러다임을 사용하여 중복을 제거하는 것입니다. "즉시"패러다임에 반대하여, 이는 네이티브 API 위에 래퍼 일 뿐이며 클라이언트 코드에 따라 명령을 바로 실행합니다. ( 예 : virtrev )

마지막으로 최신 하드웨어를 사용하면 개발하는 데 비용이 많이 들지만 잠재적으로 보람찬 단계는 API를 금속 / 맨틀 / 불칸 / DX12 스타일로 전환하고 렌더링 명령을 직접 작성하는 것입니다.

렌더링 명령을 준비하는 엔진은 각 프레임에서 덮어 쓰는 "명령 목록"을 보유하는 버퍼를 만듭니다.

보통 프레임 "예산"이라는 개념이 있는데, 게임이 감당할 수 있습니다. 16 밀리 초 안에 모든 작업을 수행해야하므로 GPU 시간을 "lightpre pass의 경우 2ms", "material pass의 경우 4ms", "간접 조명의 경우 6ms", "후 처리의 경우 4ms"로 명확하게 분할하십시오 ...