2010-07-13 5 views
10

제목은 내 질문을 상당히 잘 요약합니다. 오픈 소스 Linux 용 OpenGL 프로파일 러는 있습니까?리눅스 용 오픈 소스 OpenGL 프로파일 러

내가 찾을 수있는 유일한 것은 gDEBugger이지만 7 일 평가판이 제공되며 매우 닫힌 소스입니다. 무료 (소프트웨어 에서처럼) 소프트웨어 개발을 위해 이것을 사용할 것이므로 지불은 무료가 아닙니다. 보너스는 오픈 소스 드라이버 (내 메인 컴퓨터에는 통합 인텔 그래픽 카드가 있음)와 함께 작동하는 경우 표시됩니다.

답변

6

BuGLe을 살펴보십시오. 주요 대상은 프로파일 링이 아니지만 filter입니다. 각 OpenGL 호출에 소요 된 시간을 보여줍니다.

+0

+1! 실제로 필요한 것은 아니지만 유용합니다. 그리고 미래에 적절한 프로파일 링 지원을 포함하기를 희망 할 수 있습니다. – Staffan

+1

팁 주셔서 감사합니다. 나는 BuGLe를 시험해 보았고 환상적이다. (물론 자유롭고 오픈 소스 다.) 그러나 유용한 프로파일 링 출력을 얻으려면 약간의 작업이 필요하므로 좋은 프로파일 출력을 얻는 방법을 자세히 설명하는 [새로운 대답] (http://stackoverflow.com/a/8859325/368821)을 추가했습니다. – mgiuca

1

저는이 작은 프로파일 러를 권장합니다 : http://silverspaceship.com/src/iprof/, 프로파일 링에 의존하지는 않지만 매우 잘합니다! 또한 OpenGL을 사용하여 프로파일 링 통계를 표시 할 수 있으므로 매우 유용합니다.

+0

대화식이 아니라 gprof, oprofile, callgrind 등과 어떻게 다른가요? AFACIT는 적절한 OpenGL 프로파일 링을 수행 할 수있는 방법을 제공하지 않습니다. – Staffan

+0

@staffan : 유일한 장점은 프레임 시간을 기준으로 프로파일 링 통계를 제공한다는 것입니다. 그리고 당신은 그것이 항상 실행되도록 할 수 있습니다. 프레임 율이 떨어지는 경우 프로파일 링 블록이 느려짐을 느낄 때까지 동결시키고 뒤로 움직이십시오. 정적/로깅 프로파일 링 도구를 사용할 때 프레임 드롭을 찾는 것이 까다로운 일입니다. – Greget

1

내가 지금 지불하는 무료 소프트웨어 개발이을 사용하는 것은 "자유", "오픈 소스"를 의미하는 것은 아니다 옵션

없습니다.

NVPerfKit, NVPerfSDK이 적합한 지 확인하십시오. 이전에 DirectX 응용 프로그램을 프로파일 링하기 위해 NVPerfHud를 사용했으며, NVPerfKit에서 PerfHud의 OpenGL 용 기능도 조금이라도 제공한다면, 사용자가 찾고있는 것입니다.

또한 NVIdia의 OpenGL resources 페이지를 확인하십시오.

+0

+1이 관련성이 있으며 정확히 필요한 것으로 보입니다. 불행히도 NVidia 그래픽 카드가 없습니다. – Staffan

+0

@Staffan : 글쎄, 당신이 원하는 것인지 확인할 수 있습니다 : http://developer.amd.com/gpu/StreamProfiler/Pages/default.aspx. 개인적으로 NVidia 카드를 개발에 사용하는 것을 선호합니다 (그리고 수년 동안 ATI 카드를 사용하지 않았기 때문에).이 "스트림 프로파일 러"가 목표에 적합한 지 말할 수 없습니다. 또한, 다른 사람 (ATI가 아닌 비 NVidia 카드)이 만든 카드를 가지고 있다면 행운이 될 수 있습니다. – SigTerm

+0

@Staffan : 또 다른 (위험한) 옵션은 일종의 소프트웨어 OpenGL 구현을 사용하고 CPU 프로파일 러를 사용하여 프로파일 링하는 것입니다. 내가 생각할 수있는 가장 가까운 것은 Mesa3D이지만 인증되지 않았으며 OpenGL과 완벽하게 호환되지 않습니다. 나에게 성능 데이터는 공급 업체에 따라 다르기 때문에 모든 카드에 유용한 일반적인 GPU 프로파일 러가 없을 수도 있습니다. – SigTerm

9

@ cypheon의 답변 덕분에 BuGLe를 체크 아웃했습니다. 환상적이지만 유용한 프로파일 링 출력을 얻으려면 약간의 시간을 소비해야했습니다. 이 답변에 대한 의견으로 추가하고 싶었지만 전체 코드 예제를 붙여 넣어 새로운 답변을 시작해야했습니다.

그가 제안했듯이 stats_calltimes 필터는 프로파일 링에 적합합니다 (호출 스택 정보를 표시하지 않으므로 이상적이지는 않지만) 약간의 작업만으로도 각 GL 함수의 전체 플랫 시간을 표시 할 수 있습니다 프레임 당.

~/.bugle/filters~/.bugle/statistics 파일을 모두 편집해야합니다.

chain showcalltimes 
{ 
    filterset stats_calls 
    filterset stats_calltimes 
    filterset showstats 
    { 
     show "average time per call" 
    } 
} 

이제 명령으로 프로그램을 실행합니다 : 첫째, filters의 끝이 체인을 추가

BUGLE_CHAIN=showcalltimes LD_PRELOAD=libbugle.so <your-program> 

이 프레임 당 각 GL 기능에서 보낸 평균 시간을 인쇄합니다. 프레임 당 수천 번 호출되는 glVertex과 같은 호출의 경우 누적 시간이 상당히 중요하더라도 0.00ms로 표시되기 때문에 그 자체로는별로 유용하지 않습니다. 그래서 statistics에 새 항목을 추가 호출되지 않았다 어떤 기능으로 나누기 오류가 발생하는 d("calls:*")에 의해 곱셈과 나눗셈 :

"total time per call" = d("calls:*")/d("calls:*") * d("calltimes:*")/d("frames") * 1000 
{ 
    precision 3 
    label "* (ms)" 
} 

내가 동일 "호출 프레임 당"통계와 같은 트릭을 사용 모든 관련없는 기능에 대해 0.00이 표시되지 않도록합니다.

이제, 우리는 filters에 추가 showcalltimes 체인 이동, 변경 "average time per call""total time per call"에 :

chain showcalltimes 
{ 
    filterset stats_calls 
    filterset stats_calltimes 
    filterset showstats 
    { 
     show "total time per call" 
     #key_accumulate "A" 
     #key_noaccumulate "I" 
    } 
} 

그리고 지금 우리는 프레임 당, 각 기능에 소요 된 총 시간의 유용한 통계를 볼 수 있습니다. 이러한 통계를 여러 프레임에 걸쳐 평균화하려면 위의 key_accumulate 줄의 주석 처리를 제거한 다음 "A"를 누르거나 원하는 키로 다시 매핑하여 누적을 시작할 수 있습니다. 시간이 지남에 따라 많은 프레임에서 평균대로 통계가 너무 많이 튀는 것을 볼 수 있습니다.

또한이 체인 출력 파일에 이러한 통계를 기록 할 수 있습니다 :

chain logcalltimes 
{ 
    filterset stats_calls 
    filterset stats_calltimes 
    filterset log 
    { 
     filename "bugle.log" 
    } 
    filterset logstats 
    { 
     show "total time per call" 
    } 
} 

이 단순히 다른 후 각 프레임 하나에 대한 개별 통계를두고 있기 때문에, 읽기가 매우 어렵습니다, 나는 천국 시간이 지남에 따라 평균을내는 방법을 찾지 못했습니다. 그래서 선호하는 통계 읽기 방법은 accumulator가 켜진 showcalltimes 체인입니다.

-1

또한 보글처럼 많은 -하지만 킬러 기능은 프레임 캡처, 당신은 모든 버퍼, 쉐이더 바르를 검사하고 그래서 그냥 의한에 수 있습니다 - 그것은 프로파일 캡처, 재생을 가지고 https://github.com/ValveSoftware/vogl

에서 확인해 캡처 된 상태를 재생합니다.