렌더링 장면 이후에 CPU를 잠시 대기

나는 렌더링과 렌더링 사이에 휴식이 포함 된 3D 프로그램을 제공하는 것이 좋습니다. 사실입니까? 이것이 CPU 부하를 줄이거 나 관계 없습니까?렌더링 장면 이후에 CPU를 잠시 대기

그렇다면 어떤 방법을 권하고 싶습니까? 또한 프레임 률 캡 (60fps의 캡)과 관련이 있으며, 다른 프레임을 렌더링 할 시간이 아닌 경우 나머지 프레임을 렌더링하여 60fps 마크를 충족해야 할 때까지 기다려야합니다.

OpenGL 및 C++을 사용하고 있습니다.

출처

2012-01-18 Satchmo Brown

단순한 장면의 경우 이는 좋은 생각 일 수 있습니다. 그렇지 않으면 2000fps로 장면을 렌더링 할 수 있습니다. 실제로 화면에 120Hz 나 60Hz보다 빠르게 도달하지 않으므로 이러한 장면이 낭비됩니다. 이 낮은 CPU 사용률은 실행하려는 다른 응용 프로그램이있는 경우에 유용합니다. 유일한 게임이되도록 설계된 게임을 실행하는 경우 그러한 조절없이 full-bore에서 실행하십시오.

출처

2012-01-18 02:24:22 nmjohn

나는 동의하지 않습니다. 비록 그것이 유일하게 달리는 것이라해도, 그것은 배터리와 전력 요금을 죽이는 많은 힘을 이끌어냅니다. –

나는 "Think green!"이라고 말할 것입니다. – Luca

UX 조언 : 소프트웨어 만 설계하면 안됩니다. PC (Mac 포함) 사용자는 멀티 태스킹 환경을 기대하며 Alt + Tab 또는 응용 프로그램으로 돌아가려면 10 초 이상 기다리는 것이 이러한 환경에서는 매우 무례합니다. 스마트 폰 및 태블릿 사용자는 멀티 태스킹을 기대합니다. 게임 콘솔은 아마도 예외 일지 모르지만 저그와 관련된 경험은 거의 없습니다. –

저는 그래픽 렌더링을하기 전까지는 괜찮은 게이트웨이 컴퓨터를 가지고있었습니다. CPU는 곧 후 축배가되었습니다.

하지만 그건 컴퓨터의 결함 이었으므로 걱정할 필요가 없습니다.

출처

2012-01-18 02:24:12

나는 CPU가 쉬는 것을 기다리는 것이 렌더링 성능에 도움이된다고 들었다. 그러나 동일한 효과가 이미 발생하고 있습니다. OpenGL은 프레임 업데이트 사이에서 CPU를 쉬어야하므로 이론적 인면에서는 걱정할 필요가 없습니다. 아마도 "cpu resting"아이디어는 프레임마다 이벤트 루프를 실행하지 않는 프레임 워크에서 온 것입니다. 이것에 대한 다른 관점이 있다면 나는이 글을보고있을 것이다.

출처

2012-01-18 02:25:53

자체 OpenGL은 응용 프로그램 흐름을 지시하지 않습니다. "외부"대기 메커니즘이 없다면 OpenGL 응용 프로그램은 다른 명령처럼 자주 다시 호출 (glClear, ..., glSwapBuffers) 스팸 메일을 보낼 수 있습니다. OpenGL은 스팸으로부터 GPU를 차단할 수 있지만 CPU를 통한 전원은 없습니다. –

예, 프레임 속도를 제한하면 CPU로드가 줄어 듭니다.

또한 2000fps 인 경우 모니터에 모든 프레임이 표시되지 않으며 대개 60fps 만 표시됩니다. 낮은 엔드 PC와 대부분의 스마트 폰, CPU 등의 공유 (통합) GPU 메모리와 시스템에서

#include <boost/thread.hpp> 
#include <boost/date_time/posix_time/posix_time.hpp> 

long desiredFps=60; 

void drawLoop() { 
    using namespace boost; 
    using namespace boost::posix_time; 

    ptime lastDraw = microsec_clock::universal_time(); 
    while(true) { 
     ptime now = microsec_clock::universal_time(); 
     long diff = (now-lastDraw).total_microseconds(); 
     long desiredDiff = 1000000/desiredFps; 
     if(diff < desiredDiff) { 
      this_thread::sleep(microseconds(desiredDiff-diff)); 
     } 
     draw(); 
     lastDraw = now; 
    } 
}

출처

2012-01-18 02:39:48

드라이버가 V-Sync를 수행하도록 올바르게 구성되어 있고 프로그램이이를 비활성화하지 않으면 대기 루프가 필요하지 않습니다. 그런 다음 SwapBuffers는 프레임이 디스플레이로 전송 될 때까지 차단합니다. 프로그램이 멀티 스레드라면 다른 스레드가 CPU 시간을받으며 I/O, 사용자 입력 처리, 시뮬레이션 등을 위해 사용할 것을 강력하게 제안합니다. – datenwolf

대기 루프가없고 스레드 잠이기 때문에 스레드는 CPU를 받고 입력을 위협합니다. 또한 V-Sync를 사용하지 않고 FPS를 제한하려는 경우이 방법을 사용하는 것이 좋습니다. FPS를 모니터 화면 주사율보다 약간 높게 설정하거나 모니터 화면 주사율보다 느리게 설정한다고 가정 해 봅시다. –

일반적으로 프레임 속도를 정확하게 모니터 화면 주사율로 유지하려고합니다. 그렇지 않으면 당신은 비트 (V- 싱크와 함께) 또는 찢어지는 인공물을 얻습니다. 나는 while 문으로 인해 wait 루프를 잘못 이해했다. 일반적으로 실시간 그래픽 프로그램에는 "drawLoop"이 없습니다. 일정한 속도로 그리기 기능을 호출하는 이벤트 루프가 있습니다. – datenwolf

: http://en.wikipedia.org/wiki/Refresh_rate

나는 (부스트 날짜 시간 및 스레드 라이브러리를 사용하여 코드를) 다음과 같은 방법을 권장합니다 GPU는 메모리 대역폭에 대해 서로 경쟁합니다. 많은 메모리 액세스가 관련된 추가 계산을 수행하면 텍스처 읽기 및 프레임 버퍼 업데이트가 방해되어 프레임 속도가 저하됩니다.

출처

2012-02-12 01:13:14 noop

게임 엔진은 멀티 스레드되어야하며 각 스레드는 서로 다른 프레임 버퍼 개체에서 작동하므로 이중/삼중 버퍼링 방법을 사용할 수 있습니다 (필수 사항). glFinish()에 대한 호출은 스레드를 생성하지 않지만 (glX)SwapBuffers()에 대한 호출은 드로잉 작업에 사용 가능한 버퍼가 더 이상 없을 때 자동으로 CPU 사용을 최적의 지점으로 줄입니다. 거의 모든 GL 구현은이를 수행하도록 조정됩니다.

출처

2012-05-29 02:10:48 Gold

렌더링 장면 이후에 CPU를 잠시 대기

답변

관련 문제