Bienvenido a Agalisa Informática
  Eres un/a usuario/a Anónimo/a Lunes, 9/12/2019  
Servicios Agalisa
· Tienda On-Line
· Lista Precios
· Quienes Somos
· Acreditaciones
· Mapa Situación
· Consulta E-Mail
· Panda ActiveScan
·

Producto Destacado
En este momento no existe contenido para este bloque.

Zona Activa
· Página Inicial
· Archivo de Noticias
· Buscar
· Descargas
· Encuestas
· Enlaces
· Enviar Noticia
· FAQ
· Foros
· Mi Cuenta
· Recomiéndanos
· Sugerencias
· Temas
· Top 10
· Versión PDA

Buscar



Titulares Aleatorios

Msi
[ Msi ]

·MSI lanza la primera placa madre con el chipset nForce4 para Athlon 64
·MSI reafirma la fiabilidad y durabilidad de sus placas madre
·MSI lanza una unidad combo CD-RW/DVD con interfaz SATA
·MSI lanza una placa basada en el KT880 de VIA
·Novedades MSI 4/10/03
·MSI fabricará tarjetas gráficas con sistema de refrigeración pasivo
·Novedades MSI 7/7/03
·Novedades MSI 23/6/03
·Nuevas Placas 845PE-Max3 y 746FX-Ultra

Efemérides
Tal día como hoy...

Producto de Oferta
En este momento no existe contenido para este bloque.

¿Qué fue mal con el NV3x?
Enviado el 04/05/04 a las 02:00 por noticias

nVidia

Tras su aparición en el mercado, ha habido una gran cantidad de comentarios sobre la nueva GPU NV40 de NVIDIA, conocida como GeForce 6800. Este chip ofrece, sin duda, un rendimiento que está a años-luz del de los anteriores NV3x. La gran pregunta es ¿por qué? Os ofrecemos la traducción de un excelente artículo de Anandtech.

La primera respuesta que surge es: NV3x es una arquitectura diferente. ¿Pero cuan diferente es de su hermano mayor? ¿Cuales son las razones por las que no obtenemos el rendimiento que desearíamos del NV3x? ¿Qué hace que NV40 sea tan superior a NV3x?

Estas son las preguntas que queremos responder, para lo que echaremos un vistazo en profundidad a cada una de las dos arquitecturas para poder entender qué fue lo que provocó los 12 meses más oscuros de NVIDIA.

Rendimiento de la cadena de procesado de pixels

El objetivo del hardware gráfico es determinar el color de cada uno de los pixels de la pantalla, para lo que es preciso realizar una gran cantidad de operaciones matemáticas. A medida que la demanda de mejores gráficos aumenta, se hace necesario realizar más y más trabajo a nivel de hardware en vez de en software sobre la CPU. Todo el trabajo que se ha de hacer a nivel de pixels individuales se agrupa en lo que se llama la cadena de procesado de pixels (pixel pipeline en inglés). Trazando un paralelismo con el mundo real, se puede decir que es la cadena de montaje de cada pixel.

Una de las características más ventajosas de los gráficos por computadora es que el determinar el color de un pixel se puede hacer de forma totalmente independiente a la de cualquier otro pixel, por lo que éstos son infinitamente paralelizables. Si dispusiésemos de suficiente potencia de cálculo, podríamos calcular a la vez todos los pixels de la pantalla. Aunque este extremo no es una opción actualmente (aunque quien sabe, quizás en una década o dos...), sí es cierto que las actuales tarjetas gráficas son capaces de procesar varios pixels a la vez. Precisamente al número de pixels que se pueden trazar en paralelo se le conoce como el "ancho" de la arquitectura.

