[Hilo Oficial] La revolución de las APIs gráficas (DX12 y Vulkan)

1, 2, 3, 4, 58
Amdar escribió:Me surgen varias dudas...

Teniendo vulkan y dx12 el desarrollador creo yo que optara por vulkan porque el juego sera portable a más plataformas sean Linux, Mac. ¿Se sabe algo de la implementación de vulkan en dichos sistemas principalmente Linux? Esto puede ser un puntazo para Linux ya que le daría un buen empuje. ¿Se sabe cuando habrá drivers que soporten vulkan para nvidia y amd? En definitiva ¿tenéis algo más de información sobre vulkan en los otros sistemas?


Vulkan le puede dar un empuje a Linux, pero ten en cuenta que las desarrolladoras van a usar DX12 como base si o si por que básicamente representa mas de un 90% del mercado y Microsoft hará presión allí donde haga falta.

Lo mas probable es que sean las Steam Machine lo que revitalice de verdad la plataforma Linux y le de esa oportunidad tan esperada de competir tu a tu contra Windows, pero todo esto esta en pañales todavía.
Dfx escribió:Vulkan le puede dar un empuje a Linux, pero ten en cuenta que las desarrolladoras van a usar DX12 como base si o si por que básicamente representa mas de un 90% del mercado y Microsoft hará presión allí donde haga falta.

Lo mas probable es que sean las Steam Machine lo que revitalice de verdad la plataforma Linux y le de esa oportunidad tan esperada de competir tu a tu contra Windows, pero todo esto esta en pañales todavía.

Te doy la razón en que Microsoft se sacará la cartera. Pero, ¿a qué te refieres con que representa más del 90% del mercado?

Si te refieres a Windows, Vulkan también es compatible con Windows de la misma forma que DX12. Es más, mientras DX12 es solo para W10, Vulkan también podrá funcionar en versiones anteriores.
josemurcia escribió:
Dfx escribió:Vulkan le puede dar un empuje a Linux, pero ten en cuenta que las desarrolladoras van a usar DX12 como base si o si por que básicamente representa mas de un 90% del mercado y Microsoft hará presión allí donde haga falta.

Lo mas probable es que sean las Steam Machine lo que revitalice de verdad la plataforma Linux y le de esa oportunidad tan esperada de competir tu a tu contra Windows, pero todo esto esta en pañales todavía.

Te doy la razón en que Microsoft se sacará la cartera. Pero, ¿a qué te refieres con que representa más del 90% del mercado?

Si te refieres a Windows, Vulkan también es compatible con Windows de la misma forma que DX12. Es más, mientras DX12 es solo para W10, Vulkan también podrá funcionar en versiones anteriores.


Basicamente a lo que dije en otro hilo que se refleja en las estadisticas de STEAM, Linux representa menos de un 1% de las plataformas y MAC apenas un poco mas del 3%, un atractivo que nisiquiera llega al 5%, teniendo DX11 y DX12 que es donde esta trabajando casi todo el mundo para específicamente la plataforma que mas se usa...

Que si, que Vulkan es compatible con Windows, pero tiene que ofrecer algo mas para que sea atractivo para los desarrolladores, logicamente un 1% no se traduce en un 1% mas de ventas por que no todos los usuarios compran.

Quizas esa compatibilidad fuera de W10 y que Vulkan sea superior a DX11 pueda atraer mucho publico, pero vuelvo a repetir que Vulkan necesita destacar, ya sea en rendimiento y/o en graficos y eso influira luego en el numero de títulos que podamos ver también en Linux y que muchos usuarios opten por hacer de Linux su plataforma primaria con el tiempo.

Seguramente también veamos algún híbrido DX12/Vulkan, ya se vera, ahora mismo me preocupan mas los efectos propietarios como gameworks.
El modelo programacional de DX12 no tiene nada que ver con DX11. No estamos hablando de que los devs dejen de usar lo que ya conocen para usar Vulkan, como ha pasado hasta ahora con DX y OpenGL(problema de drivers mierda de AMD a parte) que son 2 APIs muy distintas.

