텍스처 수정 (그리기)이 "상태 변경"으로 간주됩니까?


11

그래픽의 규칙은 더 많은 상태 변경을 수행하는 것보다 더 많은 상태 변경을 수행하는 것 (스위칭 셰이더, 바인딩 버퍼, 바인딩 텍스처 등)보다 낫습니다. 텍스처의 경우 각 다각형에 대해 새 텍스처를 개별적으로 바인딩하는 것보다 단일 아틀라스 (스프라이트 / 텍스트 렌더링 용)를 사용하여 많은 다각형을 렌더링하는 것이 더 빠릅니다.

을 통해 지속적으로 텍스처에 페인팅하는 경우에도 마찬가지 glTexSubImage2D입니까? 처리 과정을 거쳐 (네트워크를 통해) 들어오는 데이터 스트림이 있으며 한 번에 한 행씩 텍스처에 페인트됩니다. 데이터는 끝없는 스크롤로 시각적으로 표시됩니다.

하나의 큰 사각형에 렌더링 된 하나의 텍스처로 페인팅하는 것이 더 좋을까요 (페인팅 된 데이터를보기로 스크롤)? 여기서 아이디어는 주어진 시간에 하나 또는 두 개의 텍스처를 바인딩하고 계속 페인트하는 것입니다.

아니면 작은 사각형을 많이 칠해야합니까 (그림을 칠 때 사각형 만 표시)? 사각형 당 하나의 텍스처를 바인딩한다고 가정합니다.

답변:


11

그래픽 장치의 메모리 영역 (텍스처, 버퍼 등)을 업데이트하는 것은 렌더링 상태를 변경하는 것과는 다릅니다.

렌더링 상태 변경을 비싸게 만드는 것은 새로운 상태를 확인하고 파이프 라인을 재정렬하기 위해 드라이버가해야하는 작업량입니다. 이것은 또한 CPU와 그래픽 장치 사이에 동기화가 발생할 가능성이 높습니다. 그러나 장치간에 전송되는 데이터의 양은 상태 변경 (아마도 몇 개의 명령)에 비해 작아야합니다.

반면에 텍스처 / 버퍼 업데이트의 경우 주요 비용은 데이터 전송 자체에 있습니다. 이론적으로 업데이트 후 텍스처 데이터를 CPU로 다시 읽지 않는 한 동기화 또는 파이프 라인 중단이 없어야합니다. 그러나 API 오버 헤드라는 또 다른 측면을 고려해야합니다. 그래픽 장치로 전송하는 데이터의 양이 적더라도 자주 그렇게하면 드라이버 / 장치와의 통신 비용이 데이터 전송 비용보다 높아집니다. 이것이 렌더러를 최적화 할 때 일괄 처리가 중요한 이유 중 하나입니다.

따라서 귀하의 경우 가장 좋은 방법은 새 데이터가 도착 할 때마다 업데이트하는 텍스처의 시스템 메모리 사본을 유지하는 것입니다. 더티 플래그를 설정하고 가능한 glTexSubImage한 많은 텍스처를 전체 텍스처 (또는 큰 순차적 부분)에 하나로 통합하십시오. 또한 Pixel Buffer Objects 를 사용하여 비동기 데이터 전송을 시도하여 파이프 라인 중단을 가능한 한 줄이십시오. 어떤 종류의 이중 버퍼링을 구현할 수 있으면 텍스처의 한 복사본에 다른 복사본을 렌더링하는 동안 쓸 수 있습니다. 이 튜토리얼그 시나리오를 탐구합니다. 그것은 직관적 인 접근법입니다. API 호출 수를 줄이고 텍스처 업데이트를 "일괄 처리"하려고했습니다. 즉, 이것은 매우 추측 적이며 사용 사례에서 가장 성능이 좋은 것을 확인하기 위해 몇 가지 작은 업데이트를 수행하는 것과 같은 다른 접근 방식과 프로파일 링하고 비교해야합니다.

부수적으로, NVidia의이 프레젠테이션은 관련성이 있으며 OpenGL에서 Zero Driver Overhead에 접근 하는 좋은 통찰력을 제공 합니다 .


5
확실하지는 않지만 PC 드라이버가 종종 프레임을 버퍼링하려고 시도하기 때문에 마지막 프레임 또는 2에서 렌더링 된 텍스처의 glTexSubImage가 파이프 라인을 정지시킬 것으로 의심됩니다. 작은 업데이트로 인해 전체 텍스처를 복사하려고합니다. 따라서 최대 성능을 위해서는 텍스처 또는 픽셀 버퍼 객체를 이중 또는 삼중 버퍼링해야합니다.
John Calsbeek
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.