Futuremark responde a las acusaciones de parcialidad en la nueva prueba DirectX 12 Time Spy

TimeSpyFeature

La semana pasada, Futuremark lanzó Time Spy, un nuevo DirectX 12 benchmark que aprovecha al máximo las características y capacidades de DX12, incluida la computación asincrónica. Si bien el lanzamiento de un nuevo punto de referencia suele tener un interés modesto, ha habido mucha confusión, incertidumbre y dudas sobre los resultados del punto de referencia de Time Spy y lo que significan esos resultados. Desde entonces, Futuremark ha publicado una guía actualizada y ampliada sobre cómo funciona el punto de referencia y para qué está diseñado.

Gran parte de la confusión sobre este tema está relacionada con lo que prueba Time Spy y cómo implementa el soporte para cómputo asincrónico en DirectX 12. A grafico de los resultados de las pruebas de PC Perspective de la semana pasada ilustrarán la pregunta:



timespy-3

Datos por Perspectiva de PC



Estos resultados muestran el rendimiento en Time Spy en la configuración predeterminada de la prueba comparativa con el cálculo asíncrono habilitado frente a deshabilitado. Las GPU de AMD obtienen una cantidad significativa de rendimiento, con el RX 480 aumentando su puntaje en un 8.5%, mientras que el R9 Nano y Fury X obtienen un 11.1% y 12.9% respectivamente. Las tarjetas Maxwell de Nvidia, por el contrario, son planas.

Pascal, sin embargo, hace ganar algo de rendimiento, con la GTX 1070 ganando un 5,4% y la GTX 1080 ganando un 6,8%. Esto es contrario a lo que hemos visto en la mayoría de los benchmarks de DX12. hasta la fecha , en el que habilitar la computación asincrónica en tarjetas Nvidia condujo a una pequeña disminución del rendimiento o no tuvo ningún impacto en el rendimiento.



Revisando el cálculo asincrónico

El debate sobre si Time Spy es un punto de referencia válido, y las preguntas sobre su implementación de cómputo asincrónico, hablan de una cantidad significativa de confusión en la comunidad de usuarios sobre lo que cálculo asincrónico es, cómo funciona y cómo puede o debe usarse en DirectX 12.

Si bien el soporte informático asincrónico es un componente de DirectX 12, los detalles de cómo implementar ese soporte se dejaron en manos de AMD, Intel y Nvidia. AMD y Nvidia implementaron esta capacidad de manera muy diferente y con resultados muy diferentes. Ahora sabemos que Nvidia nunca ha implementado un controlador de cómputo asíncrono para las GPU Maxwell v2 (GM200, GM204 y GM206), lo que significa que nuestros intentos de caracterizar y examinar el impacto en el rendimiento de ejecutar cargas de trabajo de cómputo asíncronas en Maxwell en Ashes of the Singularity no lo hicieron. no midas lo que pensamos ellos estaban midiendo . El consenso actual es que es poco probable que Nvidia habilite el cómputo asincrónico en Maxwell debido a la dificultad de implementar la función de una manera que mejore el rendimiento.

Si bien es cierto que Nvidia podría haber sido mucho más claro acerca de la capacidad de Maxwell para realizar cargas de trabajo de cómputo asincrónico y los beneficios (o la falta de ellos) de hacerlo, algunos en la comunidad de usuarios se han centrado en el cómputo asincrónico como si fuera el único elemento que define característica de la API DX12. Este no es el caso.



La razón por la que la computación asincrónica se ha convertido en una característica tan destacada de DirectX 12 es porque su adopción tiende a mejorar significativamente el rendimiento en hardware AMD. Hasta la fecha, GCN de AMD ha obtenido un rendimiento sustancialmente mayor con el cambio a DirectX 12 que Nvidia, aunque parte de esta ganancia refleja el estado relativo de optimización de controladores entre las dos empresas. Históricamente, Nvidia ha tenido más dinero para gastar en optimización de controladores y relaciones con los desarrolladores, incluso si algunos de sus programas, como GameWorks , han sido controvertidos. La computación asincrónica también mejora el rendimiento en hardware AMD porque expone una funcionalidad que antes no se aprovechaba en DirectX 11.

Entonces, ¿dónde encaja Pascal en todo esto?

Pascal agrega soporte para la preferencia detallada y el equilibrio dinámico de carga, dos características críticas de las que carecía Maxwell. Uno de los límites de la implementación de cómputo asincrónico de Maxwell es que la GPU tenía que programar sus cargas de trabajo de cómputo y gráficos antes de la ejecución y no podía cambiar su estrategia a mitad de camino. Esto hizo que fuera comparativamente probable que habilitar el cómputo asíncrono en un chip Maxwell v2 daría como resultado un rendimiento deficiente debido a una asignación de recursos incorrecta.