Estamos hablando de que ha surgido un nuevo modelo de programación gráfica en PC, que es el mismo tanto para DX12 como para Vulkan y no tiene nada que ver con lo que había hasta ahora, con lo cual no se puede decir que en DX12 es donde está trabajando todo el mundo porque no lo está haciendo, todo el mundo está trabajando en algo totalmente distinto que es DX11, incluso muchos en DX9.

Con lo cual la situación está así:
DX12: Windows y Xbox ONE
Vulkan: Windows, MAC, Linux, Android, iOS, etc.

Realmente el simple hecho de poder abarcar tantas plataformas ya debería ser un atractivo para los desarrolladores. El tener drivers de código abierto en Linux también es una ventaja que va a facilitar mucho el aprendizaje de Vulkan, mientras que los drivers de DX12 seguirán siendo una caja negra cerrada.

A priori DX12 no destaca sobre Vulkan sino todo lo contrario, salvo por la cartera de Microsoft.
Yo creo, que el que sea multiplataforma es el mayor handicap y si le sumas que valve es una empresa muy grande y con mucho interés en exactamente eso, tener juegos multiplataforma, puede que tengamos el mayor cambio de tendencia desde hace años. Las compañias buscan llegar con su juego a consolas y PC principalmente en windows, pero ese 1% y ese 3% es mucha gente. De todas maneras creo que esos porcentajes son de uso de steam no así de uso de la plataforma que en Mac según lei la última vez en un 9% y en Linux un 3%.
Como siempre, la diferencia de qué se usará no estará en el número de plataformas a las que puedes portearlo, porque eso siempre se puede hacer más tarde, sino en quién es el que te da mejores herramientas y mejor soporte, no se trata de cartera, si Microsoft pone toda la carne en el asador para ayudar a los desarrolladores, éstos preferirán su plataforma, así ha sucedido antes y es como sucederá, se trata de hacer la vida más fácil al desarrollador, que si Vulkan tiene mejores herramientas o equipo de soporte, se irán a ésta igualmente.
papatuelo escribió:Imagen



Ese es el verdadero (para mi) avance.
Y lo del soporte multigpu nativo en DX12.

Que AMD saque ya las 390/X [angelito] y que por favor, sean un poco menos calientes y tragonas.
Si cumplen esas 2 premisas, se vienen 2 p'aquí.

Edito
http://www.guru3d.com/news-story/amd-fiji-xt-photo.html

The card has two 8-pin connectors, so its definitely drawing a lot of power.


D'OH!
papatuelo escribió:Imagen
Imagen
Imagen


Si los juegos en DX12 acaban implementado las mejoras comentadas en combinaciones multi-gpu y el rendimiento mejora (o no se resiente), podre estirar la vida de mi equipo muchísimo tiempo.

8GB de VRAM en vez de 4GB para jugar a 4K lo voy a agradecer muchísimo.
Y debe quedar un par de mesecillos para que la version beta sea gold.
Yo, por una cagada de principiante, tenía dual boot con win7, y ahora uso win10 como principal.

Me gustaría pillarlo original, tenia un windows8 original que vendí por miseria pensando que nos iban a actualizar de free. CagÜen!!!!
Los últimos drivers Catalyst para W10 ya reportan correctamente el feature level de GCN 1.1 y el Resource Binding Tier 3.

Direct3D 12 feature checker (May 2015) by DmitryKo
https://forum.beyond3d.com/posts/1840641/

Using minimum feature level 11_0

