2010-07-13 29 views
10

El título resume bastante bien mi pregunta: ¿hay algún de código abierto OpenGL profilers para Linux?Analizador de código abierto OpenGL para Linux

Lo único que pude encontrar fue gDEBugger, pero solo viene con una versión de prueba de 7 días y está muy cerrado. Usaría esto para el desarrollo de software gratuito (como en libertad), así que pagar no es una opción, aunque podría considerar aceptar respuestas para una aplicación gratuita (como en la cerveza) pero cerrada. Puntos de bonificación si funciona con controladores de código abierto (mi computadora principal tiene una tarjeta gráfica Intel integrada).

Respuesta

6

Eche un vistazo a BuGLe. Su objetivo principal no es perfilar, pero tiene un filter, que muestra el tiempo pasado en cada llamada OpenGL.

+0

+1! No es realmente lo que necesito pero parece útil. Y uno puede esperar que incluyan soporte adecuado de perfiles en el futuro. – Staffan

+1

Gracias por la sugerencia. Probé BuGLe y es fantástico (además de gratuito y de código abierto). Sin embargo, me llevó un poco de trabajo obtener una salida de generación de perfiles útil, así que agregué una [nueva respuesta] (http://stackoverflow.com/a/8859325/368821) describiendo en detalle cómo logro una buena salida de creación de perfiles. – mgiuca

1

Realmente recomendaría este pequeño generador de perfiles: http://silverspaceship.com/src/iprof/, no está obligado a perfilar OpenGL, ¡pero lo hace muy bien! También puede usar OpenGL para mostrar las estadísticas de perfiles, lo que significa que es muy portátil.

+0

Aparte de ser interactivo, ¿cómo es esto diferente de gprof, oprofile, callgrind, etc.? AFACIT no proporciona ningún medio para realizar un perfil de OpenGL adecuado. – Staffan

+0

@staffan: Supongo que la única ventaja que tiene es que presenta las estadísticas de perfil en relación con el frametime. Y puede tenerlo funcionando todo el tiempo, solo congélelo si experimenta una caída de velocidad de fotogramas y retrocede hasta que vea qué bloque de creación de perfiles causó la desaceleración. Me resulta complicado encontrar marcos cuando se utilizan herramientas de generación de perfiles estáticos/de registro. – Greget

1

me gustaría utilizar esto para el desarrollo de software libre por lo que pagar no es una opción

"libre" no significa "código abierto".

Ver si NVPerfKit, NVPerfSDK son adecuados para usted. He usado NVPerfHud para perfilar aplicaciones DirectX antes, y si NVPerfKit ofrece incluso un poquito de la funcionalidad de PerfHud para OpenGL, será exactamente lo que está buscando.

Además, consulte la página de NVIdia OpenGL resources.

+0

+1 ya que esto es relevante y parece ser exactamente lo que necesito. Lamentablemente, no tengo una tarjeta gráfica NVidia. – Staffan

+0

@Staffan: Bueno, podría ver si esto es lo que quiere: http://developer.amd.com/gpu/StreamProfiler/Pages/default.aspx. Personalmente, prefiero usar tarjetas NVidia para el desarrollo (y no he usado la tarjeta ATI en años), por lo que no puedo decir si este "generador de perfiles de flujo" es adecuado para sus objetivos. Además, si tiene una tarjeta creada por otra persona (tarjeta que no es de ATI y que no es de NVidia), * puede * no tener suerte. – SigTerm

+0

@Staffan: Otra opción (arriesgada) sería utilizar algún tipo de implementación de software OpenGL y perfilarlo utilizando perfiladores de CPU. Lo más parecido que puedo pensar es Mesa3D, pero no está certificado, y no es totalmente compatible con OpenGL. Para mí, parece que los datos de rendimiento dependen del proveedor, por lo que es posible que no haya un generador de perfiles genérico que sea útil para cada tarjeta. – SigTerm

9

Gracias a la respuesta de @cypheon, revisé BuGLe. Es fantástico, pero tuve que pasar un poco de tiempo para obtener resultados útiles de creación de perfiles. Quería agregar esto como un comentario sobre esa respuesta, pero realmente necesito pegar ejemplos de código completo, así que comencé una nueva respuesta.

Como sugirió, el filtro stats_calltimes es bueno para crear perfiles, no es ideal (ya que no muestra información de la pila), pero con un poco de trabajo, puede mostrar el tiempo total para cada función GL por cuadro

Debe editar los archivos ~/.bugle/filters y ~/.bugle/statistics. En primer lugar, añadir esta cadena al final de filters:

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

Ahora ejecutar el programa con el comando:

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

Esto imprimirá la tiempo medio de permanencia en cada función GL por cuadro. Eso no es terriblemente útil en sí mismo, porque para una llamada como glVertex, llamada miles de veces por fotograma, probablemente aparecerá como 0.00ms aunque el tiempo acumulado sea bastante significativo. Así que añadir una nueva entrada a statistics:

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

he usado el mismo truco que la estadística de "llamadas por cuadro": multiplicar y dividir por d("calls:*") para causar un error de división por cero para cualquier función que nunca fue llamado , para evitar mostrar 0.00 para todas las funciones irrelevantes.

Ahora, regresa a la cadena showcalltimes hemos añadido a filters, y cambiar "average time per call" a "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" 
    } 
} 

Y ahora vamos a ver la estadística útil del tiempo total dedicado a cada función, por cuadro. Si desea promediar estas estadísticas en muchos cuadros, elimine el comentario de las líneas anteriores key_accumulate y luego puede presionar "A" (o reasignarlo a la clave que elija) para comenzar a acumular. Con el tiempo, verá que las estadísticas dejan de rebotar tanto como promedian en muchos cuadros.

También puede registrar estas estadísticas a un archivo de salida con esta cadena:

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

Esto es bastante difícil de leer, ya que simplemente pone las estadísticas individuales para cada cuadro, una tras otra, y no he Encontré una manera de promediarlos a lo largo del tiempo. Así que mi método preferido para leer estadísticas es la cadena showcalltimes con el acumulador encendido.

-1

También me gusta Vogl mucho - Hay que ver en https://github.com/ValveSoftware/vogl

Tiene perfilado, capturar, reproducir - pero las características asesinas son las capturas de marco, puede inspeccionar todos los tampones, VARs de sombreado y así sucesivamente con sólo reproduciendo tu estado capturado.

Cuestiones relacionadas