he probado un test de velocidad cambiando el valor de un shader
for (int i = 0; i < 1000; i++)
{
shader.SetValue("g_MaterialAmbientColor", new ColorValue(0.35f, 0.35f, 0.35f, 0));
}
mi sorpresa es que de 3000fps me baja a 200fps, ¿es normal esto o hay algun truco para acelerar el tema?, es importante decir que no activo el shader, con el shader solo se hace el cambio de este valor
y si no se puede acelerar, ¿que sale mejor ... tener 1000 shaders ya configurados o cambiarle el valor?
saludos
Saludos
Creo que aqui hay dos asuntos que puedes probar:
1. Hacer un new en cada iteracion puede ser costoso, aunque no el impacto de esto en el C#...
2. No se puede obtener el handle del valor "g_MaterialAmbientColor" previamente? Es decir, que hagas algo asi como setValue(matAmbientColorHandle, ...), ya que al pasarle un string setValue tiene que hace un hash del mismo en cada llamada. Hasta donde yo recuerde esto es perfectamente posible conseguir un handle de este tipo en Direct3D con las HLSL (yo como todavia tiro de asm :P)
efectivamente, usa un handle ;)
se gana 500 fps, pero sigue relantizando el asunto, de 3000fps bajar a 700fps por eso me parece una burrada
(ups! doble post)
Ten en cuenta que cuando tienes un porron de fps, bajan con cierta facilidad al añadir casi que cualquier cosa.
Para hacer pruebas de rendimiento, mide el tiempo que se toma en hacer la rutina, y pasa de los fps.
para probarlo mejor, en lugar de hacer un new, haz esto:
ColorValue c=new ColorValue(0.35f, 0.35f, 0.35f, 0);
for (int i = 0; i < 1000; i++)
{
shader.SetValue("g_MaterialAmbientColor", c);
}
si, ya lo habia probado, pero no se nota diferencia alguna
con 1000 me baja a 700fps, con 2000 a 450fps, con 3000 a 240fps, cada mil me baja un 50% aproximado usando los handles, ya no se como ordenar el renderizado, por lo mas cercano a los mas lejano por los estados de los shaders, por tutatis :P
zupervaca, no caigas en la trampa de los FPS, ya que son engañosos! (dicho en tono epico ;))
Recuerda que el asunto no es lineal. Para una mejor medida usa el frametime, que es el tiempo que consume cada frame. Asi veras mejor el cambio que supone, y no ese 50% de FPS que es totalmente engañoso.
Por cierto... que estas dibujando para que todo te vaya a 3000, 1000 y tal? Ya nos contaras ;)
Estoy de acuerdo, con los FPS pasa algo similar a la velocidad y el rozamiento de los objetos, cuanto mayor es la velocidad mas afecta a esta el rozamiento que en este caso seria el codigo.
Yo para asegurarme meteria algun grafico cargado hasta que bajase a 100fps (que ya es una buena velocidad), y luego meteria el codigo a probar, dudo mucho que baje un 90% como te ocurre ahora.
Cita de: "Mandelbrot"Yo para asegurarme meteria algun grafico cargado hasta que bajase a 100fps (que ya es una buena velocidad), y luego meteria el codigo a probar, dudo mucho que baje un 90% como te ocurre ahora.
Yo, por mi parte, usaría el periodo de trabajo que es el inverso del FPS. Si
FPS = nFrames/nSegundos.
P = nSegundos/nFrames.
Esto te dice cuánto tarda en calcular/renderizar/etc un frame. Se mide en unidades de tiempo (segundos para lo de arriba).
Por ejemplo, si te baja de 3000fps a 200fps, lo que está pasando es que estás subiendo el periodo de trabajo de 1/3000fps=0,33ms a 1/200fps=5ms. Es decir, que lo que metes te cuesta 4,66ms.
Si tuvieras un framerate de, digamos 50fps=20ms, pasarías a 24,66ms=40,55fps. Ya parece menos.
Mejor usar medidas lineales como el periodo. Con este tipo de medidas, puedes estudiar el rendimiento y hacer predicciones con la Ley de Amdahl.
Interesante teoria gdl.
Por cierto, ya que a salido, probar 1/3000 en buestra calculadora de windows. :P
Saludos.
Esta muy bien el metodo ese para medir el tiempo que tarda en hacerse algo con bastante precision (me lo apunto), yo siempre he usado timeGetTime() al comienzo y final de lo que quiero medir, y aunque aunque es util para medir varias partes individualmente y mostrarlas en pantalla simultaneamente, tiene el problema de que su escasa resolucion en milesimas de segundo muchas veces no sirve, ¿conoceis alguna otra forma para poder medir el tiempo en millonesimas o mas?
Cita de: "Mandelbrot"¿conoceis alguna otra forma para poder medir el tiempo en millonesimas o mas?
Para eso probablemente lo mejor que hay es lo que hace zupervaca; realizar la operacion 1000 veces y luego dividir el tiempo empleado entre 1000 (por ejemplo).
Citar¿conoceis alguna otra forma para poder medir el tiempo en millonesimas o mas?
Te pueden servir :
QueryPerformanceCounter()QueryPerformanceFrequency()Que son las funciones para el timer de alta resolucion, si esta presente en la maquina claro, a dia de hoy, seria raro que no estubiesen.
Saludos.
Efectivamente Grey, precision de millonesimas de segundo!!!. sera suficiente para evitar las odiosas repeticiones en muchos casos, estaria bien saber si el tiempo medido asi coincide con la prediccion de gdl, por lo que con QueryPerfomanceCounter deberia dar 4,66ms ¿no?, a ver si zupervaca se anima a probarlo y nos cuenta, creo que lo he implementado bien asi, echadle un vistazo.
double t1, t2, frec, tiempoConsumido;
int repeticiones=1000;
if (QueryPerformanceCounter((LARGE_INTEGER *)&t1))
{
for (int i=0;i {
shader.SetValue("g_MaterialAmbientColor", new ColorValue(0.35f, 0.35f, 0.35f, 0));
}
QueryPerformanceCounter((LARGE_INTEGER *)&t2);
QueryPerformanceFrequency((LARGE_INTEGER *)&frec);
tiempoConsumido=(t2-t1)*1000/frec; // en microsegundos
tiempoConsumido/=repeticiones;
}
En cualquier caso parece claro que es mejor testar con tiempos de ejecucion que con fps.
meti la gamba en el comentario del codigo, el resultado es en milisegundos, no en microsegundos, ya que lo multiplique por 1000.