Maxwell está arriba, Pascal debajo.

Maxwell está arriba, Pascal debajo.

El equilibrio de carga dinámico de Pascal permite que la GPU cambie rápidamente los recursos que dedica a la computación y los gráficos según lo que suceda en el juego. Esta función no garantiza automáticamente que Pascal se beneficie de la computación asincrónica, pero soluciona un problema importante con la última generación de Nvidia. La otra nueva capacidad de Pascal, la preferencia detallada, permite que la GPU cambie rápidamente entre cargas de trabajo a nivel de píxel, en lugar del límite de llamadas de dibujo de grano grueso de Maxwell v2. Anandtech acaba de publicado una mirada más profunda a ambos temas si desea información adicional.

Los entusiastas, sin duda, se apresurarán a señalar que Pascal, a pesar de estos cambios, todavía no puede ejecutar una carga de trabajo informática asincrónica de la forma en que AMD puede hacerlo, y tienen razón. Lo que se pierde es el hecho de que la arquitectura de Pascal no se beneficiaría de ejecutar cargas de trabajo de la misma manera que AMD, porque no está diseñado para hacerlo. La otra cara de la moneda es que las cargas de trabajo optimizadas para Pascal probablemente tampoco funcionarían tan bien en hardware AMD. Futuremark creó un punto de referencia diseñado para funcionar bien en ambas tarjetas sin favorecer a ningún proveedor.

Este enfoque debería resultar similar a lo que veremos en títulos futuros, dado que diferentes aplicaciones pueden utilizar y utilizarán la computación asincrónica de distintas formas y en diversos grados. Las GPU dentro de la misma familia también responden de manera diferente a la computación asincrónica; el RX 480 obtiene un 8.5% en Time Spy mientras que el Fury X gana un 12.9%. ¿Eso significa que Time Spy está predispuesto contra el RX 480 solo porque el Fury X recibe un impulso mucho mayor de la función? Por supuesto no.

Espía del tiempo de Futuremark

Las preguntas relacionadas con Time Spy se pueden resumir de la siguiente manera:

  • ¿Por qué la arquitectura Pascal de Nvidia gana rendimiento en Time Spy cuando no muestra ninguna ganancia de rendimiento del cómputo asíncrono en otros puntos de referencia?
  • ¿Por qué Futuremark no implementa rutas de código optimizadas y específicas del proveedor para AMD y Nvidia? ¿No es este un requisito funcional de DX12?

Según Futuremark, Time Spy utiliza un nuevo motor diseñado específicamente para DirectX 12. El punto de referencia se diseñó durante un período de dos años de colaboración activa con Intel, AMD y Nvidia, todos los cuales han tenido acceso al código fuente y han contribuido con las mejores prácticas. y comprensión técnica. Además, todos los socios de Futuremark han firmado la publicación del índice de referencia en su forma actual.

Me gustaría señalar que esta explicación pública se alinea con lo que hemos escuchado en privado. Ni los equipos de relaciones públicas de AMD ni de Nvidia son conocidos por su reticencia cuando se trata de atacar puntos de referencia que perciben como defectuosos o injustos, y ninguna de las empresas tiene nada negativo que decir sobre Time Spy.

Futuremark continúa diciendo que ha considerado implementar rutas de código específicas del proveedor, pero que sus socios invariablemente están en contra de la práctica. Escribe:

En muchos casos, una ruta de optimización agresiva también requeriría alterar el trabajo que se está realizando, lo que significa que la prueba ya no proporcionaría un punto de referencia común. Y con rutas separadas para cada arquitectura, no solo los resultados no serían comparables, sino que las rutas quedarían obsoletas con cada lanzamiento de una nueva arquitectura.

Los puntos de referencia de 3DMark utilizan una ruta que está muy optimizada para todo el hardware. Esta ruta se desarrolla trabajando con todos los proveedores para garantizar que nuestro motor funcione de la manera más eficiente posible en todo el hardware disponible. Sin el apoyo y la participación de los proveedores, esto no sería posible, pero tenemos la suerte de contar con socios de desarrollo activos y dedicados.
En última instancia, 3DMark tiene como objetivo predecir el rendimiento de los juegos en general. Para lograr esto, necesita poder predecir juegos que están altamente optimizados para un proveedor, ambos proveedores, y juegos que son bastante agnósticos. 3DMark no pretende ser una medida del rendimiento máximo teórico absoluto del hardware.