En el interior del NV3x se encuentra una cadena de procesado de pixels de 4x2 (aunque hubo algo de confusión respecto a ésto; volveremos sobre ello más tarde). Esto significa que las tarjetas NV3x pueden pintar a la vez cuatro pixels con hasta dos texturas en cada uno ("texturizar" los pixels permite añadir texturas a una superficie, esto es, el color de cada pixel de una superficie se toma de una imagen o textura. En una arquitectura como la NV3x, se pueden superponer dos texturas en un solo paso por la cadena). Por su parte, la arquitectura R300 de ATI es 8x1, lo que significa que se pueden trazar hasta 8 pixels simultáneamente pero con una única textura cada uno. Desgraciadamente, en entornos que utilicen una única textura, NVIDIA sólo puede trazar cuatro pixels por ciclo de reloj como máximo.

La arquitectura NV3x, tal y como se ve a nivel software, está formada por cuatro pixel shaders, cada uno con dos unidades de textura. La tasa de pintado de texturas es el doble que el máximo número de pixels por segundo de la tarjeta, lo que significa que se desperdicia una gran cantidad de potencia de cálculo cuando se trabaja con una única textura por superficie.

La decisión que NVIDIA tomó para los NV3x tiene sentido si se considera que muchos efectos realizables en el hardware gráfico de funciones fijas y en los primeros programables (en la época de DirectX7 y DirectX8) estaban orientados hacia la creación y aplicación de varias texturas sobre una misma superficie (esto se denomina multitexturado, por razones óbvias). La implementación de light maps (luces), envornment maps y cube maps (reflexiones) y bump maps (abolladuras y otras deformaciones pequeñas de superficie), junto con el tradicional mapa de color, son ejemplos en los que los desarrolladores pueden explotar el multitexturado para aumentar el realismo de sus escenarios.

Sin embargo, muchos efectos de multitexturado se pueden hacer mediante programas que realicen el vertex y pixel shader. Estos suelen ofrecer un mayor control a los desarrolladores y artistas, y eliminan al mismo tiempo la necesidad del multitexturado. Aunque esto es muy bueno para desarrolladores, artistas, usuarios y ATI, no lo es para la arquitectura NV3x, pues su rendimiento en la práctica es mucho menor del máximo teórico.

Al cambiar desde la arquitectura NV3x a la NV40, NVIDIA cambió a un enfoque de textura única, además de aumentar el rendimiento interno de los shaders de vertex y pixels. Esto se ha conseguido, básicamente, cuadruplicando el número de cadenas de procesado (pipelines), pero únicamente duplicando la capacidad de la GPU de trabajar con texturas. El resultado es una arquitectura 16x1. En el NV40, las tasas máximas de pixel y texturas son las mismas, lo que ofrece un uso más equilibrado del hardware en condiciones reales. Cuando se trabaja con texturas múltiples, el NV40 puede trabajar en un modo 8x2 en donde la mitad de las cadenas se emplean para cada textura.

Además del color y la textura, las tarjetas 3D han de enfrentarse también con la tercera dimensión: la profundidad de la pantalla. Este valor indica cuan cerca o lejos del observador se encuentra un pixel de una superficie. Si en cualquier punto de la cadena de procesado se determina que dicho pixel está "detras" de cualquier otra cosa, puede ser eliminado (a esto se le denomina "occlusion culling"). Una de las mejores formas de mejorar el rendimiento en los gráficos 3D es reducir el trabajo, y la clave para ello es saber qué no hay que hacer. Calcular y actualizar los valores de la coordenada z es esencial para reducir el trabajo. La arquitectura de NVIDIA puede manejar el stenciling (ocultamiento) con el mismo hardware que maneja la coordenada z. El ocultamiento es difícil de explicar, pero es fácil si se le echa un vistazo a su aplicación más común: el cálculo de sombras. Las sombras se pueden implementar mediante los valores de z vistos desde la fuente de luz. Cualquier cosa que se encuentre detrás de un objeto desde el punto de vista de la fuente de luz estará en sombra, y puede obviarse a la hora de trazar la escena desde el punto de vista del observador (quien verá una sombra de dicha luz porque dichos pixels estarán apagados). El conseguir "buenas" sombras es mucho más complejo que esto, pero esta es la idea base.

