OpenGL이 실제로 화면을 업데이트하는 데 시간이 얼마나 걸립니까?

키 입력에 대한 응답으로 다른 것을 그리는 C에 간단한 OpenGL 테스트 앱이 있습니다. (Mesa 8.0.4, NVIDIA GTX650이 설치된 PC에서 Mesa-EGL 및 GLFW, Ubuntu 12.04LTS로 시도) 추첨은 매우 간단하고 빠릅니다 (삼각형의 회 전형). 내 테스트 코드는 어떤 식 으로든 프레임 속도를 의도적으로 제한하지 않으며 다음과 같이 보입니다.

while (true)
{
    draw();
    swap_buffers();
}

나는 이것을 매우 신중하게 시간을 정했고, 한 번 eglSwapBuffers()(또는 glfwSwapBuffers같은 것)에서 다음 번까지의 시간 은 ~ 16.6 밀리 초라는 것을 알았습니다 . 전화가 끝나고 eglSwapBuffers()다음 전화가되기 직전 까지 걸리는 시간은 그 내용이 매우 단순하지만 그보다 약간 적습니다. 스왑 버퍼 호출에 걸리는 시간은 1ms 미만입니다.

그러나 앱이 키를 누르면 화면에 실제로 나타나는 변경에 대한 응답으로 그림이 바뀌는 시간 은> 150ms (약 8-9 프레임 가치)입니다. 이것은 60fps에서 화면과 키보드의 카메라 녹화로 측정됩니다.

따라서 질문 :

1. 스왑 버퍼 호출 사이에 드로우가 어디에 버퍼링되고 실제로 화면에 표시됩니까? 왜 지연? 앱이 항상 화면보다 많은 프레임을 그리는 것처럼 보입니다.

2. OpenGL 응용 프로그램으로 화면을 즉시 그릴 수있는 방법은 무엇입니까? (즉 : 버퍼링 없음, 그리기가 완료 될 때까지 막기; 높은 처리량이 필요없고 낮은 대기 시간이 필요합니다)

3. 위의 즉각적인 추첨을 가능한 빨리하기 위해 응용 프로그램은 무엇을 할 수 있습니까?

4. 응용 프로그램은 현재 화면에 실제로 무엇이 있는지 어떻게 알 수 있습니까? (또는 현재 버퍼링 지연이 얼마나 오래 / 얼마나 많은 프레임입니까?)

CPU에서 호출 된 모든 드로잉 API 함수는 GPU에 의해 나중에 실행될 수 있도록 GPU 명령 링 버퍼 에 제출됩니다 . 이것은 OpenGL 함수가 대부분 비 차단 함수라는 것을 의미합니다. 따라서 CPU와 GPU가 동시에 작동합니다.

가장 중요한 점은 응용 프로그램이 CPU 또는 GPU 바인딩 일 수 있다는 것입니다. glFinish를 호출하면 CPU가 더 많은 시간이 걸리고 CPU가 정지 될 수있는 경우 응용 프로그램이 GPU에 바인딩 된 경우 CPU가 그리기 명령을 완료 할 때까지 기다려야합니다. GPU가 드로잉 명령을 마치고 CPU가 너무 오래 걸리면 응용 프로그램이 CPU에 바인딩됩니다.

그리고 사이에 차이가 있음을 유의 glFlush하고 glFinish.

glFlush: GL에 이전에 전송 된 모든 명령이 유한 시간 내에 완료되어야 함을 나타냅니다.

glFinish: 모든 이전 GL 명령을 강제로 완료합니다. GL 클라이언트와 서버 상태 및 프레임 버퍼에 대해 이전에 발행 된 명령의 모든 효과가 완전히 실현 될 때까지 완료가 리턴되지 않습니다. "

glXSwapBuffers 는 암시적인 glFlush를 수행하기 전에 수행합니다. 후속 OpenGL 명령은 glXSwapBuffers를 호출 한 직후에 발행 될 수 있지만 버퍼 교환이 완료 될 때까지 실행되지 않습니다.

실제 프레임 시간은 두 CPU / GPU 중 어느 것이 작업을 완료하는 데 더 많은 시간이 걸리는지에 따라 결정됩니다.

OpenGL은 기술적으로 화면을 업데이트하지 않습니다.

이를 수행하는 GL (예 : GLX, WGL, CGL, EGL)과 별 개인 창 시스템 API가 있습니다. 이러한 API를 사용하는 버퍼 스왑은 일반적으로 암시 적으로 호출 glFlush (...)되지만 일부 구현 (예 : Windows의 GDI 래스터 라이저)에서는 전체를 수행합니다 glFinish (...).

    ^{* 왼쪽에는 ICD (하드웨어) 경로가 SwapBuffers (...)있습니다. 오른쪽에는 GDI (소프트웨어) 경로가 있습니다.}

VSYNC를 활성화하고 이중 버퍼링 한 경우 보류중인 스왑이 발생하기 전에 백 버퍼를 수정하는 모든 명령이 스왑 될 때까지 정지 해야합니다 . 명령 대기열의 깊이는 제한되어 있으므로이 지연된 명령은 결국 파이프 라인에 교통 체증을 유발합니다. 이는 SwapBuffers (...)애플리케이션 에서 차단하는 대신 VBLANK가 롤오버 될 때까지 실제로 관련되지 않은 일부 GL 명령 을 차단 함을 의미 할 수 있습니다. 실제로 요약하면 스왑 체인에 얼마나 많은 백 버퍼가 있는지입니다.

모든 백 버퍼가 완성 된 프레임으로 가득 차서 앞으로 이동하지 않는 한 스왑 버퍼는 암시 적으로 블로킹을 유발합니다. 안타깝게도 대부분의 GL 윈도우 시스템 API에서 사용하는 백 버퍼 수를 명시 적으로 제어 할 수있는 방법이 없습니다 ( 0 개의 단일 버퍼 또는 1 개의 이중 버퍼 제외). 드라이버는 원하는 경우 2 개의 백 버퍼를 자유롭게 사용할 수 있지만 (트리플 버퍼링) GLX 또는 WGL과 같은 것을 사용하여 애플리케이션 레벨에서이를 요청할 수 없습니다.

이 실험에 익숙하다고 생각 하십니까?

본질적으로 John Carmack은 비슷한 작업을 수행하여 화면을 기록하고 화면으로 전송되는 타이밍 픽셀을 기록했습니다. 그는 많은 대기 시간이 화면에서 나왔다는 것을 발견했습니다. 다른 요인은 키보드, 비디오 드라이버 및 프로그램 자체의 입력 지연으로 인한 입력 지연이었습니다.