por
pobrecito hablador
el Jueves, 11 Diciembre de 2008, 22:06h
(#1107510)
Un shader se compila en tiempo de ejecución.
Pero se compila bajo demanda, no Just In Time (como el bytecode de Java o el de C#). Así que el hecho de que se compile en tiempo de ejecución no afecta a la calidad final del código absolutamente en nada. Esto se hace así con los shaders porque un mismo código tiene que correr en muchas tarjetas distintas (con distintas microarquitecturas, etc), así que definen un lenguaje intermedio que se pasa al código que entiende la tarjeta cuando ya sabes en qué tarjeta se va a ejecutar (no hablo de los perfiles, hablo de las arquitecturas). A ese código intermedio se puede compilar tanto en tiempo de ejecución como antes. La compilación es estática, NO DINÁMICA.
De hecho si está escrito en cg, el mismo shader sirve para tarjetas ati y para nvidia (y sus arquitecturas son completamente diferentes).
NO. De completamente diferentes NADA. Ambas hacen exactamente lo mismo. Ambas implementan una tubería gráfica y los shaders se cargan para procesar dos estados (tres en DX10 y OGL2) de la tubería. Lo que tienen que hacer es de sobra conocido, así que un código que está escrito para hacer esas etapas, no otra cosa, no requiere de ningún tipo de optimización especial para correr en una u otra tarjeta, Cg ya expone, como lenguaje específico para esas cosas, toda la funcionalidad para que el programador la use a manita. Solo requiere que se compile para un juego de instrucciones u otro, a lo sumo con algún tipo de restricción en los tipos u operaciones que puede utilizar (que es lo que hace un shader no funcione exactamente igual en todas las tarjetas, o incluso que no corra si no soporta un perfil determinado).
No es para nada el caso del que estamos hablando.
Al paralelizar un programa no importa la arquitectura, sólo las dependencias entre los datos.
Las dependencias son importantes para ENCONTRAR paralelismo, no para paralelizar ese código.
Una suma de matrices se paraleliza igual en una gpu, en un cell, un intel o lo que sea.
Los cojones treinta y tres. Tanto para CUDA como para Cell como para Intel tienes implementaciones de referencia de una multiplicación de matrices. Y oye, qué curioso, no se parecen en nada. Eso hablando en concreto. Incluso desde el punto de vista más general, cuando analizas una multiplicación de matrices encuentras paralelismo en los tres bucles, dos de ellos de un tipo y otro de otro tipo. Pero NADIE te dice qué haces con ese paralelismo. ¿Paralelizamos el bucle externo? ¿Los dos bucles externos? ¿El externo por bloques y el más interno de todos una reducción logarítmica? No, en serio, mejor no hables de lo que no sabes.
Te digo más. Si conoces un compilador que vea una multiplicación de matrices y, de forma automática, sea capaz de sacarte la implementación de referencia del Cell, estaré aquí esperando para que me des en toda la boca con él. Pero vamos, que ya te lo avanzo: ese compilador está por aparecer.
Re:Opinión a primera vista
(Puntos:0)Pero se compila bajo demanda, no Just In Time (como el bytecode de Java o el de C#). Así que el hecho de que se compile en tiempo de ejecución no afecta a la calidad final del código absolutamente en nada. Esto se hace así con los shaders porque un mismo código tiene que correr en muchas tarjetas distintas (con distintas microarquitecturas, etc), así que definen un lenguaje intermedio que se pasa al código que entiende la tarjeta cuando ya sabes en qué tarjeta se va a ejecutar (no hablo de los perfiles, hablo de las arquitecturas). A ese código intermedio se puede compilar tanto en tiempo de ejecución como antes. La compilación es estática, NO DINÁMICA.
NO. De completamente diferentes NADA. Ambas hacen exactamente lo mismo. Ambas implementan una tubería gráfica y los shaders se cargan para procesar dos estados (tres en DX10 y OGL2) de la tubería. Lo que tienen que hacer es de sobra conocido, así que un código que está escrito para hacer esas etapas, no otra cosa, no requiere de ningún tipo de optimización especial para correr en una u otra tarjeta, Cg ya expone, como lenguaje específico para esas cosas, toda la funcionalidad para que el programador la use a manita. Solo requiere que se compile para un juego de instrucciones u otro, a lo sumo con algún tipo de restricción en los tipos u operaciones que puede utilizar (que es lo que hace un shader no funcione exactamente igual en todas las tarjetas, o incluso que no corra si no soporta un perfil determinado).
No es para nada el caso del que estamos hablando.
Las dependencias son importantes para ENCONTRAR paralelismo, no para paralelizar ese código.
Los cojones treinta y tres. Tanto para CUDA como para Cell como para Intel tienes implementaciones de referencia de una multiplicación de matrices. Y oye, qué curioso, no se parecen en nada. Eso hablando en concreto. Incluso desde el punto de vista más general, cuando analizas una multiplicación de matrices encuentras paralelismo en los tres bucles, dos de ellos de un tipo y otro de otro tipo. Pero NADIE te dice qué haces con ese paralelismo. ¿Paralelizamos el bucle externo? ¿Los dos bucles externos? ¿El externo por bloques y el más interno de todos una reducción logarítmica? No, en serio, mejor no hables de lo que no sabes.
Te digo más. Si conoces un compilador que vea una multiplicación de matrices y, de forma automática, sea capaz de sacarte la implementación de referencia del Cell, estaré aquí esperando para que me des en toda la boca con él. Pero vamos, que ya te lo avanzo: ese compilador está por aparecer.