ADAPTER 0
"AMD Radeon R9 200 Series (Engineering Sample - WDDM v2.0)"
VEN_1002, DEV_67B0, SUBSYS_30801462, REV_00
Dedicated video memory : 3221225472 bytes
Total video memory : 4294901760 bytes
Maximum feature level : D3D_FEATURE_LEVEL_12_0 (0xc000)
DoublePrecisionFloatShaderOps : 1
OutputMergerLogicOp : 1
MinPrecisionSupport : D3D12_SHADER_MIN_PRECISION_SUPPORT_NONE (0)
TiledResourcesTier : D3D12_TILED_RESOURCES_TIER_2 (2)
ResourceBindingTier : D3D12_RESOURCE_BINDING_TIER_3 (3)
PSSpecifiedStencilRefSupported : 1
TypedUAVLoadAdditionalFormats : 1
ROVsSupported : 0
ConservativeRasterizationTier : D3D12_CONSERVATIVE_RASTERIZATION_TIER_NOT_SUPPORTED (0)
MaxGPUVirtualAddressBitsPerResource : 38
StandardSwizzle64KBSupported : 0
CrossNodeSharingTier : D3D12_CROSS_NODE_SHARING_TIER_NOT_SUPPORTED (0)
CrossAdapterRowMajorTextureSupported : 0
VPAndRTArrayIndexFromAnyShaderFeedingRasterizerSupportedWithoutGSEmulation : 0
ResourceHeapTier : D3D12_RESOURCE_HEAP_TIER_2 (2)
Adapter Node 0: TileBasedRenderer: 0, UMA: 0, CacheCoherentUMA: 0tUMA: 0
Como sea verdad y funcione eso del soporte nativo multiGPU, se viene otra 290 corriendo para casita :D
En este foro de desarrollo de juegos, hablan en general que existe una gran diferencia de las versiones anteriores de OpenGL a Vulkan destacando que mejora mucho el poder crear bajo vulkan al ser mas claro y organizado.

http://www.gamedev.net/topic/666419-wha ... kanmantle/

Aunque parece siempre tiene una pequeña ventaja D3D12 en ese rubro contra Vulkan

http://www.gamedev.net/topic/666986-dir ... ow-public/



SashaX escribió:Que AMD saque ya las 390/X [angelito] y que por favor, sean un poco menos calientes y tragonas.
Si cumplen esas 2 premisas, se vienen 2 p'aquí.

Edito
http://www.guru3d.com/news-story/amd-fiji-xt-photo.html

The card has two 8-pin connectors, so its definitely drawing a lot of power.


D'OH!


Al ser tope de gama, es claro que debe consumir bastante energia, porque es de alto rendimiento, pero parece que sera menos que las versioens anteriores.





.
Amdar escribió:Me surgen varias dudas...

Teniendo vulkan y dx12 el desarrollador creo yo que optara por vulkan porque el juego sera portable a más plataformas sean Linux, Mac.

Esto sera un paso mas en la guerra DX vs. OpenGL ...

A mi personalmente me encantaría que triunfase Vulkan, ya que creo que los estándares abiertos, pero viendo lo que hemos tenido en el pasado con DX, tengo pocas esperanzas.

Un factor muy importante yo creo que sera el soporte de los motores, si Unreal y CryEngine dan soporte para Vulkan, pues ya será un gran paso.

Y otro factor sera Valve, si está dispuesto a invertir pasta favorecer a Vulkan, y así hacer triunfar su SteamOS. Y este es un factor nuevo, que no estaba antes en la guerra, nadie ponia pasta para contrarrestar a Microsoft.
Muy a mi pesar, tenemos un nuevo contendiente, Apple en lugar de abandonar Metal en iOS y adoptar Vulkan en este y OSx, va a hacer lo opuesto, adoptar Metal en OSx y no dar soporte a Vulkan.
Apple se lo pierde [aunque los entiendo]



Como sea, esta tabla parece la mas completa y veraz sobre el tema de Soporte a las FEATURES de Dirct3D12/DXGI12.

.
Imagen .
Gracias por la tabla Trastaro.
Por nada, y se me paso poner el link de donde viene la tabla

http://www.computerbase.de/2015-06/dire ... l-12-0-gcn
josemurcia escribió:Muy a mi pesar, tenemos un nuevo contendiente, Apple en lugar de abandonar Metal en iOS y adoptar Vulkan en este y OSx, va a hacer lo opuesto, adoptar Metal en OSx y no dar soporte a Vulkan.


