Stratos: Punto de Encuentro de Desarrolladores

¡Bienvenido a Stratos!

Acceder

Foros





Shaders Y El Setvalue

Iniciado por zupervaca, 01 de Agosto de 2005, 12:03:08 PM

« anterior - próximo »

zupervaca

 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

AK47

 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)

Haddd

 efectivamente, usa un handle  ;)  

zupervaca

 se gana 500 fps, pero sigue relantizando el asunto, de 3000fps bajar a 700fps por eso me parece una burrada

Lord Trancos 2

on los años y mucho esfuerzo he llegado a atesorar una ignorancia total sobre casi todas las cosas.
Gate to Avalon (mi Blog)

Lord Trancos 2

 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.  
on los años y mucho esfuerzo he llegado a atesorar una ignorancia total sobre casi todas las cosas.
Gate to Avalon (mi Blog)

Haddd

 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);
          }




zupervaca

 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

AK47

 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 ;)

Mandelbrot

 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.

gdl

 
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.




_Grey

 Interesante teoria gdl.

Por cierto, ya que a salido, probar 1/3000 en buestra calculadora de windows. :P

Saludos.

Mandelbrot

 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?

Lord Trancos 2

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).
on los años y mucho esfuerzo he llegado a atesorar una ignorancia total sobre casi todas las cosas.
Gate to Avalon (mi Blog)

_Grey

 
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.






Stratos es un servicio gratuito, cuyos costes se cubren en parte con la publicidad.
Por favor, desactiva el bloqueador de anuncios en esta web para ayudar a que siga adelante.
Muchísimas gracias.