Jok, por supuesto las shaders van precompiladas pero no van linkadas de ahí los quebraderos de cabeza de ciertos programadores a la hora de evitar que le roben sus códigos de shaders... Es el DirectX quien aplica uno u otro modelo de optimización de shaders en el caso del hardware en questión.... Muchas veces los programadores actualmente para el 9.0b si quieren hacer el juego compatible con DX7 (osease MX440) tienen que hacer el código sin shaders para que se vea correcto, muchas veces añadiendole texturas al juego (es bastante costoso y aveces crea problemas un jeugo pensado con shaders hacerlo compatible con las tarjetas DX7 como las GF4 MX)...
Luego le hacen una versión de shaders en 1.1 para las GF4 TI, luego si tienen ganas hacen una en 1.4 algo mejor que las 1.1 que lo aprovechan las ati 8500, 9000, 9100 y 9200, pero muchas veces se olvidan de este modo. Luego realizan otro para las 2.0_a y luego otro para las 2.0_b
Las 2.0_a es para los modelos 9500 y 9700 y las 2.0_b són para los modelos 9600 y 9800 y las GF FX.
A partir del 9.0c y todo devido a los diferentes modelos de hardware para los shaders. Se hará el 2.0_c y el 3.0 a añadir despues de todos los que ya existian.
La tendencia en los juegos que se están diseñando actualmente es a realizar los juegos ya pensando en DX9 y no en DX8 camo se han ido realizando hasta ahora. Al hacer esto a un programador le saldrá más a cuenta realizar los shaders para DX8 en 1.4 haciendo así que al compilarlos en DX en 1.1 se hagan 3 pasadas por shaders relentizando de sobremanera las GF4 TI. En DX9 parece ser que pasará lo contrario a lo que pasa actualmente ya que pocos son los juegos que aprovechan las ventajas de los shaders 2.0_b ya que todos producen el mismo código que el producido mediante el 2.0_a (Far Cry o Tom Raider es un ejemplo de lo contrario)...
A partir de ahora se programará pensando en los 3.0 y los 2.0_b y 2.0_c lo que se hará es programar shaders en 3.0 y pasarle el código a 2.0_c que se convierte automáticamente el 99% del código haciendo el shader 2.0_c más largo (de ahí la ventaja de rendimiento teórico de los 3.0 aplicados sobre el mismo hard) y luego se diseñará el resto de shaders para 2.0_b y el 1% del código del 3.0 no transportable al 2.0_c (displacemente mapping) será acogido del 2.0_b seguramente para no tener que diseñar un tercer código de shaders para DX9)
Al contrario de lo que pasaba hasta ahora seguramente empezemos a ver shaders en las 9500 y 9700 que las cogerán de las 1.4 en lugar de las 2.0_b los que quieran ahorrarse rediseñar los shaders en 2.0_a. Esto tambien puede probocar problemas para diseñar los ForceWare de Nvidia los cuales se aprovechaban de esto que realiza el DX, para adaptar shaders con profundidad de 32 bits y registros de profundidad parcial a 16bits. Los cuales ya se ha podido ver en la última versión que solo han dejado a 16 bits los registros temporales haciendo que los registros vuelvan a tener los 32 bits que tenian en los antiguos detonator. Seguramente en cuanto esta situación les creee más problemas y la gama FX quede olvidada vuelvan a colocar para evitar cualquier tipo de fallo la profundidad incluso de los registros temporales a 32 bits en lugar de 16 bits parciales.
Por eso el asúnto es que incluso dentro de la gama de shaders 2.0 podremos ver diferencias de calidad de imágen en shaders, pero eso ocurrirá cuando los programadores hayan realizado el software necesario para verlas. De momento solo el FarCry tiene shaders específicos en los dos diferentes métodos de 2.0 actuales en el 9.0b de DX.
Esto lo ley en los foros de Beyond3D de los comentarios de diversos programadores que están trabajando ya con la beta del SDK del 9.0c algo molestos por el esfuerzo que supone realizar 6 tipos diferentes de shaders... y dan gracias a que solo existan Nvidia y ATI ya que existiran 16 marcas compitiendo seguramente tendrian que realizar 839472983740298 tipos de shaders diferentes y su mosqueo era bastante importante...
OpenGL por ejemplo con su ARB2 tiene otra filosofia... Tu creas el shader uno único y si puede el Hard lo ejecuta y si no puede no lo ejecuta perdiendo así posibilidad de explotar el Hard pero facilitando la creación de software sobre el mismo. Aun así en OpenGL parece ser que el problema de la "privacidad" ante el robo de código de las Shaders parece ser aún más problemática.
A mi me has convencido totalmente xD por cierto alguien me deja 500 €?? 