No se ha dicho que no se de soporte a Vulkan, se ha dicho que incluirán Metal... Apple es miembro de Khronos Group e invierte mucho dinero en Vulkan, supongo que si que lo lanzaran para mac cuando este listo, eso no quita que hayan sacado su propia librería.
La pregunta es, ¿para qué es miembro Apple el grupo Khronos? Si luego su soporte OpenGL es una mierda, en OSx van 5 años con retraso.

Dan Baker de Oxide Games da a entender que Apple no dará soporte a Vulkan en OSx.
Imagen
TRASTARO escribió:Apple se lo pierde [aunque los entiendo]



Como sea, esta tabla parece la mas completa y veraz sobre el tema de Soporte a las FEATURES de Dirct3D12/DXGI12.

.
Imagen .


Hasta donde yo se esa tabla está mal.

La 250X es cape verde y no es 12_0
Pero las 240 y 250 a pelo son oland y son 12_0

No sé si habra más errores y el error es por mi parte pero si vais a techpowerup, a la base de datos de GPUs, precisamente la 240 y 250 están actualizadas hace unos días, el 6 de junio creo, y les dan compatibilidad 12_0.

Por cierto Shader Model 5.1 para DX12:

https://msdn.microsoft.com/en-us/library/windows/desktop/dn933277(v=vs.85).aspx
Gracias por indicarlo...

Pues hasta el momento he buscado y encontrado que el OlandPro/OlandXT y CapaVerdeXT son GCN 1.0, y al momento sigue sin tener soporte al feature 12.0/12.1 por hardware.

https://www.reddit.com/r/Amd/comments/3 ... 2_feature/

Aqui otra tabla desmenusada con mas detalles, y coincide [me parece] con la anterior.
Imagen

Imagen

Si alguien encuentra mas informacion al respecto.... pues que la pase ya.


.
@TRASTARO

Miralo aquí

http://www.techpowerup.com/gpudb/

A la derecha, arriba, salen las últimas actualizadas. El seis de enero entre otras actualizaron las Oland y no se lo que pondría antes, pero al menos ahora pone DX 12_0
Ya veo, te refieres a esto:

Imagen


Y esto, que indica la compatibilidad hardware con X version de la API DirectX3D, ¿no?

Imagen


Pues por ahora no le tomaria mucha confianza, pues mira que hay discrepancias. La 250 y 250X es compatible Direct3D12 [D3D12], pero en su base actual solo la 250 es D3D12 misntras la 250X sigue apareciendo como D3D11.2.

Ahora, tambien creo que estas confundiendo la FEATURE LEVEL con la version de la API. Tenemos entonces que GCN 1.0, efectivamente soportara muchas de las funciones de la API D3D12 en el manejo del procesador y los hilos y su organizacion con el GPU, pero a niveles graficos esta restringida a los efectos visuales de D3D11.1 por su diseño de arquitectura que tiene. Vamos, la feature_level la podemos considerar como una medida de retrocompatibilidad de la nueva API D3D con GPUs fabricados antes de la creacion de dicha nueva API D3D.

Por eso en la tabla aparece marcada como SI en "SOPORTE D3D12", y con 11_1 en "NIVEL FEATURES"


https://msdn.microsoft.com/en-us/librar ... 85%29.aspx
microsoft escribió:Direct3D feature levels

To handle the diversity of video cards in new and existing machines, Microsoft Direct3D 11]introduces the concept of feature levels. This topic discusses Direct3D feature levels.

Each video card implements a certain level of Microsoft DirectX (DX) functionality depending on the graphics processing units (GPUs) installed. In prior versions of Microsoft Direct3D, you could find out the version of Direct3D the video card implemented, and then program your application accordingly.

With Direct3D 11, a new paradigm is introduced called feature levels. A feature level is a well defined set of GPU functionality. For instance, the 9_1 feature level implements the functionality that was implemented in Microsoft Direct3D 9, which exposes the capabilities of shader models ps_2_x and vs_2_x, while the 11_0 feature level implements the functionality that was implemented in Direct3D 11.