Esta declaración causó cierta controversia en la comunidad de usuarios porque una presentación conjunta AMD-Nvidia en GDC 2016 afirmó de manera destacada que no tenía sentido implementar DirectX 12 a menos que planeara implementar también rutas de código específicas de IHV.

MotorConsideraciones

Entonces, ¿es esto una prueba de falsedad, prejuicio o engaño? No. De hecho, desde mi perspectiva como revisor, es todo lo contrario.

Las rutas optimizadas por el proveedor son riesgosas

En 2008, cuando trabajaba para Ars Technica, escribió una reseña de la Via Nano. Durante el curso de la prueba de esa CPU, decidí usar una utilidad provista por VIA para cambiar la cadena de CPUID que identifica el microprocesador. La mayoría de los puntajes de las pruebas no cambiaron, pero el puntaje del subsistema de memoria cambió drásticamente.

PCM2K5-2

Las etiquetas Nano (AMD) y Nano (Intel) significan que el chip se identificó como fabricado por AMD e Intel, respectivamente. La ruta del código de Intel es un 47% más rápida que la ruta predeterminada.

Cambiar el CPUID mejoró el rendimiento de Nano en un 47% porque se había implementado una ruta de código específica del proveedor y se le habían vinculado ciertas optimizaciones. Futuremark siempre insistió en que esto se debió a un accidente y no a un intento deliberado de sesgar los resultados de las pruebas a favor de Intel. Cuando Futuremark anunció PCMark 8, le pregunté a la compañía qué había sucedido después de la controversia de PCMark05. Futuremark me informó que había revisado sus programas de desarrollo y sus estrategias de optimización para evitar rutas de código optimizadas a mano específicas del proveedor debido a las consecuencias que rodean el problema PCMark05.

Sería extremadamente hipócrita atacar a Futuremark por usar optimizaciones específicas de Intel en una prueba, solo para dar la vuelta y atacarlo por no implementar optimizaciones específicas de AMD o NV en una prueba diferente. Si tengo que elegir entre una prueba justa general y completa que no incluye optimizaciones específicas del proveedor para ninguna arquitectura, y un punto de referencia que ha sido optimizado en un grado desconocido por varios proveedores, tomaré el primero cada tiempo, incluso si eso significa perder la oportunidad de ver el mejor de los casos para cualquier GPU determinada.

Un programa como Time Spy, Fire Strike o 3DMark 11 está diseñado para servir como un vehículo general y representativo para medir el rendimiento en una serie determinada de pruebas. La base de clientes de Futuremark no se limita a jugadores individuales. También vende licencias de sitio a otras empresas que desean medir el rendimiento general de su hardware en un punto de referencia estandarizado. Las versiones de 3DMark también tienden a tener una vida útil más larga que los puntos de referencia de juegos. La mayoría de los revisores actualizan sus pruebas de juegos en un ciclo de 1 a 2 años, mientras que las versiones de 3DMark suelen durar tres o más. Escribir y actualizar un punto de referencia que funcione decentemente bien en múltiples arquitecturas sin estar específicamente optimizado para un solo objetivo puede evitar que una empresa muestre una característica específica. Pero también proporciona un marco en el que pueden confiar varias empresas para calificar sus propios diseños.

Conclusiones

Futuremark’s declaración formal y la guía técnica actualizada contiene una gran cantidad de información adicional sobre cómo se ejecuta el cómputo asincrónico en las GPU Maxwell, Pascal y AMD. Nuevamente, simplemente no hay evidencia de que esta prueba esté sesgada de manera injusta o inusual hacia algún proveedor.

Lo único que muestra este punto de referencia es que Pascal puede ver una mejora modesta con el cómputo asíncrono habilitado. Dado el estado aún temprano de DirectX 12, la cantidad limitada de juegos que lo utilizan y el hecho de que solo dos motores que conocemos se han escrito para API de baja sobrecarga desde cero (el motor Nitrous de Oxide y el propio Time Spy ), concluir que este índice de referencia está sesgado simplemente porque muestra una pequeña ganancia para Pascal es extremadamente prematuro.

Incluso 12 meses después del lanzamiento, la compatibilidad con DirectX 12 en los títulos de envío sigue siendo limitada, y nuestra capacidad para caracterizar cómo se verá el rendimiento de DirectX 12 en toda la industria también está limitada. Con Pascal recién lanzado y la llegada de Vega de AMD a finales de este año, habrá una gran oportunidad de ver cómo evoluciona la API.

Copyright © Todos Los Derechos Reservados | 2007es.com