Can we put the DX11 to rest, are we going to see DCL's added or not?
1) Because DCLs are useless. They've been inappropriately positioned as a panacea for DX11's modest multi-threading capabilities, but most journalists and users exploring the topic are not familiar with why DCLs are so broken or limited.
Me encanta como AMD_Robert muestra esa neutralidad al hablar de las command lists de DX11, diciendo que son una mierda rota cuando nvidia desde antes de optimizar su driver para DX11 (multihilo "forzado" en gestión de drawcalls, por decirlo de una forma rápida, más reducción de tiempo por drawcall), ya las ejecutaba correctamente.
AMD las ejecutaba mal hace muchos años (desarrollo de BF3, donde DICE y Johansson que ya paseaba por las conferencias de AMD, ya venían con el cuento de que no funcionaban bien.... olvidándose decir que sólo en AMD), las ejecutaba mal hace pocos, y sigue ejecutando MAL una función de DX11 que, gracias a ellos, la gran mayoría de desarrolladores evitan porque no hay forma de que funcionen como deben en gpus AMD (siempre se pierde rendimiento).
Me encanta que tire así balones fuera sobre un punto crítico de su driver DX11 y el soporte de esta API, cuando el rival en el mercado lleva demostrando desde hace tantos años que sí se pueden usar las command lists y además con claro beneficio de rendimiento. Es que no sé cómo se le puede echar tanto morro a una cuestión de soporte del API principal de varias generaciones de tus gpus, y de una característica troncal. Las "modestas" capacidades de multihilo de la que habla Roberts se transforman en NULAS gracias a ese mal soporte de las DCLs.
Si se quiere llevar el mérito de transformar un API básicamente monohilo con pocas capacidades multihilo, en una puramente monohilo, felicidades.
Muy mala excusa el decir que está "rota" esta funcionalidad o es muy limitada. Si es limitada, no es tu problema, sopórtala como lo hace el rival como mínimo, y punto.
Fuera de esto, no estoy viendo ni un sólo dato técnico de las gpus, y cada vez que se intenta sacar algo concreto, salta el "no puedo comentarlo". Vamos bien.
PD:
5) 8-16x tessellation factor is a practical value for detail vs. speed, and this is what our hardware and software is designed around. Higher tessellation factors produce triangles smaller than a pixel, and you're turfing performance for no appreciable gain in visual fidelity.
Bueno carallo. Ahora Roberts de AMD me acaba de descubrir que la teselación es dependiente de la resolución y que no tiene sentido usar factores altos porque se tesela "por debajo del pixel".
Este señor ha llevado la pirueta que se usaba en las primeras gpus DX11 de AMD, las 5xxx, donde se decía que "no tenía sentido teselar por encima de 8x porque se creaban triángulos de menos de 16 píxeles", al ridículo. Como si el factor de teselación fuera unido sí o sí al tamaño final del triángulo (dependerá del POV y distancia al objeto, resolución de la pantalla, etc).
Para que se deje de tonterías, le recomendaría una prueba rápida y simple, que se baje Tessmark 4 y pase la prueba con los distintos niveles de teselación (8x, 16x, 32x, 64x), a ver si después dice que no hay diferencias o se tesela ya desde 32x con triángulos de tamaño subpixel.
Ya dejo de leer porque, entre cero explicaciones del hard, y cosas así, no me renta para nada. Menos propaganda y justificaciones, y más seriedad. Que le pregunten qué mejoras hay en la teselación de Polaris no es excusa para meter una cuña de propaganda e intentar vender que teselar en bajos factores es lo "ideal". Pero bueno, otra excusa al estilo de las command lists de DX11, no van a hacer nada con ellas porque "están rotas", "no funcionan" o "mi perro se ha comido mis deberes".