Now when you create a device, you can attempt to create a device for the feature level that you want to request. If the device creation works, that feature level exists, if not, the hardware does not support that feature level. You can either try to recreate a device at a lower feature level or you can choose to exit the application. For more info about creating a device, see the D3D11CreateDevice function.





.
Eso es la versión de la API que soporta, no el feature level. La tabla que ha puesto TRASTARO antes está bien hasta donde yo he visto.
@TRASTARO

Chicos, creo que es el feature level.

Y si no mirad otras gráficas.

Mirad la 980 y veréis el 12_1

Y la 250X marca 11_2 porque no es el mismo núcleo que la 250.

La primera es cape verde mientras que la segunda es oland.
Si en la 980 Ti marca 12.1 lo que hay es una errata.

La 250X está sin actualizar a 12. Pero no puede ser el feature level porque para empezar no existe el feature level 11.2.
Pues hasta el momento todos indican un FEATURE_LEVEL hasta 11_1, con lo que podemos entender que no existe un FEATURE_LEVEL 11_2, mas sin embargo si existe una version de la API D3D11.2 [que es soportada a partir de windows 8.1], si incluso hay una version de la API D3D11.3.

Imagen


Y pues viendo solo la imagen, se ve que por GRAPHICS FEATURES se refieren solo a que version de la API D3D es soporta por hardware, pero no nos dice nada del FEATURE_LEVEL.

Imagen


Pero si, es algo confuso porque es algo que no se venia manejando tantio como ahora que nos trae extasiados esto de las nuevas APIs a bajo nivel.
El tema es que eso datos salen del GPU-Z, que es software propio de Techpowerup.

Pero no sé, quizá sea un error como decís, aunque lo de 12.1 está en toda la familia 900.

Edito:

@TRASTARO

Mira he encontrado que Oland es GCN 1.1:

Edit: This post originally referred to Oland as a GCN 1.0 chip. It’s at least provisionally GCN 1.1, though it lacks certain features traditionally identified with that architecture, like TrueAudio support.


http://www.extremetech.com/extreme/207598-demystifying-directx-12-support-what-amd-intel-and-nvidia-do-and-dont-deliver

Creo que al menos en el tema de si es 12.0 o feature inferior os podéis fiar de techpowerup.

PD: Creo que DX11.3 no ha salido aun, era una especie de DX12 para W7 y W8
Es que GPU-Z no reporta el FEATURE_LEVEL, solo la version del API d3d soportada por hardware, y hasta la fecha aun no existe una version de la API d3d 12.1 aunque nVidia informa que sus GPUs soportaran esta nueva API por hardware cuando salga [cosa que aun no ocurre], y con ello GPU-Z debe reportar que por hardware esas GPUs de nvidia soportan por hardware d3d12.1 aunque aun no este disponible esa version de la api d3d.

Vamos, que es igual que cuando AMD saco sus GPUs compatibles con D3D10.1 mientras nvidia solo tenia hasta la d3d10.0, asi GPU-Z te indicaba que las radeon soportaban d3d10.1 aunque esa version de la API pocos juegos la usaban.

Si es confuso eso del FEATURE_LEVEL, pero si lo meditas un rato, le encuentras sentido y podras diferencias entre que es VERSION del API, y que es Feature_Level.
Trastaro, he editado mi mensaje anterior.

Oland es 1.1, por lo tanto el feature level es bueno.
Ese articulo de ExtremeTech se basa en información errónea, para empezar la tabla que dicen que es de microsoft pero no de donde la han sacado y esta completamente mal.

Oland es GCN 1.0, no se de donde se sacan lo contrario.
josemurcia escribió:Ese articulo de ExtremeTech se basa en información errónea, para empezar la tabla que dicen que es de microsoft pero no de donde la han sacado y esta completamente mal.

Oland es GCN 1.0, no se de donde se sacan lo contrario.


Pues no es en el único sitio que lo dicen.