Tanto en NV3x como en NV40, el color y la coordenada z de un pixel se pueden calcular a la vez. Además, en vez de colorear el pixel, se puede realizar una operación z o una de ocultamiento en la unidad de color. Esto permite al NV3x realizar 8 operaciones z u ocultamiento por ciclo de reloj, y al NV40 hasta 32. NVIDIA ha comenzado a denominar a esto "8x0" y "32x0" respectivamente, pues no se pintan nuevos pixels. Este modo es muy útil si se realiza primero una pasada sólo para calcular el valor z, o si se usan sombras por ocultación (stencil shadows), como en el caso de Doom 3.

Por supuesto, hay muchas más razones que influyen en el rendimiento que el número de cadenas de procesado.

Arrojando luz sobre la iluminación

Explicar donde encajan los shaders (encargados de los efectos de iluminación) precisa una pequeña explicación de qué ocurre al trazar gráficos 3D. Al movernos desde el software hasta la pantalla a través de la cadena de procesado, hay varias cosas que cambian, generalmente de gran escala a pequeña escala. En la parte superior se trabaja con objetos y geometría. La posición y dirección de observación de la escena, junto con los datos de posición 3D son trasladados, rotados y manipulados como haga falta al principio. Si tan sólo se va a representar una imagen en modelo de alambre y en dos colores, acabaríamos aquí. Pero si seguimos, las operaciones a realizar se vuelven más y más pequeñas. Comenzamos a ver no ya la geometría global, sino las normales de cada superficie para determinar como debe iluminarse. Seguimos con las texturas de cada superficie, y más abajo pasamos a ver los pixels individuales a pintar en la pantalla, donde el color que tome dependerá de lo que haya ocurrido en las etapas anteriores. Esta es una visión global simplificada, pero en general, a medida que bajamos en la cadena, más pequeña se hace la escala a la que trabajamos.

Un efecto colateral de ésto es que, a medida que nos desplazamos hacia abajo, aumenta el tamaño de los datos con los que trabajamos. Por ejemplo, una escena normal tiene unos cuantos objetos, que estarán hechos cada uno con unos cuantos polígonos con 3 o más vértices cada uno. Cuando una escena es trazada, pasamos de una escena con algunos objetos a muchos más polígonos, muchos más vértices, y millones de pixels. Esto implica que, de cara a la eficiencia, es mejor realizar un proceso en la primera etapa de la cadena que lo permita.

El hardware de los shaders es una versión fractal del sistema completo. Primero trabajamos sobre los datos de los vertex, los cuales son manipulados y enviados a las cadenas de pixels (pixel pipes), en donde los pixel shaders trabajan pixel a pixel.

Dentro de los shaders podemos realizar una gran cantidad de operaciones en vértices y pixels, y cuanto más largo sea el programa del shader, más impacto tendrá en el rendimiento. Otra forma de verlo es que un programa de shader más grande precisa un hardware de shader más eficiente para trabajar a buena velocidad.

Decir "shaders más eficientes" no permite mostrar una imagen clara del problema. Las especificaciones de shaders están comenzando a necesitar que algunas partes de la GPU se parezcan cada vez más a una CPU. Con esta evolución llegan todos los problemas y dificultades asociadas con el diseño de una CPU potente. Y el aspecto más interesante del diseño de CPUs nos permitirá entender por qué el NV3x no fue tan bueno como debería haber sido: planificación de instrucciones.

La planificación (consistente en decidir el orden de ejecución más adecuado para una serie de instrucciones) suele verse como una cuestión de diseño de compiladores, pero hay también una gran cantidad de consideraciones a tener en cuenta desde el lado del hardware. Las principales que veremos y que afectan al NV3x son: disponibilidad de unidades funcionales y presión en los registros.

