Una mirada más cercana a DirectX 12... O, mejor dicho, a Direct3D 12 En la Game Developers Conference de este año, Microsoft retiró el telón de Direct3D 12, la primera gran actualización de sus APIs gráficas desde 2009. La compañía ha anunciado algunos cambios bastante grandes, incluyendo el apoyo a un nivel más bajo de abstracción y la compatibilidad con no sólo de Windows, sino también a Windows Phone y Xbox Uno. Esta será la primera versión de Direct3D para unificar la programación de gráficos en todas las plataformas de juego de Microsoft. También puede ser la primera versión de Direct3D para ganarse importantes mejoras de rendimiento de hardware actual.
Ya cubrí algunos de esos acontecimientos en un par de mensajes de noticias durante el frenesí GDC. Ahora que estoy de vuelta en casa con todas mis notas de varias sesiones y reuniones con Microsoft y los vendedores de la GPU, puedo ir a un poco más de detalle. En este artículo, voy a tratar de explorar el inicio de Direct3D 12, las principales formas en que se diferencia de Direct3D 11, y lo que piensan que AMD y Nvidia respecto.
En primer lugar, sin embargo, vamos a arreglar algo. Nosotros y otros hemos referido en ocasiones a la nueva API de Microsoft como DirectX 12, pero lo que se estrenó en la GDC era técnicamente Direct3D 12, el componente de gráficos de DirectX 12. Como Matt arena de Microsoft , escribió en el blog oficial de DirectX, DirectX 12 también tendrá en cuenta "otras tecnologías" que "puede ser visto de antemano en una fecha posterior", incluyendo "herramientas de vanguardia para los desarrolladores." Eso es probablemente por qué no hemos oído nada acerca de, por ejemplo, la próxima versión de DirectCompute. La noticia hasta ahora se ha centrado exclusivamente en Direct3D.
Ahora que eso está todo aclarado, vamos a echar un vistazo más de cerca a Microsoft de nuevo gráficos API-comenzando con un poco de historia.
El inicio de Direct3D 12Dada la forma en que Microsoft ha presentado Direct3D 12, es difícil no establecer paralelismos con la API Manto de AMD . Manto fue presentado en septiembre pasado, y al igual que D3D12, proporciona un menor nivel de abstracción que permite a los desarrolladores a escribir código más cerca del metal. El resultado, al menos en teoría, es una menor carga de la CPU y de mejor rendimiento, los mismos beneficios generales Microsoft promete para D3D12.
La pregunta, entonces, casi se pregunta. Hizo trabajo de AMD en Manto motivar a Microsoft para introducir una API de gráficos de bajo nivel?
Cuando hablé con la gente de AMD unas pocas horas después de la D3D12 revelan, tengo una fuerte sensación de que ese no era el caso y que era desarrolladores, no de AMD, que había encabezado el impulso a un nivel inferior de gráficos API en Windows . De hecho, en la keynote, Gerente de desarrollo de Microsoft para los gráficos, Anuj Gosalia, no hizo mención de Mantle. Afirmó que "los ingenieros de Microsoft y los fabricantes de GPU han estado trabajando en esto durante algún tiempo", y agregó que D3D12 fue "diseñado en estrecha colaboración con los desarrolladores de juegos."
Luego hablé con Ritche Corpus, AMD Alianzas de software y director de desarrollo Ofertas. Corpus me dijo que AMD dio a conocer su trabajo en Manto con Microsoft "desde el primer día", y que partes de Direct3D 12 son "muy similares" a API de AMD. Le pregunté si el desarrollo de D3D12 había comenzado antes de Manto de. Respuesta Corpus ': "No es que lo sabemos." Corpus explicó que, cuando AMD estaba desarrollando Mantle, no recibió ninguna respuesta de los desarrolladores de juegos que sugieren AMD estaba perdiendo su tiempo, porque un proyecto similar está en marcha en Microsoft. Recordé que, en el evento APU13 de AMD en noviembre de 2013, de EA DICE Johan Andersson expresó el deseo de utilizar Mantle "en todas partes y en todo." Esas son quizás no las palabras que habría utilizado si hubiera sabido D3D12 fue a la vuelta de la esquina.
El día después de la apertura D3D12, tengo en el teléfono con Tony Tamasi, vicepresidente senior de Nvidia de Contenido y Tecnología. Tamasi pintó un cuadro bastante diferente de Corpus. Me dijo que había estado en D3D12 en las obras de "más de tres años" (más de manto) y que "todo el mundo", había participado en su desarrollo. Según ha señalado, la gente de AMD, Nvidia, Intel, Qualcomm e incluso estaban en el escenario en el D3D12 revelan apertura. Logos Esas cuatro empresas también son un lugar destacado en la página de destino actual para el blog oficial de DirectX:
Tamasi continuó señalando que, puesto que los ciclos de desarrollo para el nuevo tramo GPUs "muchos años", que "no hay manera posible" Microsoft podría haber abofeteado juntos una nueva API dentro de los seis meses del debut público de Mantle.
Visto desde ese ángulo, parece bastante inverosímil que Microsoft podría haber surgido una nueva API de gráficos en un gran proveedor de la GPU sin darles año para preparar-o, para el caso, solicitando su entrada a lo largo del proceso de desarrollo. AMD es apenas un actor en el mercado de GPU, y sus poderes de silicio propia consola Xbox Uno de Microsoft, que será una de las plataformas de soporte D3D12 próximo año. No estoy seguro de lo que Microsoft se beneficiaría al mantener AMD fuera de onda.
Creo que es muy posible que AMD ha sabido sobre D3D12 desde el principio, que siguió adelante con Manto de todos modos con el fin de lograr una ventaja temporal sobre la competencia, y que ahora está tratando de embellecer su parte en la creación de D3D12. Es igualmente posible AMD era del todo sincero con nosotros, y que Nvidia está simplemente tratando de restar importancia a la magnitud de la influencia de su competidor.
En cualquier caso, ya que estamos a punto de ver, D3D12 comparte de hecho algunas similitudes notables con Mantle. Más importante aún, ofrece algo a los desarrolladores parecen haber querido desde hace tiempo: un multi-fabricante de Windows API de gráficos que ofrece un nivel de tipo consola de abstracción. Cualquiera que sea parte de AMD juega, parece desarrolladores y jugadores por igual pueden beneficiarse.
Direct3D 12 en el hardware existente Menor nivel de abstracción de Direct3D 12 toma la forma de un nuevo modelo de programación, y que el modelo de programación contará con el apoyo de una amplia franja de hardware actual. AMD se ha comprometido el apoyo de todos sus actuales ofertas sobre la base de la arquitectura Graphics Core siguiente, mientras que Nvidia hizo lo mismo con todas sus fichas DirectX 11 de clase (que abarcan el Fermi, Kepler y arquitecturas de Maxwell). Intel, por su parte, se comprometió a apoyar a los gráficos integrados en sus procesadores Haswell existentes (también conocido como cuarta generación Core).
Más allá de la PC, el nuevo modelo de programación de Direct3D 12 también será explotable en la consola Xbox Uno y en teléfonos Windows Phone. Microsoft aún no ha dicho que las versiones de Windows en el escritorio apoyarán Direct3D 12, pero cayó algunas pistas. Durante el Q & A tras la keynote revelar, de Microsoft Gosalia descartado el soporte de Windows XP, pero se negó a dar una respuesta categórica acerca de Windows 7.
El blog de arena identificó cuatro principales cambios que D3D12 hace al modelo de programación de Direct3D: objetos de estado de tuberías, listas de comandos, paquetes, y montones y tablas de descriptores. Estos son todos acerca de la reducción del nivel de abstracción y dando a los desarrolladores un mejor control sobre el hardware. Aquellos de ustedes bien informado de Manto pueden encontrar que algunas de esas construcciones tienen un anillo familiar para ellos. Esa familiaridad puede deberse en parte al papel de AMD (directos o indirectos) en Direct3D desarrollo de 12, pero sospecho que es explicable en gran medida por el hecho de que tanto D3D12 y Mantle son APIs gráficas de bajo nivel ajustarse estrechamente al comportamiento de la moderna GPUs.
Por ejemplo, del Manto tuberías monolíticos rodar la pipeline de gráficos en un único objeto. Direct3D 12 grupos de la pipeline de gráficos en "objetos de estado de tuberías", o las OSP. Esas obligaciones de servicio público funcionan como tales, de acuerdo con Sandy:
Direct3D 12. . . [] unifica gran parte del estado de tuberías en objetos de estado de tuberías inmutables (OSP), que se finalizaron en la creación. Esto permite que el hardware y los controladores para convertir inmediatamente el PSO en cualquier hardware que se necesitan instrucciones nativas y estatal para ejecutar el trabajo de la GPU. Qué PSO está en uso todavía se puede cambiar de forma dinámica, pero para ello el hardware sólo tiene que copiar la cantidad mínima de estado pre-computada directamente a los registros de hardware, en lugar de calcular el estado del hardware sobre la marcha. Esto significa reducido significativamente por encima llamada empate, y muchas más llamadas de dibujo por cuadro.
Gosalia dice PSO "envuelven de manera muy eficiente de hardware real GPU." Eso está en contraste con la representación de alto nivel de Direct3D 11 de la pipeline de gráficos, lo que induce mayor sobrecarga. "Por ejemplo," Sandy explica, "muchas GPUs combinan Shader y de salida de estado de fusión de píxeles en una sola representación de hardware, sino porque la API Direct3D 11 permite que estos pueden fijar por separado, el conductor no puede resolver las cosas hasta que sabe que se termine la estatal, que no es hasta la hora de dibujar ". El enfoque de D3D11 aumenta la sobrecarga y limita el número de llamadas de dibujo que pueden ser emitidos por cada trama.
D3D12 también sustituye modelo de ejecución basado en el contexto de D3D11 con algo llamado listas de comandos, que suenan bastante comparable a los tampones de comandos de Mantle. Aquí está la explicación de arena de nuevo:
Direct3D 12 introduce un nuevo modelo para la presentación de trabajo sobre la base de listas de comandos que contienen la totalidad de la información necesaria para ejecutar una determinada carga de trabajo en la GPU. Cada nueva lista de comandos contiene información como la que PSO usar, qué textura y el tampón se necesitan recursos, y los argumentos de todas Dibujar llamadas. Debido a que cada lista de comandos es autónomo y hereda ningún estado, el conductor puede pre-calcular todos los comandos de GPU necesaria por adelantado y de manera gratuita-threaded. El único proceso en serie es necesario es la presentación final de las listas de comandos para la GPU a través de la cola de comandos, que es un proceso muy eficiente.
D3D12 lleva las cosas un paso más allá con un constructo denominado paquetes, lo que permite a los desarrolladores de los comandos de reutilización con el fin de reducir aún más los gastos generales del controlador:
Además de las listas de comandos, Direct3D 12 también introduce un segundo nivel de trabajo de pre-cálculo, haces. A diferencia de las listas de comandos que son completamente autónomos y típicamente construidos, presentado una vez, y se desecha, paquetes proporcionan una forma de herencia del estado que permite su reutilización. Por ejemplo, si un partido quiere sacar dos modelos de los personajes con diferentes texturas, un método consiste en grabar una lista de comandos con dos juegos de las llamadas de dibujo idénticos. Sin embargo, otro enfoque consiste en "grabar" un paquete que dibuja un único modelo de personaje, y luego "reproducir" el paquete dos veces en la lista de comandos utilizando diferentes recursos. En este último caso, el conductor sólo tiene que computar las instrucciones correspondientes una vez, y la creación de la lista de comandos que esencialmente equivale a dos llamadas a funciones de bajo costo.
Gracias a todo esto Shader y de almacenamiento en caché de estado de tuberías, Gosalia dice que debería haber "no más compila en el medio del juego." Compilación de sombreado en tiempo Draw puede causar tirones (o los picos de latencia frame) durante el juego, y los desarrolladores lamentado que en el evento APU13 de AMD el año pasado. Dan Baker, de óxido de juegos dice que, en D3D12, "debemos no tener contratiempos marco causados por conducir en absoluto."
Tanto Mantle y D3D12 introducen nuevas formas de enlazar recursos a la pipeline de gráficos, también. El modelo de D3D12 implica montones de descriptores, que no suenan tan diferentes a conjuntos de descriptores de Mantle. Arena explica:
En lugar de exigir vistas de recursos independientes y asignación explícita a las franjas horarias, Direct3D 12 proporciona un montón descriptor en la que los juegos crean sus distintos puntos de vista de los recursos. Esto proporciona un mecanismo para la GPU para escribir directamente la descripción de recursos en hardware nativo (descriptor) a la memoria por adelantado. Declarar que los recursos deben ser utilizados por el oleoducto para una llamada sorteo especial, juegos especifican una o más tablas de descriptores que representan sub-rangos del descriptor montón completo. A medida que el descriptor del montón ya se ha rellenado con los datos de descriptores específicos de hardware apropiados, el cambio de tablas de descriptores es una operación muy bajo costo.
Además de la mejora del rendimiento ofrecido por montones y tablas de descriptores, Direct3D 12 también permite que los recursos se indexan de forma dinámica en shaders, proporcionando una flexibilidad sin precedentes y el desbloqueo de nuevas técnicas de representación. A modo de ejemplo, los motores de renderizado diferido modernos normalmente codifican un material o identificador de objeto de algún tipo a la g-buffer intermedio. En Direct3D 11, estos motores deben tener cuidado para evitar el uso de demasiados materiales, incluyendo muchos en una g-buffer puede ralentizar considerablemente la representación final pase. Con los recursos de forma dinámica indexables, una escena con un millar de materiales se puede finalizar con la misma rapidez como uno con sólo diez.
Según Sandy, montones descriptor "coinciden hardware moderno y significativamente mejoran el rendimiento." El enfoque D3D11 es "altamente abstracta y conveniente," él dice, pero requiere de juegos para emitir llamadas de dibujo adicionales cuando los recursos necesitan ser cambiados, lo que conduce a una mayor sobrecarga.
Según Yuri Shtil, Arquitecto Senior en Infraestructura Nvidia, la introducción de montones descriptor transfiere la responsabilidad de la gestión de los recursos en la memoria del controlador de la aplicación. En otras palabras, es responsabilidad del desarrollador para la gestión de memoria. Esta disposición es más una reminiscencia de Mantle. AMD elogió la asignación de memoria manual del Manto como una mejora importante y como un medio para hacer un uso más eficiente de la memoria de la GPU.
Ahora, por supuesto, la abstracción de bajo nivel de ese tipo puede ser un arma de doble filo. Debido a que los desarrolladores tienen un mayor nivel de control sobre lo que ocurre en el hardware, el conductor y API son capaces de hacer menos trabajo, pero esto también conduce a más oportunidades para que las cosas salgan mal. He aquí un ejemplo de Tamasi de Nvidia:
Piense acerca de la gestión de memoria, por ejemplo. La forma de DirectX 11 obras es, si desea asignar una textura, antes de poder utilizarlo, el conductor básicamente pre-valida que ese recuerdo sea residente en la GPU. Así, hay trabajos que se realicen en el controlador y en la CPU para validar que ese recuerdo sea residente. En un mundo donde el desarrollador controla la asignación de memoria, ellos ya sabrán si han asignados o desasignada ese recuerdo. No hay verificación de que tiene que suceder. Ahora bien, si los tornillos de desarrolladores y trata de hacer a partir de una textura que no es residente, se va a romper, ¿verdad? Pero debido a que tienen el control de eso, no hay paso de validación que deberá tener lugar en el conductor, y así ahorrar ese trabajo de la CPU.
Los desarrolladores que prefieren no hacer frente a tales riesgos no tendrán que hacerlo. Según Max McMullen, Director de desarrollo de Microsoft para Windows Graphics, D3D12 dará a los desarrolladores la opción de utilizar el modelo de programación más abstraído de D3D11. "Cada algoritmo que se puede construir el 11 de este momento, se puede construir el 12", dijo.
d3d11:
d3d12:
Sin embargo, conseguir las manos sucias con el modelo de programación de nivel inferior debe pagar algunos dividendos muy reales. Una de las demostraciones que se muestran en la GDC era una costumbre, versión D3D12 de 3DMark de Futuremark se ejecuta en un procesador de cuatro núcleos Intel. La demo D3D12 utiliza 50% menos de tiempo de CPU que la versión D3D11, y en lugar de dumping mayor parte de la carga de trabajo en un núcleo de la CPU, se extendió la carga de manera bastante uniforme en los cuatro núcleos. Las imágenes anteriores muestran las diferencias en la utilización de la CPU en la parte superior izquierda.
Baker Óxido mencionó otras posibles upsides a D3D12, incluyendo una "gran reducción en la complejidad del conductor" y "juegos en general más sensibles ... incluso a una velocidad más baja." D3D12 no puede simplemente extraer un rendimiento adicional y haciendo complejidad del hardware actual. También puede hacer que los juegos se sienten mejor en formas sutiles pero importantes. Además, si lo que Baker dijo acerca de la robustez del controlador comprueba hacia fuera, los jugadores de PC pueden perder menos tiempo de espera en las correcciones del controlador específicos del juego y optimizaciones de los fabricantes de GPU.
Direct3D 12 en el hardware futuroLos desarrolladores serán capaces de explotar el nuevo modelo de programación de D3D12 en una amplia gama de procesadores gráficos existentes. Además de que el modelo de programación, sin embargo, D3D12 introducirá algunas nuevas características de renderizado que requerirán nuevas GPUs. Microsoft bromeó un par de aquellos que presten funciones en la GDC:
No estoy del todo claro lo que se supone que los nuevos modos de mezcla que hacer, pero como yo lo entiendo, la rasterización conservador ayudaré con objeto de sacrificio (es decir, ocultando geometría que no debe ser visto como objetos detrás de una pared) así como la detección de colisiones.
Tamasi de Nvidia nos dijo D3D12 incluye un "manojo entero más" nuevas funciones de representación más allá de los que Microsoft ya ha discutido. Espero que vamos a oír más sobre ellos cuando Microsoft ofrece la versión preliminar de la nueva API para desarrolladores, que está previsto que ocurra a finales de este año.
¿Qué nueva generación GPUs apoyará esas nuevas características? No lo sabemos aún. Dado que se espera que los primeros títulos D3D12 en la temporada de vacaciones de 2015, me sorprendería si Nvidia y AMD no tenían un nuevo hardware con soporte completo D3D12 listo para entonces. Por otra parte, ni AMD ni Nvidia han anunciado nada de eso todavía. Tendremos que esperar y ver lo que esas empresas tienen que decir cuando Microsoft revela completa gama de nuevas características de renderizado de D3D12.
Toma de AMD y el futuro del MantoDesde el día en que Microsoft anunció DirectX 12, AMD ha dejado claro que es totalmente detrás de la nueva API. Su mensaje es simple: Direct3D 12 "apoya y celebra" el empuje hacia la abstracción de bajo nivel que AMD comenzó con Manto años-pero la última D3D12 no estará listo de inmediato, y, mientras tanto, los desarrolladores pueden utilizar Manto con el fin de obtener algunas de las mismas ganancias de hardware de AMD.
En la GDC, Corpus de AMD elaboró un poco en ese mensaje. Me dijo que la llegada de Direct3D 12 no significará el fin de Mantle. D3D12 no llega tan cerca del metal de AMD Graphics Core Siguiente GPUs como hace Mantle, afirmó, y Mantle "va a hacer algunas de las cosas más rápido." Manto también puede ser más rápido para aprovechar el nuevo hardware, ya que AMD será capaz de actualizar la API de forma independiente sin tener que esperar a que Microsoft lanzará una nueva versión de Direct3D. Por último, AMD está hablando con los desarrolladores sobre traer Manto de Linux, donde no tendría la competencia de Microsoft.
Corpus fue firme en que los desarrolladores podrán ver el valor de la adopción de Manto aún hoy, con D3D12 en el horizonte y sin apoyo explícito a Linux o futura GPU de AMD. Debido a que el API es similar a D3D12, dará a los desarrolladores una "ventaja importante", dijo, y podemos ver títulos D3D12 lanzamiento "muy pronto" como resultado.
Naturalmente, AMD puede motivar a los desarrolladores de otras maneras también. Mientras Corpus no se refirió a ese lado de la ecuación, VG247 informó el año pasado que Battlefield 4 's la inclusión en el programa-and Gaming Evolved su apoyo a los involucrados-Manto un pago de $ 5-8 million de AMD. Esa cifra nunca fue confirmado oficialmente, pero no es ningún secreto AMD y Nvidia de relaciones con desarrolladores y los programas de co-marketing a menudo implican incentivos financieros. Apoyar Manto puede ser una propuesta muy lucrativa para algunos estudios de juegos.
Toma de NvidiaNvidia parece ver las API de gráficos de nivel inferior como menos de una panacea que AMD hace. Tamasi nos dijo que, si bien este tipo de API están "muy bien", que son "no es la única respuesta" porque son "no necesariamente bueno para todos." Esta declaración se remonta a lo que dijimos antes acerca de los desarrolladores de tener control manual sobre las cosas actualmente manejados por el API y el conductor, como la gestión de memoria de la GPU. Gurús de programación del motor como de DICE Johan Andersson y Tim Sweeney de Epic podría ser perfectamente feliz para gestionar los recursos de forma manual, pero de acuerdo a Tamasi, "mucha gente no lo haría."
Nvidia también cree que todavía hay algo de potencial sin explotar para mejorar la eficiencia y la reducción de gastos generales en D3D11. Desde el debut de Mantle hace seis meses, Nvidia ha "redoblado" sus esfuerzos para frenar la sobrecarga de la CPU, mejorar escalamiento multi-core, y utilizar el almacenamiento en caché de sombreado para abordar los problemas de tartamudez. (Tamasi admitió libremente que la liberación de Mantle impulsó la iniciativa. "AMD y Mantle deben recibir crédito para la revitalización ... y lograr que las personas encendieron", dijo.)
Nos vimos de primera mano los resultados del trabajo de Nvidia hace dos meses. En una prueba de campo de batalla CPU limitada 4, controlador Direct3D de Nvidia realizó claramente mejor que AMD. Ese trabajo de optimización está todavía en curso:
Los datos de rendimiento anterior, suministrada a nosotros por Nvidia, muestra mejoras en el rendimiento respecto a las versiones de controladores GeForce sucesivas de óxido Juego Estrella Swarm prueba de esfuerzo. Esa prueba también es compatible con Mantle, que ayuda a poner optimizaciones D3D11 de Nvidia en su contexto. Tamasi concedido versión de AMD Mantle "todavía tiene marcos menos lentos" y que D3D11 "todavía [tiene] algunos factores limitantes", pero reiteró su argumento principal, que es que es posible "hacer un trabajo mucho mejor" con D3D11. Incluso ir por nuestros propios números, tal vez menos halagüeñas, diríamos que es una evaluación justa.
¿Qué pasa con OpenGL?Direct3D 12 tiene un montón de promesas, pero no va a ayudar a la gente que ejecutan sistemas operativos basados en Linux como SteamOS. Los desarrolladores de juegos que tratan de escribir puertos nativos para los sistemas operativos tendrán que usar OpenGL, y van a tener que extraer cualquier optimizaciones que puedan de esa API.
Tamasi nos dijo Nvidia, AMD e Intel han sido todos "trabajando duro" para ayudar a los desarrolladores a lograr "super alta eficiencia" con OpenGL. En una sesión de GDC titulado "cercanos a cero Overhead Conductor en OpenGL," la gente de las tres empresas demostraron mejores prácticas para optimizaciones de OpenGL. Las técnicas que se describen se pueden explotar con la versión actual de la API en el hardware de hoy con los controladores existentes, y pueden dar lugar a grandes mejoras en el rendimiento.
Durante la sesión, vimos los números de rendimiento obtenidos con APItest , un punto de referencia de código abierto desarrollado por Blizzard Patrick Doane. En palabras de Nvidia, APItest está "diseñado para mostrar y comparar entre diferentes enfoques de los problemas comunes que se encuentran en aplicaciones de renderizado en tiempo real." Los resultados mostraron diferencias en el rendimiento de un orden de magnitud entre un enfoque de "ingenuo", que describió como "Tamasi escritura OpenGL como Direct3D", y las mejores prácticas recomendadas por los fabricantes de GPU.
En el gráfico anterior, el enfoque de la línea de base "ingenuo" es la barra superior, mientras que la última barra es lo Tamasi describe como "escribir buen código." La diferencia equivale a un aumento de velocidad de 18X. Obviamente, este es un caso de prueba aislado en lugar de un escenario integral del juego similares. Pero yo diría que la diferencia es lo suficientemente grande como para que, al menos, algunos desarrolladores de OpenGL repensar la forma en que optimizar su código.
La lección importante aquí, creo yo, es que a pesar de su implicación con D3D12, los tres grandes fabricantes de PC de gráficos por hardware de AMD, Intel y Nvidia, todos tienen interés en mantener OpenGL competitivo. Eso es una buena noticia para los usuarios de Linux, y es especialmente una buena noticia para aquellos de nosotros con la esperanza de ver SteamOS se convierten en un verdadero competidor a Windows en el terreno de los juegos de PC.
Por supuesto, SteamOS no saldrá a la venta hasta el verano, y los primeros títulos D3D12 no se espera hasta que la temporada de vacaciones de 2015. Vamos a tener que volver a estas cuestiones en el futuro, cuando podemos ver por nosotros mismos cómo los juegos de nueva generación realmente realizan en las dos plataformas.
Fuente original:
http://techreport.com/review/26239/a-cl ... directx-12 
![[carcajad]](/images/smilies/nuevos/risa_ani2.gif "carcajada")
![[sonrisa]](/images/smilies/nuevos/risa_ani1.gif "sonrisa")
![[buenazo]](/images/smilies/nuevos/risa_tonta.gif "buenazo")
![[360º]](/images/smilies/nuevos/vueltas.gif "como la niña del exorcista")
..........![[+risas]](/images/smilies/nuevos/risa_ani3.gif "más risas")
![[buuuaaaa]](/images/smilies/nuevos/triste_ani3.gif "a lágrima viva")
![[oki]](/images/smilies/net_thumbsup.gif "Ok!")
