Anuncio

Anuncio Módulo
Colapsar
No hay anuncio todavía.

FUNCIONAMIENTO DE LAS TARJETAS GRAFICAS EN DIRECTX 9 Y 10

Título de Página Módulo
Transferir Eliminar Colapsar
Este es un tema pegajoso.
X
X
Detalle Conversación Módulo
Colapsar
  • Filtrar
  • Tiempo
  • Mostrar
Limpiar Todo
nuevos mensajes

  • FUNCIONAMIENTO DE LAS TARJETAS GRAFICAS EN DIRECTX 9 Y 10

    Bueno, aqui os dejo una transcripcion que he hecho de un articulo de los geniales chicos de CustomPC, explicandonos los recovecos del funcionamiento de las graficas.


    FUNCIONAMIENTO EN DIRECTX 10
    Los parentesis en negrita son "mi" explicacion
    Veamos, en este articulo los chicos de CustomPC hacen un buen trabajo expicandonos como funciona el DirectX 10, y a la vez, explican un poco sobre graficas.

    La llegada de DX 10 anuncia una nueva era para los graficos de PC. Crysis es sólo el principio. En los próximos años veremos juegos para el ordenador que ensombrecerán a los superventas más deslumbrantes de PS3 y Xbox 360. Sin embargo, este tipo de potencia trae aparejado un cambio radial, y los que

    lo van a sufrir no son los jugadores ni los programadores, sino los ingenieros de Ati y nVidia. DX 10 necesita una GPU con una arquitectura radicalmente diferente.
    Pero esta gente ya está acostumbrada a los cambios. La GPU Radeon R100 original tenia aproximadamente 30 millones de transistores, mientras que la R580 utilizada en la serie X1900 tiene 384 millones. Este aumento era necesario para soportar los números crecientes de procesadores de vertex y píxeles, y el complejo hardware de organización necesario para gestionar sus operaciones. Sin embargo, el cambio de la GPU R580 a la R600 en la (nueva) Radeon HD2900XT (ahora usan el RV670 en la HD3850/3870) de Ati va más allá de los meros números. El aumento a 700 millones de transistores no es solo cuestión de añadir mas musculo, sino también de utilizarlo de forma más eficiente y flexible.
    Para comprender esto tenemos que cambiar la forma en la que pensamos acerca de las pipelines graficas 3D.
    Tradicionalmente, las GPUs funcionaban como una maquina de salchichas o una línea de producción de una fabrica. En un extremo se ponen la geometría, las texturas y el código de shader. A continuación la GPU organiza estos materiales en bruto en varias corrientes y bloques, y envía la geometría a través de los vertex shaders, que la organizan en grupos de triángulos en el espacio 3D, que pueden rotar, escalar, mover, mezclar e iluminar si es necesario. (Bien, aquí tenemos un concepto, los vertex shaders, son la base de todo y son ellos los que transmiten los datos en bruto a algo un poco mas organizado)
    Seguidamente, la GPU toma todos los datos de vertex procesados y los reorganiza en una vista 2D de la escena 3D, realizando los cortes y selecciones necesarios. Luego esta vista se transforma en “fragmentos” de píxel, que son procesador por los pixel shaders , que se ocupan de los efectos complejos de texturas de superficies, opacidad, color e iluminación. Luego las salidas de este proceso se combinan, junto con la información del depth y stencil buffer, antes de enviarse al buffer de frames final. (Los pixel shaders procesan los datos del vertex a pixeles, que los transmitirán luego al buffer, la memoria GDDR. Tambien juega aquí los RAMDAC, que transforman la señal digital de la GPU a señal analógica para la pantalla. Normalmente hay dos RAMDAC, uno por salida DVI/VGA. Todos son iguales normalmente)
    Sin embargo, DirectX 10 no sólo altera el paso de vértices a pixeles hasta dejarlo irreconocible, sino que también las instalaciones utilizadas en el proceso. Ya no se trata de una simple línea de producción (consideremoslo “Pipeline”, que es la unidad de trabajo, compuesta por el grupo de Vertex Shaders y Pixel Shaders que actúan a la vez), sino de una compleja instalación de fabricación. La mano de obra es diferente, al igual que la estructura de dirección.

    ACERCA DE DIRECTX 10

    Hay tres nuevas características que tienen un impacto directo en lo que ha de venir. En primer lugar, DirectX 10 añade un tercer tipo de shader, el geometry shader, que puede procesar primitivas completas o multiples vértices, en contraposición a solo vértices individuales como un vertex shader. La ventaja es que podemos construir nuevos datos de vertex a partir de otros de vertex existentes formando triangulos, listas de líneas, listas de puntos o franjas, y extrapolarlos, en nuevas franjas de líneas o triangulos, o en multiples puntos.
    En segundo lugar, DirectX10 permite hacer “stream out” de los resultados de los vertex o geometry shaders de camino a los pixel shaders y que sean reutilizados por otros vertex o geometry shaders. (Bien, por lo tanto, utilizando varios ciclos de shadeo de los datos geométricos, aumenta la definición y detalle, mas que en un único ciclo como con DirectX9. Aquí juegan un gran papel los procesadores desdiferenciados, los Stream Processors)
    Finalmente, DirectX 10 utiliza lo que se llama una arquitectura de shader unificada. Esto significa que no divide sus unidades de shader en vertex shaders discretos, pixel shaders y pipelines de geometría; solo tiene shaders, y punto.

    LA MANO DE OBRA EN DX10

    Este último aspecto es particularmente importante. Si nos imaginamos una GPU R580 de Ati como una línea de producción, 8 trabajadores llevarían a cabo trabajos de vertex, y pasarían los datos de vertex a un setup engine. Desde allí, pasarían a cuatro equipos de doce trabajadores que se encargarían de los pixel shaders, estando cada equipo controlado por lo que Ati llama un procesador de dispatch con ultra-threading. Este “director de línea” se aseguraría de que, por ejemplo, i una unidad de pixel estuviese esperando a que le llegasen los datos de texturas, su trabajo actual pudiese intercambiarse por otra tarea, y que ninguna unidad de pixel estuviese ociosa durante mucho tiempo. (Es una gran ventaja, y el hecho de que Nvidia no lo tenga hace despegar a la X1950 frente a sus adversarios)
    En DirectX 10, en lugar de ocho unidades de vertex y 48 de pixel, hay bancos unificados de ALU (Arithmetic-logic units, unidades aritmético-logicas) de propósito general. Para la R600 se disponen en cuatro clusters de 16 unidades de shaders, constando cada una de 5 ALU, lo que hace un total de 320 unidades de Shader. La G80 de la GeForce 8800 GTX de nVidia dispone sus 128 procesadores stream en ocho clusters de 16, aunque no es posible una comparación directa, ya que los procesadores stream de nVidia y las unidades de shader de Ati no realizan exactamente las mismas tareas.
    Las ALU también se diferencian de las que estamos acostumbrados a ver en las GPU de generaciones anteriores. En primer lugar, están diseñadas con operaciones escalares en lugar de vectoriales como modelo dominante. ¿Qué significa esto? Mientras que un a operación escalar solo trabaja sobre un objeto de datos cada vez, una vectorial puede hacerlo sobre varios. Sin embargo, estas ultimas se pueden dividir en sucesivas operaciones escalares, y al “desempaquetarlas” de esta forma, podemos asegurar que esas instrucciones se procesan de forma mas eficiente.
    Podriamos comparar esto con cinco trabajadores en una línea de producción que enroscan ruedas en vehículos de juguete, y que tardan un minuto en terminar cada uno. Cada tres o cuatro minutos tienen que hacer coches, lo que significa que cuatro de los trabajadores están trabajando mucho mientras uno no está haciendo nada. Sin embargo, cada cuarto minuto reciben un triciclo, lo que implica que dos de ellos se quedan con las manos en los bolsillos. Sin embargo, si dividimos las tareas de tres coches y un triciclo en solo ruedas de coche y ruedas de triciclo, y asignamos la tarea también al ultimo trabajador que esta ocioso, todos nuestros obreros estarán ocupados todo el tiempo. Y también emplearan un minuto menos en hacer el trabajo. (Los coches y triciclos son cálculos vectoriales, pero la división en ruedas los convierte en escalares, como trabajan estas tarjetas).
    Utilizar el enfoque escalar permite a la GPU funcionar con un nivel de eficiencia similar. Con esto se consigue un mayor rendimiento, y ya no tendremos que pedir a los programadores de los juegos o a los compiladores de los shader que “pre-vectoricen” sus instrucciones para que el juego funcione a velocidad optima.
    En segundo lugar, no todas las ALU se crean igual. En la Radeon HD2900XT, cada unidad de shader consta de cinco ALU. Cuatro de ellas están diseñadas para encargarse de las operaciones matematicas básicas escalares y vectoriales que componen la mayor parte del trabajo estándar del shader. Sin embargo, una de esas es una especie de Super-ALU. No puede hacer todo lo que hacen las ALU normales, pero puede realizar una variedad de operaciones transcendentales, como las llama Richard Huddy (director de Relaciones con los Desarrolladores Europeos de ATI). “Lo crítico”, explica, “es echar un vistazo a ña carga de trabajo típica que incluyen los juegos actuales, y también la de los títulos que creemos que veremos el año próximo, y luego calcular cuanta carga es trabajo vectorial sencillo, cuanto es escalar básico y cuanto es escalar difícil”. Los ingenieros de Ati creían que solo el 15-20% de ella descansaban en la ultima categoría, y por ello asignaban esos trabajos a solo una de cada cinco ALU.
    nVidia, sin embargo, lo ve de forma ligeramente diferente, separando sus SFU (Special Function Units) de los procesadores Stream (SP)principales, y enparejandolas, con 16 en cada cluster. Sin embargo, como la lógica de las SFU de nVidia también funciona por interpolación de atributos, esas SFU solo funcionan a aproximadamente un cuarto de la velocidad de los SP principales. “Optimizamos el diseño de nuestros SP estándar para lograr el mayor rendimiento con las instrucciones ejecutadas mas comúnmente”, afirma Nick Starm (director de Marketing Tecnico de nVidia), “sin incluir un grupo de lógica adicional para casos especiales, como instrucciones más complejas que no necesitan ejecutarse tan frecuentemente. Esta es una razón clave de por qué tenemos unidades separadas”.
    Tambien merece la pena mencionar que nVidia y Ati tienen enfoques igualmente divergentes en la velocidad de reloj de sus ALU. El enfoque de la segunda es bastante sencillo: simplemente las empaquetan en masa y las ejecuta a la misma velocidad de reloj que el resto de la GPU. El de nVidia, sin embargo, utiliza menos SP, pero los ejecuta al doble de la velocidad del reloj de la GPU. Richard Huddy, de Ati, admite que esta opción es perfectamente valida. “Si realmente podemos duplicar la velocidad de las ALU dentro del motor, estaremos tentados a tener como mucho la mitad”. Existe el riesgo de latencia entre los dos dominios de velocidad de reloj diferente, pero no es un problema fatal, y permite a nVidia utilizar una arquitectura mas pequeña y eficiente respecto al consumo.
    Ademas, también hay que considerar la granularidad y la anchura de instrucción. Cada unidad de shader en la G80 puede procesar 32 pixeles por ciclo de reloj, contra los 64 de la R600. Sin embargo, aunque esto pueda parecer algo malo, también implica que el hardware de organización de la G80 tiene menos trabajo que hacer para encontrar y organizar juntas las instrucciones independientes para mantener una eficiencia optima. “La G80 es esencialmente una arquitectura que emite una sola instrucción”, dice Stam, “lo que la hace ser muy eficiente, sin tener en cuenta el tamaño del vector ni dependencias en el flujo del código. Para la R600, el rendimiento es una función de la habilidad del compilador para husmear en seis instrucciones independientes por ciclo, un trabajo realmente duro”. Esta puede ser la razón , entre otras, de que la 8800 GTX de gama alta de nVidia supere en rendimiento a la HD2900XT de Ati, incluso aunque esta ultima tenga dos veces y media mas unidades de shader.

    LA DIRECCIÓN

    Para dirigir a los obreros, Ati sigue utilizando un procesador de dispatch, como se ha visto en la R580. Sin embargo, en la R600, el “director de línea” tiene un trabajo mas difícil. Mientras que el procesador de dispatch de la R580 solo tenia que programar varias tareas de pixel-shader e intercambiarlas dentro y fuera para optimizar el flujo de trabajo, el procesador de dispatch de la R600 tiene que programar tres colas diferentes de trabajo de pixel, vertex y geometría por el mismo banco de ALU, utilizando su habilidad para intercambiar entre trabajo de pixel y vertex, o vertex y geometría dentro de un único ciclo de reloj. Al mismo tiempo, la G80 de nVidia utiliza una combinación de un organizador global principal y una serie de organizadores locales (uno por cluster) para realizar básicamente la misma tarea.
    La arquitectura de DirectX 10 es confusa. No solo envía instrucciones a través de una pipeline, sino que también las circula por un complejo sistema interconectado. Los datos de vertex procesados a través de la porción de vertex del setup engine, el procesador de dispatch y las ALU acabaran en el setup engine, listos para ser rasterizados y enviados a través de la porción de pixel del setup engine, para luego pasar por el procesador de dispatch y por las ALU. Sin embargo, utilizar este enfoque unificado y con tantos hilos ofrece una ventaja enorme.
    En una GPU de DirectX 9, todo funcionaba suavemente, siempre que el trabajo sobre pixeles y vertex cumpliese el propósito para el que los arquitectos habían diseñado la GPU. Si un juego que corria en una R580 realizaba seis veces mas trabajo con los motores de pixeles que con los vertex, eso quería decir que se estaban utilizando el 100% de las unidades de shader y que todo funcionaba a toda velocidad. Si, sin embargo, los motores de pixel realizaban diez veces mas trabajo que los de vertex, estos últimos no estarían haciendo nada mientras que los primeros se atascaban. Aun peor, si los motores de vertex tuvieran la misma carga de trabajo que los pixel shaders, estarían sobrecargados, mientras que los de pixel estarían hambrientos de datos.
    Esto no sucede con la arquitectura unificada. Suponiendo que el procesador de ordenes, el setup engine y el procesador de dispatch(o el setup engine y los organizadores locales-globalesen la G80) funcionen correctamente, todas las unidades deberían estar ocupadas todo el tiempo. En palabras de Richard Huddy, de Ati, “una pieza de hardware que de vez en cuando solia caer por debajo del 50% de eficiencia porque solo era una parte de la pipeline, y ni siquiera se utilizaba eficientemente al 100%” se ha convertido en una “en la que es difícil ver a cualquier parte del chip gastando ciclos de trabajo disponibles sin hacer nada”. Ahora vamos a seguir una carga de trabajo 3D típica a través de los diversos departamentos de una GPU DX10

    EL FRONT END

    La primera cosa que se encuentran los datos graficos que salen de la CPU es el “fron end” de la GPU, el bloque dedicado a organizar instrucciones y datos que llegan, para luego distribuirlos al resto de la GPU. En una GPU DX9 como la R580, los datos de vertex entrantes iban directos a ser procesados en los vertex shaders; en la R600, sin embargo, llegan al procesador de ordenes. Este comprueba que el hardware esta configurado correctamente para la tarea que tiene ante sí, que ha pasado de la CPU a la GPU por razones de ancho de banda y latencia, y luego agrupa las instrucciones de entrada en grupos apropiados para minimizar la latencia mas tarde. nVidia ha empleado unas lógica equivalente en su G80. Estos datos agrupados llegan a un setup engine global, que examina las instrucciones que llegan y las separa en tre colas, trabajo de pixel, de geometría y de vertex.

    VERTEX SETUP
    Por ahora, vamos a concentrarnos en el Vertex Setup. El procesador de ordenes toma los datos de vertex procedentes de la CPU y los pasa al ensamblador de vertex, listos para operaciones de vertex shader en las ALU. En la R600 (HD2900XT), también pasan a través del Tesselator. Acontinuación, los vertex shaders llevan a cabo su trabajo, y se quitan de en medio los datos dejándolos a un lado, donde las instrucciones del setup engine pueden utilizarlos para la siguiente etapa. Alternativamente, pueden utilizar la caché “stream out”, para que puedan ser usados por otros vertex o geometry shaders. Por ejemplo, al combinar “stream out” y un geomery shader, los datos de vertex se pueden utilizar para generar un mapa de desplazamiento y crear el relieve de una superficiem o construir sombras volumétricas totalmente en 3D.
    Una vez terminadas todas las operaciones en un conjunto de vértices en particular, el setup engine se pone a trabajar, calculando qué vértices pertenecen a qué triangulos, y cómo tienen que dibujarse ésos desde la perspectiva dada. También calculará qué triángulos tienen que rasterizarse y cuales tienen que descartarse.
    Esta parte del proceso es similar al método utilizado en una GPU de DirectX 9, pero las GPU de DX10 son más eficientes, particularmente cuando se trata de seleccionar o cortar triangulos no deseados. Por ejemplo, en cualquier escena dada, la mitad de los polígonos que se podrían dibujar estarán de espaldas (no están de cara a la cámara, con lo que no se verían si fueran renderizados). Rasterizar estos triangulos no solo es un malgasto de potencia de proceso, y por lo tanto, un problema para el rendimiento; dejarlos en la pipeline puede provocar desagradables artefactos en la imagen mas adelante. El motor setup engine de la R600 puede seleccionar un millón de triangulos con cada ciclo de reloj!!
    TEXTURIZADO
    La salida del setup engine se “rasteriza”. El setup engine transforma las primitivas em “fragmentos” de píxel, que tienen que colorearse y sombrearse. En el proceso lineal de DX9, utilizado en la R580, esto implica simplemente meter el fragmento de datos en la caché y enviar instrucciones al procesador de dispatch que controla las 48 unidades de pixel shaders. En la R600, sin embargo, significa meter los datos en la caché para que estén liston para el procesador de dispatc los utilice en las colas de pixeles. En la G80, las instrucciones van al organizador global, y luego al organizador local que pertenece al cluster de la ALU.
    Aunque los shaders unificados son una parte fundamental de la arquitectura de DX10, no son la única parte importante cuando se trata de operaciones de texturizado y sombreado de pixel; también tenemos que considerar las unidades de texturas. Casi todas las operaciones graficas 3D llevan implícito el muestreado de texturas, que se realiza en la RAM de video o del sistema principal, y luego se almacena en una o más caches de texturas en las GPU. La principal tarea de la unidad de texturas es mover datos de muestras desde las caches de texturas al pixel shader que los necesita. Filtrarlas, asegurándose de que aparecen con el angulo y nivel de borrosidad correctos según la distancia y perspectiva, es su segunda tarea. En ambos aspectos, si comparamos la R600 con la vieja R580, destacan dos cosas
    En primer lugar, mientras que las GPU s de DX9 de la vieja escuela como la R580 ya han realizado el paso de desasociar unidades de texturas de unidades de pixel especificas, compartiéndolas en una relación de tres a uno por los 48 procesadores, la R600 realiza este proceso una etapa mas adelante. Ahora las unidades de texturas son, en palabras de Richard Huddy, “sirvientes de los nucleos de shader en un sentido mucho mas abstracto”. Cualquier nucleo de shader, que realice trabajo de pixel, vertex o geometría, puede solicitar los recursos de una unidad de texturas, y el procesador de dispatch maneja la transacion. Curiosamente, las unidades de texturas en la G80 de nVidia están vinculadas con clusters específicos de las SPU, auqnue pueden ser asignadas de cualquier forma de programa de shader que funcione en ese cluster.
    En segundo lugar, las unidades de texturas de la R600 son mucho mas eficientes que las de la R580 cuando se trata de filtrar texturas; particularmente las de 16 y 32 bits en punto flotante que necesitan las técnicas de renderizado HDR de alta precisión, que demandan mas información de color y luminosidad que la que podrían proporcionar los valores enteros de 8 bits de la vieja escuela. La R600 puede manejar texturas FP16 a 16 pixeles por ciclo de reloj, y texturas FP32 a la mitad de esa velocidad. Sin embargo, la R580 solo podía filtrar esas texturas utilizando sus unidades de pixel shader, y no podría manejarlas dentro de las propias unidades de texturas.
    De forma sorprendente, mientras que los procesadores-shader en la arquitectura de la R600 han aumentado a 320 desde los 56 (píxel+vertex) de la R580, no se ha producido un aumento correspondiente en las unidades de texturas.
    Richard Huddy ofrece dos razones para esto. En primer lugar, las unidades de textura utilizan ancho de banda de forma intensiva. Cuantos más muestreos se lleven a cabo, más datos de texturas andaran por el bus interno del chip, y menos ancho de banda habrá disponible para otras tareas. Debido a esto, es mas barato añadir mas ALU que unidades de textura. En segundo lugar, en el pasado, los programadores dependían de las muestras de texturas para trabajos como la iluminación especular, arrastrando un bitmap especular desde la memoria de texturas y utilizándolo para aplicar el efecto, mientras que ahora tienden a crear los efectos utilizando computación para conseguir resultados mas precisos y eficaces.
    Echemos un vistazo a los progresos de id Software desde Doom hasta Quake 4. En el primero, todo son texturas y no hay matematicas; en el segundo, que añade mapas de iluminación, hay dos partes de texturas y una de calculo por superficie. En el momento en el que pasamos a Doom3 y Quake4, estamos hablando de cuatro o cinco cálculos de shader por textura. En los juegos futuros que utilicen los nuevos motores CryEngine2 o Unreal se espera que continúe la tendencia, especialmente cuando los desarolladores utilicen texturas procedurales y otros efectos similares. La desventaja, sin embargo, es que los títulos de última generación y actuales, por no mencionar algunos nuevos, siguen realizando grandes exigencias a las unidades de texturas. Esto proporciona a la G80 de nVidia, que tiene unidades de textura sirviendo a cada uno de sus ocho clusters de SPU, una ventaja sobre la R600 por el momento.
    EL BACK END
    En este punto del proceso, el procesador de dispatch ha entregado los trabajos a los clusteres de la ALU, que están ocupados procesando los fragmentos, tomando datos de vertex de la caché de vertex, y datos de texturas de las unidades de texturas, y realizando complejos cálculos para asegurarse de que el color de un píxel refleja las propiedades correctas de textura, iluminación y reflejos, etc. Una vez que se han ejecutado todos los shaders pertinentes en un píxel, lo resultados se vuelcan en lo que Ati denomina el “Back-end de render”.
    Los ROP (Render Output Processors, procesadores de salida de render) que realizan el trabajo destacado aquí llevan a cabo una comprobación final para asegurarse de que sólo los fragmentos visibles serán renderizados como píxeles hacia el bufer de salida. Después de eso, se aseguran de que la salida de los diversos shaders se mezclará de forma correcta, y de que se aplicarán las mezclas adicionales debidas a la iluminación. En esta etapa también se realiza el proceso tradicional de anti-aliasing antes de que el frame de imagen final se envie al buffer de frames, listo para ser mostrado.
    Antes de la llegada de DX9, los ROP estaban vinculados directamente con los procesadores de píxeles y unidades de texturas como parte de una pipeline de píxel unificada. Sin embargo, con el hardware de DX9, se ha realizado un movimiento para desemparejas los ROP de los procesadores de píxeles. Para la R580, por ejemplo, solo se necesita un ROP para manejar la salida de cada tres unidades de píxeles (16 ROP para 48 unidades de píxel).
    Como sucede con la reducción del número de unidades de texturas, la R600 lleva esta tendencia una etapa más adelante, con solo cuatro ROP, aunque cada uno puede dar salida a cuatro píxeles por ciclo de reloj. Las unidades también pueden realizar el doble de pruebas de stencil/depth por ciclo de reloj que los ROP de la R580, y por lo tanto la eficiencia del Z-Buffer y el stencil-buffer, como la de muestreo de AA se ha mejorado drásticamente. Sin embargo, todo el cálculo no se realiza dentro de los ROP, como sucede con la R580 o la G80 de nVidia, sino en los núcleos de shader. Ati está arriesgando con los desarrolladores de juegos de DX10 al pasar del AA “boxfilter” actual, en el que la GPU toma cuatro muestras y las promedia, a rutinas de shader de AA personalizadas más sofisticadas que examinan los valores de píxeles fuera de la box y los factorizan en los cálculos.
    Este enfoque tiene sentido para las aplicaciones futuras, según explica Richard Huddy: “Esto nos proporciona a veces una imagen más borrosa; pero, en la gran mayoría de casos, parece más nítida. Podemos librarnos de parte de lo que llamamos artefactos de enlace”. Y no sólo eso, sino que también abre el camino para que los programadores creen rutinas de AA personalizadas que funcionan de forma específica para los entornos que creen en sus juegos. “Llegaremos a tener situaciones en las que el anti-alising sea especifico del juego”, añade Huddy. Aún más, este Custom Filter Anti-Aliasing (CFAA) se vuelve mas importante en títulos que utilicen HDR, ya que hay valores de píxeles que tienen que mapearse cuidadosamente para crear la impresión correcta de blancos ultrabrillantes y ricas sombras más oscuras que lo que se lograría promediando cuatro muestras que pueden crear efectos horribles. nVidia tiene sus propias rutinas de filtrado personalizadas basadas en shader, CSAA (Coverage Sample Anti-Aliasing) para evitarlo. El problema es que esto no se adapta bien a las aplicaciones actuales. Las rutinas 4x AA con multisampling estándar montadas en los seis ROP en la G80 de nVidia (cada una de las cuales también puede sacar cuatro píxeles por ciclo de reloj) manejan las rutinas AA de DX9 más eficazmente, lo que es otra razón de que la R600 no haya funcionado tan bien como se esperaba en las privas de rendimiento recientes. “Creemos que nuestra arquitectura es más equilibrada, y que podemos procesar más eficazmente un rango más amplio de código de shader actual y futuro”, afirma Nick Stam, de nVidia. Como no nos gustaría que el procesamiento back-end realizado por los ROP provocase un cuello de botella, proporcionamos los recursos de ROP adecuados para llevar a cabo el frame buffer blending y el procesamiento de píxeles final, con lo que tenemos un diseño muy equilibrado”.

    FUENTE
    Código:
    Custom PC, número 28

  • #2
    Muchas gracias por la información, no sabía nada sobre el funcionamiento de las gráficas ni de DX10 xD y menuda paliza a escribir te has pegado...

    Comentario


    • #3
      Muchas, gracias de verdad,sabía ede ellas, pero con eso he aprendido aun más.

      ¿esto va en tutoriales informaticos?

      Comentario


      • #4
        No es un tutorial en si, es una explicacion, porque ela finalidad va a ser resolver dudas de la gente respecto a como funcionan o "que es mejor, esta o esta" y asi miran y comparan

        Un saludo

        Comentario


        • #5
          Ya me acordé despues de poerlo y la flojera... xDD.

          ¿Pero en hardware?
          No lo veo , lo siento.....

          Comentario


          • #6
            Esperemos que lo termine pronto Gailen.

            Saludos

            Comentario


            • #7
              Originalmente publicado por forocero.i
              Ya me acordé despues de poerlo y la flojera... xDD.

              ¿Pero en hardware?
              No lo veo , lo siento.....
              Se basa en la ordenación de las unidades de proceso respecto a DX10. Un poco lioso ponerlo.

              A ver si puedo pasar par de titulos mas cuando acabe unos deberes

              Comentario


              • #8
                Apartir de que modelo de nvidia funciona el directx 10?

                Comentario


                • #9
                  A partir de la serie 8X00 de nVidia. Y e Ati, a partir de HD2X00

                  Comentario


                  • #10
                    yo sabia muy poco ahora lo se todo

                    Comentario


                    • #11
                      una 8400 no le va?

                      Comentario


                      • #12
                        Si es la GS si le vale...

                        Comentario


                        • #13
                          No esta termiando aun, a ver si para el fin de semana saco tiempo y lo termino

                          Un salduo

                          Comentario


                          • #14
                            instalar hadwer de tarjeta grafica GA ,despues de formatear

                            una rpegunta ese tutorial bueno ese psot k as peusto aber es muy bueno xk me ha exo entender kosas k no savia pero no me ayuda ala hora de poner bien al tarjeta grafica VGA yo tengo la tarjeta pero no peudo jguar aningun jeugo depeus de k yo formateara el ordena ns ese psot es bueno pero no ayuda a poner bien al tarjeta (configurarla)

                            no crees¿?


                            repodne plis es k encesito jguar jajaj tengo 14 no soi un informatiko ni nada de esto pero me gustaria k me ayuaras.........

                            Comentario


                            • #15
                              una rpegunta ese tutorial bueno ese psot k as peusto aber es muy bueno xk me ha exo entender kosas k no savia pero no me ayuda ala hora de poner bien al tarjeta grafica VGA yo tengo la tarjeta pero no peudo jguar aningun jeugo depeus de k yo formateara el ordena ns ese psot es bueno pero no ayuda a poner bien al tarjeta (configurarla)

                              no crees¿?


                              repodne plis es k encesito jguar jajaj tengo 14 no soi un informatiko ni nada de esto pero me gustaria k me ayuaras.........

                              Comentario

                              Trabajando...
                              X