De hecho en más de un artículo la introducen como el escalon más bajo de las volcanic island.
Pues mira, para mi es mas una coincidencia.

Es que insisto en que techpowerUp asi como tiene su base de datos, no esta refiriendose precisamente a FEATURE LEVEL, y si lo esta haciendo, AH, PUES QUE CAMBIEN LA ETIQUETA O PONGAN UNA NUEVA QUE DIGA PRECISAMENTE "FEATURE_LEVEL".

Algo asi como:

GRAPHICS FEATURES
DirectX/F_L: 12.0/11_1
OpenGL: xxx
OpenCL: xxxx

O
GRAPHICS FEATURES
DirectX: 12.0
Features_Level: 11_1
OpenGL: xxx
OpenCL: xxxx


Que por cierto, hasta la nomenclatura usada por microsoft tiene concordancia.

el punto "." seria empleado solamente en la VERSION de la API D3D
el guion bajo "_" seria empleado solamente para indicar el FEATURE_LEVEL

De esta manera cuando leamos '11.1' entenderemos inmediatamente que estamos hablando de la API d3d11.1, mientras que si leemos '11_1' se refiere a que se pueden usar las funciones graficas de 'd3d11' en su nivel '1', vamos que esto ultimo tiene mas interes para el programador de juegos.


Y pues de lo otro, pues si es realmente GCN 1.1 pues que mejor, asi los que tengan esas tarjetas podran disfrutar tambien de los efectos visuales de d3d12 por hardware, y eso es bueno.

Ah, por cierto, espero no te este molestando el debate que estamos teniendo con el tema de techpowerup, la version y el feature_level.



.
Pues nada, será coincidencia.

No sé.
Aun no se si sea fiable esta tabla, pero puede dar referencia del nivel GCN.

Imagen
Vamos para atras, ahora lo quitan de ser un hilo FIJO.
TRASTARO escribió:Vamos para atras, ahora lo quitan de ser un hilo FIJO.

Es lógico, el hilo es meramente informativo y no aporta nada en la práctica.

Y ni siquiera es que haya estado saliendo información relevante durante los últimos meses.
Eso es irrelevante, o me diras que salen continuamente controles [o mandos] de consola, o que hay noticias continuas para las mismas, y aun asi sigue como fijo lo de tales mandos de consola.

La importancia de estas nuevas APIs graficas a bajo nivel va mas alla de que salgan o no noticias continuamente, ya que son un cambio radical tanto a nivel de industria o a nivel de desarrollo. ¿Que en la practica no aporta nada este tema?... me extraña esa manera de pensar.
Una explicacion en video del polemico sistema de computo asincrono

https://www.youtube.com/watch?v=v3dUhep0rBs
Warhammer 40,000: Inquisitor Martyr tambien usara la nueva API grafica Direct3D12. Y los desarrolladores de NeoGames hablan de las amplias oportunidades que les ofrece D3D12.

En especial Zoltán Pozsonyi, productor de este titullo, explica que:

"DirectX 12 no es algo que te permita simplemente jugar con algunos efectos nuevos durante el desarrollo. Se trata más de un proceso grande y estructural que permite a los programadores muchas más oportunidades al ofrecer un acceso más sencillo y directo a la GPU. Esto implica que tendrán mucho más margen para implementar optimizaciones de rendimiento y agilizar el código; si eres capaz de exprimir más rendimiento de la GPU, esto se traduce en mejoras en la tasa de imágenes por segundo o en un contendio visual más atractivo en el juego. DX12 soporta shaders de cálculo asincrónico, lo cual nos permite, por ejemplo, usar un mayor número de efectos especiales y de una mayor calidad, así como efectos de post-procesado, y procesarlos de forma mucho más rápida (screen space ambient occlusion, screen space reflection, mejor calidad de shadow mapping, transculency, tone mapping).