Cada cadena o pipeline tiene un puñado de unidades en su interior, capaces de realizar una tarea en un tiempo determinado. La cadena del NV3x es capaz de trabajar con una textura y de realizar una operación matemática a la vez, por lo que si se quiere mantener la cadena trabajando a su máxima velocidad, los desarrolladores han de mantener ambas unidades trabajando a la vez. Si las instrucciones de un programa de shader no están ordenadas de manera que las operaciones matemáticas y de texturas se encuentren intercaladas, la arquitectura de NVIDIA trabajará a la mitad de velocidad del que podría haber realizado en un caso ideal. El compilador hace lo que puede para mejorar el rendimiento, cogiendo un programa y reordenándolo de forma que las operaciones de texturas y las matemáticas se encuentren intercaladas, pero manteniendo la misma salida. Esto es un problema difícil de resolver, pero es también la clave del rendimiento del NV3x. El activar el compilador cuando salieron los drivers de la serie 50 fue lo que permitió que, en algunos casos, se consiguiese un aumento de hasta el 25% "por la cara". This is the front end of an NV3x pixel shader pipe.

El siguiente problema es la presión en los registros. Si no se tiene suficiente espacio para almacenar datos temporales en los registros locales, se pierde tiempo en enviarlos a zonas de memoria. La analogía tradicional en ingeniería de computadoras cuando se habla de la gestión de los registros es el Tetris. No es exactamente lo mismo, pero puede ser igual de difícil rellenar de forma óptima el espacio de registros como lo puede ser rellenar de forma óptima una línea del Tetris sin saber qué pieza viene después. Esto se vuelve aún más difícil cuando hay menos espacio para hacer las cosas (basta imaginar un Tetris con la pantalla más estrecha de lo que ya es).

Esta situación es indeseable, pues nuestra intención es realizar un trabajo, no perder tiempo enviando datos de un lado para otro como si fuese una patata caliente. El compilador vuelve una vez más en nuestra ayuda, organizando el uso de los registros de la mejor forma posible. Sin embargo, si el hardware no está correctamente adaptado al tipo de programas que se van a ejecutar en él, no habrá compilador capaz de resolver todos los problemas.

La forma en que NVIDIA ha resuelto estos problemas en el NV40 ha sido el rediseño de sus cadenas de shaders, añadiendo una unidad matemática extra a todas las cadenas de pixels (los shaders pueden ejecutar ahora dos instrucciones matemáticas a la vez, o una instrucción matemática y otra de texturas), y aumentar el número de registros disponibles para programas de shader. This is the front end of an NV40 pixel shader pipe.

Las dos unidades matemáticas de cada etapa del NV40 pueden ser usadas a la vez cuando no hay una operación de texturas en marcha, lo que permite a los programas de shaders el uso intensivo de operaciones matemáticas sin caer en problemas de planificación; por su parte, los nuevos registros añaden más espacio para facilitar el empaquetado de los datos, lo que alivia los otros problemas encontrados en NV3x.

Así pues, al cuadruplicar el número de cadenas de pixels y añadir la segunda unidad matemática, el NV40 puede multiplicar por ocho el rendimiento del NV3x bajo las condiciones adecuadas. Este impresionante aumento era algo absolutamente necesario, pues el rendimiento del NV3x estaba muy por debajo del óptimo. El rendimiento de los vertex shaders también ha sido duplicado gracias a todo ésto.

Fuente: AnandTech (en inglés).


 
Enlaces Relacionados
· Más Acerca de nVidia
· Noticias de noticias


Noticia más leída sobre nVidia:
GeForce 6600 de NVIDIA


Valorar Artículo
Puntuación Media: 5
votos: 1


Por favor pierde un segundo y valora esta noticia:

Excelente
Muy Bueno
Bueno
Regular
Malo



Opciones

 Versión Imprimible  Versión Imprimible

 Enviar a un Amigo  Enviar a un Amigo


Puntos
Los comentarios son propiedad de quien los envió. No somos responsables por su contenido.

No se permiten comentarios Anónimos, Regístrese por favor


Todos los derechos reservados. Los comentarios anónimos o de los usuarios registrados son propiedad de sus autores. Agalisa no se identifica de ninguna manera con ellos salvo expresamente publicado por nuestra parte. Agalisa se reserva el derecho de modificar o eliminar aquella información propia o de terceros que considere incorrecta, incompleta u ofensiva.
© Copyright Agalisa 2002 - Consulte nuestra política de privacidad.
Portal basado en la tecnología de PHP-Nuke.