http://gamingbolt.com/dx12-will-allow-g ... ng-effects
Warhammer 40,000: Inquisitor Martyr developers on the benefits of the upcoming API and why they went multiplatform.
NeoCore Games, the developers behind the upcoming Warhammer 40,000: Inquisitor Martyr have a great experience in developing games for PC. In a recent interview with the development team at NeoCore, GamingBolt asked their thoughts on DirectX12 and how it will speed up and enhance game visuals on PC and Xbox One.

“Direct X 12 is not something that allows you to play around with new shiny effects during the development. It’s more of a big, structural development that gives the programmers a lot more opportunity by providing them easier access directly to the GPU,” Producer, Zoltán Pozsonyi explained to GamingBolt. “This means that they’ll have a lot more wiggle room for performance optimization and making the code run faster; if you’re able to squeeze out higher performance out of the GPU, that can be translated into framerate or more beautiful content in the game. DX12 supports asynchtonous compute shaders, which for example allows you to use more and better quality special effects and post process stuff, a lot faster (screen space ambient occlusion, screen space reflection, better quality shadow mapping, transculency, tone mapping).”

Warhammer 40,000: Inquisitor Martyr will be heading to the PS4 and Xbox One alongside PC and Mac when it launches next year. What kind of challenges did the development team faced while developing for consoles and what prompted the decision to go beyond the PC for this release?

“Consoles have always been on our radar, as you might have heard The Incredible Adventures of Van Helsing trilogy is also coming to Xbox One and PlayStation 4,” Lead Narrative Designer, Viktor Juhász states. “The new console generation’s architecture is very similar to the PCs and the machines are also powerful enough, so our biggest challenge is to make the controls feel just as intuitive with controllers, as it is with a keyboard and mouse setup.
In both the PC and console versions we wanted to find the balance between being faithful to the lore and to the requirements of a great ARPG. We had to overcome some serious technological challenges when we decided to revamp the engine. We still have a long way to go, like the creation of the persistent open world.”

Warhammer 40,000: Inquisitor Martyr will be out in 2016 for the PS4, Xbox One and PC. Stay tuned for our full interview in the coming days.


Asi que en principio mas leña a la polemica de si los shaders de computo asincrono tendran un factor preponderante en los juegos futuros o no.
Y segun los ultimos reportes de ventas, a AMD no le va mal en estos momentos con su serie Rx-300, posiblemente por algunos puntos en su diseño para varias cosas del d3d12/vulkan

hilo_un-ligero-repunte-en-ventas-de-amd-radeon_2123015


Es que aun no me repongo del shock de este rumor, que desgraciadamente resulto ser cierto:

hilo_houston-tenemos-un-problema-adios-jim-keller-y-gracias-por-el-festin-del-zen_2123460

Lo de menos es que se haya salido de AMD, lo que verdaderamente causa escalofrios, es el porque se fue, si por razones de dinero [cosa que dudo], o por razones profesionales como el que de un momento a otro hayan cambiado de enfoque en el diseño los directivos, o si como anteriormente, el vislumbro que el camino elegido por el CEO no era el mas conveniente para la empresa.

.
Yo sigo sin ver donde se quiere llegar con ZEN si va a ser según la información que se ha dado hasta ahora (50% mas de IPC, 2 hilos por core, 16 core?, HBM...).

A mi lo unico que me llama la atención es que se habla de HT inverso, que eso si podría ser una autentica revolución y parce que tanto Intel como AMD están trabajando en ello.
Dfx escribió:Yo sigo sin ver donde se quiere llegar con ZEN si va a ser según la información que se ha dado hasta ahora (50% mas de IPC, 2 hilos por core, 16 core?, HBM...).

A mi lo unico que me llama la atención es que se habla de HT inverso, que eso si podría ser una autentica revolución y parce que tanto Intel como AMD están trabajando en ello.


Pues asi a grosso modo, seria tener un IPC competitivo con su equivalente en intel recuperando el sector de alto rendimiento. AMD con el sistema SMT seria lo del HT inverso, pocos componentes, menor redundancia, mayor multihilo

Y de regreso a las APIs, hay nuevo banco de pruebas de Direct3D12 desarrollado por Microsoft:

hilo_multi-engine-n-body-gravity-otro-test-de-direct3d12-y-computo-asincrono_2124296

Imagen
Algo sobre WDDM 2.0 [Windows Display Driver Model 2.0] y el manejo de la memoria en sistemas MultiGPU.

GpuMmu model
Imagen

microsoft escribió:GPU virtual memory in WDDM 2.0

This section provides details about GPU virtual memory, including why the changes were made and how drivers will use it. This functionality is available starting with Windows 10.
Introduction

Under Windows Display Driver Model (WDDM) v1.x, the device driver interface (DDI) is built such that graphics processing unit (GPU) engines are expected to reference memory through segment physical addresses. As segments are shared across applications and over committed, resources gets relocated through their lifetime and their assigned physical addresses change. This leads to the need to track memory references inside command buffers through allocation and patch location lists, and to patch those buffers with the correct physical memory reference before submission to a GPU engine. This tracking and patching is expensive and essentially imposes a scheduling model where the video memory manager has to inspect every packet before it can be submitted to an engine.

As more hardware vendors move toward a hardware based scheduling model, where work is submitted to the GPU directly from user mode and where the GPU manages the various queue of work itself, it is necessary to eliminate the need for the video memory manager to inspect and patch every command buffer before submission to a GPU engine.

To achieve this we are introducing support for GPU virtual addressing in WDDM v2. In this model, each process gets assigned a unique GPU virtual address space in which every GPU context to execute in. An allocation, created or opened by a process, gets assigned a unique GPU virtual address within that process GPU virtual address space that remains constant and unique for the lifetime of the allocation. This allows the user mode driver to reference allocations through their GPU virtual address without having to worry about the underlying physical memory changing through its lifetime.

Individual engines of a GPU can operate in either physical or virtual mode. In the physical mode, the scheduling model remains the same as it is with WDDM v1.x. In the physical mode the user mode driver continues to generate the allocation and patch location lists. They are submitted along a command buffer and are used to patch command buffers to actual physical addresses before submission to an engine.

In the virtual mode, an engine references memory through GPU virtual addresses. In this mode the user mode driver generates command buffers directly from user mode and uses new services to submit those commands to the kernel. In this mode the user mode driver doesn’t generate allocation or patch location lists, although it is still responsible for managing the residency of allocations. For more information on driver residency, see Driver residency in WDDM 2.0.
GPU memory models

WDDM v2 supports two distinct models for GPU virtual addressing, GpuMmu and IoMmu. A driver must opt-in to support either or both of the models. A single GPU node can support both modes simultaneously.

GpuMmu model

In the GpuMmu model, the video memory manager manages the GPU memory management unit and underlying page tables, and exposes services to the user mode driver that allow it to manage GPU virtual address mapping to allocations.


IoMmu model

In the IoMmu model, the CPU and GPU share a common address space and page tables.

For more information, see IoMmu model.

https://msdn.microsoft.com/en-us/librar ... 85%29.aspx





.
Nvidia estaria sacando su primer controlador con soporte a la API Vulkan en sus controladores GeForce 358.66


http://forums.laptopvideo2go.com/topic/ ... a-support/
https://www.phoronix.com/scan.php?page= ... ng-Release

Michael Larabel, phoronix.com escribió:NVIDIA is readying their Vulkan drivers for a same-day release and on the Windows side they've already begun exposing some of the Vulkan interface.

NVIDIA's 358.66 driver for Windows adds a few OpenGL runtime changes referencing VK (Vulkan) and there's a new nv-vk32 library that exposes a number of Vulkan functions. Beyond that, this driver sets new runtime capabilities in OpenCL for the forthcoming Pascal and Volta GPUs.



Uy, y a saber hasta cuando AMD sacara controladores que soporten Vulkan para windows/linux.

.
TRASTARO escribió:Uy, y a saber hasta cuando AMD sacara controladores que soporten Vulkan para windows/linux.

Buf, en linux ni siquiera han actualizado para el kernel 4.2 (que salió hace meses).
383 respuestas
1, 2, 3, 4, 58