Polyteres escribió:Horizonte de sucesos escribió:Hasta que un día un buen hombre de la zona te dice que ratón y mariposa son el nombre de dos peces locales muy utilizados en la isla y que solo se cría en esos arrecifes. Y "Mi bicicleta por el aire" el nombre de la barca.
Entonces es cuando te das cuenta de que algo a lo que no le encontrabas sentido alguno adquiere un significado coherente y real.
Depende de la info que uno tiene, verá de una manera u otra las cosas.
Buenas gente.![[carcajad]](/images/smilies/nuevos/risa_ani2.gif "carcajada")
. Era un símil, elige el mas absurdo q puedas imaginar y aplícalo aquí.
Hay dos cosas q me sorprenden y no me gustan mucho. La primera es q cuando me paso por el hilo y escribo un par de mensajes siempre se forma un follón importante, salen 2 bandos, la gente se pelea...y q quereis que os diga, no me gusta nada. Es un hobby y hay q tomarlo como es.
Y la segunda es q parece q la mayoría de la gente q hay por aquí piensa q pq un hardware, el q sea me da igual, sea peor que otro todo lo q saque tenga q ser discreto gráficamente, o q no vaya a tener juegos realmente espectaculares.
Hace tiempo q os deberíais haber olvidado del hardware, y deberíais haber empezado a "preocuparos" por el software, los juegos. El problema está en el tejado de los desarrolladores, a ellos les corresponde lidiar con el hardware q hay y sacarle el mayor provecho.
Paz y amor y la consola pal salon.
Un saludo.
![[angelito]](/images/smilies/nuevos/angelito.gif "angelito")
Polyteres escribió:papatuelo escribió:El foro está para eso, si no dice nada coherente explica por qué, eres libre de hacerlo. De hecho te lo agradeceríamos.
Buenas gente. @Horizonte de sucesos y @Forzimbras claro q tenía pensado comentar las cosillas que se dicen en ese mensaje pero a mi tb me gusta el fútbol![[360º]](/images/smilies/nuevos/vueltas.gif "como la niña del exorcista")
MEGATOCHO inside:Con respecto al tema en sí. Pq no dice nada coherente?. Para empezar pq muchas de las cosas no tienen sentido ni siquiera a nivel léxico. En algunas ocasiones he tenido que leer varias veces alguna frase pq no tenía ni idea a lo que se estaba refiriendo, por la mezcla de conceptos... es como si leyeras una traducción de Google. Me da la sensación que se limita a traducir lo que dice mixstermedia. Y ya entrando en materia hay cosas mezcladas, cosas sacadas de la manga, otras que son un disparate...
Por ejemplo:No sirve de nada extrapolar arquitectura actual con la de nuevo paradigma, evidentemente por un lado se requiere una optimización de ops/c pero eso es parte del actual GCN 1.0, son técnicas que se usan en C++ desde hace años y la optimización de microcódigo en GCN y a través de DX11.2 viene de ahí.
No deja de ser una mejora de la drawcall que aprovecha la optimización del CU dedicado a GPGPU en base a conceptos FPU.
En todo caso sería: no deja de ser una mejora en los drawcall que aprovechan la optimización de las CUs dedicadas a GPGPU en base a conceptos FPU. Pero es q esto...FPU (flotating point unit), en base a conceptos de FPU??? CUs dedicadas a GPGPU exclusivamente?.12CU simples no son capaces de paralelizar nada sólo con optimización de ops.
16 rops modificados = 64 rops antiguos
Las ROPs son ROPs, no han cambiado mucho a lo largo de los años pq no hay mucho que cambiar. Es funcionalidad fija dentro de una GPU y tienen un trabajo muy específico que no varía de una generación a otra. Esto está ya muy trillado y no hay practicamente ningún margen de mejora. Les llegan fragmentos de los fragment/pixels shaders, Z Cull, resuelven las transparencias, resuelven el AA y escriben el pixel resultante en su caché o lo envían a traves de su controlador de memoria a donde corresponda. La cantidad de pixeles que son capaces de escribir por segundo es siempre el mismo: numero de ROPs x frecuencia, eso no cambia nunca. No hay cambios revolucionarios entre saltos generacionales pq todo está mas o menos inventado.
Las ROPs suelen ser un factor limitante y se están buscando formas de no usarlas (por ejemplo usando un compute shaders que escribe directamente en memoria y no usa las ROPs), siempre es preferible que te sobren y estés limitado por el ancho de banda que te falten y estés limitado por ROPs (tendrías que bajar la resolución del buffer por ejemplo).1 F32 ACE = 32 ACE antiguo
Esto se lo saca directamente de la manga pq el lo vale.tratamiento por bloque del GPU
X1 son 4 bloques: 2 Gfx + 2 COmpute (en esquema. 2azul 2morado)
PS4 es 1 bloque (1 Gfx + 8 ACE)
No. Otra cosa sin sentido. Bloques, que bloques?. XboxOne no es la única q tiene 2 Command Graphics, Ps4 tb tiene 2 (no solo 1 como dice, uno de ellos es capaz de despachar solo gráficos, y el otro tanto gráficos como GPGPU), de distinta prioridad, pero como dije en su momento hace ya tiempo, uno de ellos se usa para el juego en si y el otro para el SO.Los ACE de XBox One no están en ACE's, es por eso que se le llaman "Compute CP" Haríais bien de mirar las diapositivas de Mike Mantor o la diapositiva "negra" que colgue yo de Bryan, para entender el concepto.
La nueva ACE está seleccionada en base al tratamiento del mapa HSA, hay que ver como el tratamiento del CU está dispuesto ahí puesto que la comunicación está dispuesta a través del thread, y no como parte grande del pool del CU, lo cual encaja con la visión e interpretación del hardware nativo DX12 a partir de las r9 300 y su encapsulado de datos.
Cada paquete de datos encapsulado son controlados por 1 hilo del CPU y el hilo de computo de XBox One para el CPU tal y como hemos dicho en otros post alcanza los 6 ops per core y puesto que son 8 Cores "modificados" AMD Jaguar x86-64, en 2 clusters de 4 cores con modificaciones en/y/hacia la memoria compartida y el ancho de banda, alcanzan 48 ops/c en total, 24 por hilo, 24 por cluster.
Entonces es sencillísimo extrapolar y estimar que el numero de CU eficiente es de al menos 24CU por cada unidad de Compute CP del CPU, 24 threads per Compute.
Todo esto es q directamente no es posible. Está mezclando cosas de hardware y software, no sabe como funciona a nivel interno una GPU, ni una API de alto nivel, ni un driver. Las cosas no funcionan así. La CPU escribe comandos en un command buffer, estos se le pasan a la GPU y los ejecuta como una niña/o bueno. Que uno o varios núcleos puedan escribir sus propios command buffer y enviarselos a la GPU como pretende DirectX12 por ejemplo (o hacen actualmente otras APIs ya) es una cosa y otra es q tu manejes las CUs con cada hebra de tu CPU, esto es un disparate y no es ni posible ni viable ni lógico. La GPU es un procesador altamente pararelo y necesita de mecanismos específicos para manejar dicho paralelismo, no te los puedes saltar pq es hardware y son necesarios para funcionar.
Por otra parte los núcleos Jaguar de la CPU son capaces de retirar como máximo 2 instrucciones por ciclo, si tienes 8 núcleos tienes 16 instrucciones como máximo por ciclo. Cambiar el número de instrucciones que retiras por ciclo o IPC es jodidamente difícil y viene determinado por la arquitectura en sí de la CPU. Si es Jaguar, q lo es, retira 2 por ciclo no hay más.No es solo optimizar las colas, no es solo optimizar el entendimiento per CU, no es tan sencillo y simple, XBox One tiene duplicados los CU, pero no toda la piscina, sólo dobla las áreas referentes al GPGPU y dejan la forma de calcular actualmente los cálculos de propósito general de lado y los ACE en XBox One ya no son ACE's propiamente dichos. Y es por eso por lo cual se necesitan 768 ALU's*2 y es por eso que MS sólo menciona 768 ALU's
XboxOne no tiene duplicadas las CU ni tiene el doble de ALUs divididas en gráficos y GPGPU primero pq la familia es Sea Island (dicho por ellos) y segundo pq no es una solución correcta. La tendencia es dar cada vez mas flexibilidad a las CUs y para ello tienes q hacerlas cada vez mas generales. Que pasa si mi juego, o yo como desarrollador no quiero usar GPGPU?. O quiero usar toda la potencia de la GPU para procesar gráficos?. Desperdiciar espacio en unas ALUs que no tengan acceso al pipeline gráfico o q no se puedan usar para procesar gráficos es una tontería. Dame una ALU/CU q yo decida para q la quiero usar. Es mejor tener 12 CUs q yo decida balancear y usar como me plazca q estar limitado por una división 6+6 pq de esa forma solo podré usar 6 CUs para hacer gráficos. Es similar a lo q vimos con los shader unificados o los específicos q tenian Xbox360 y Ps3 respectivamente.El GPGPU en XBox One es nativo DX12, paraleliza todos los CU
El GPGPU en PS4 es a través de solo 4CU dedicados fortalecidos por ACE's extra
X1 12GFX 12GPGPU se beneficia de la optimización por microcódigo sensible a nivel de hardware
PS4 14GFX 4GPGPU se beneficiará de cierta optimización por microcódigo sensible a nivel de software
Los CUs se "parelelizan" solitos. Pocos kernels en CUDA, compute shaders o kernels en OpenCL ha escrito este hombre. El resto no tiene sentido.
Un saludo.
![[buenazo]](/images/smilies/nuevos/risa_tonta.gif "buenazo")
, pq ya tendría para dias y dias de lectura y entretenimiento xD. Polyteres escribió:f5inet escribió:Deberias tener cuidado con lo que escribes, porque tienes cierto prestigio en este foro y textos como el que acabas de exponer te desautorizan completamente. Las GPUs dejaron de tener pipeline fijo desde la epoca de pixel y vertex Shaders, o para afinar mas, desde DirectX 8 y Windows XP (que ya ha llovido, epoca de la Geforce3 y Radeon 8500). De hecho, el driver/controlador de esas GPUs 'autocargan' un shader generico que EMULA el pipeline fijo que historicamente tenian dichas GPUs. es cuando el programador desea aplicar un efecto distinto al programado por el pipeline por defecto, cuando cargan el shader.
Como tu bien apuntas, las primeras tarjetas con shaders programables ERAN MAS LENTAS que sus homologas de pipeline fijo, ya que no es lo mismo ejecutar un programa, que tener el programa 'incrustado' en el silicio con microcodigo. Esto se acentuo aun mas con los shaders totalmente programables, como las tarjetas compatibles con DirectX10 (nVIdia Geforce 8000 y ATI HD2000), pero los shaders unificados permitian usar mas recursos del CU para transformaciones de pixeles o para transformaciones de vertices, permitiendo shaders aun mas flexibles.
Por supuesto, en toda esta carrera por pintar mas y mas pixeles de mundos 3D en pantalla, necesitaron memorias cada vez con mayor ancho de banda, capaz de cargar rapidamente en los CUs los shaders a ejecutar, leer los inputs, y sacar los resultados a VRAM. en esto, se empezaron a dar cuenta que, si escribian los datos a la VRAM tal como eran escupidos por el shader, la latencia de la VRAM mataba el rendimiento del shader. Asi que una optimizacion rapida era meter una memoria local al CU donde almacenar los datos, y que el ROP se encargara de volcar dichos datos a la VRAM. antiguamente, cada CU tenia su propio ROP. Luego, se dieron cuenta que mientras la CU esta computando el shader, el ROP esta ocioso, asi que en lugar de dedicar silicio a 1 ROP por cada 1CU, decidieron poner menos ROPs que CUs, y con el silicio que se ahorraban metian 1 o 2 CUs adicionales. Todo era felicidad y amor en aquella epoca: mientras mas CUs tuviese tu GPU, tus shaders podian ser mas complejos y la escena resultante podia ser mas bonita, y mientras mas ROPs tuviese tu GPU, mayor podia ser la resolucion.
Pero no olvidemos lo principal: los ROPs fueron UN PARCHE para enmascarar la altisima latencia de la VRAM. una VRAM con un ancho de banda bestial, a costa de una latencia altisima. La solucion ideal hubiese sido un enorme ancho de banda con una latencia bajisima, pero eso no existia en ese momento...
Hasta que llegaron los 32 nanometros, y los procesadores Intel SandyBridge con algunos i7 con 15MB de cache L3 dentro del DIE. Oh amigo... la memoria incrustada de altisimo ancho de banda y bajisima latencia ESTABA AQUI.
¿Y sabes que dejo de ser necesario? Los ROPs...
Buenas gente. Dudo que me desautoricen puesto q no he dicho ninguna barbaridad:
http://msdn.microsoft.com/en-us/library ... 0;v=vs.85).aspx
Un pipeline es una "tubería" dividida en etapas. En un pipeline gráfico actual hay etapas programables y otras no programables, pero este pipeline es fijo, es decir hay que seguir un orden en el procesamiento de los datos. Los datos entran por un extremo, se procesan en un orden determinado y acaban saliendo los resultados por el otro extremo. En el caso de un pipeline gráfico, los datos de entrada son los atributos de los vértices y los triángulos, y la salida es un pixel con sus atributos propios.
Tener un pipeline fijo no significa que este no sea programable, al menos parcialmente. Aún así dentro del pipeline gráfico hay etapas programables (vertex shader, geometry shader, hull shader, domain shader, pixel shader) y otras que no lo son, son fijas inmutables y el programador no puede hacer nada pq so fijas, aún a día de hoy (el procesado de geometría/input assembler, la rasterización, el ZCull, Zbuffer, tesselator stage, todo lo que tiene que ver con las ROPs...).
Te has confundido con los shaders programables, no tiene nada que ver con lo que yo había dicho.
Las ROPs no fueron un parche para nada, ni mucho menos. Las ROPs llevan en las GPUs desde el principio, de hecho las primeras tarjetas no eran mas que simples rasterizadores. Las ROPs hacen muchas mas funciones que solo escribir datos en memoria, las transparencias por ejemplo se hacen aquí, el MSAA tb... Quítale ROPs a una GPU y verás como sufre a la hora de trabajar con transparencias, o verás como sufre tu GPU para renderizar una sombra xD.
La optimización más lógica y barata para evitar una latencia, y la usada por los diseñadores, es usar cachés dentro de las ROPs (en este caso dos distintas una para el color y otra para el valor z). De hecho, si profundizamos un poco más... habría formas de renderizar ciertos elementos (partículas por ejemplo) de forma que optimices la caches de las ROPs pero esto es profundizar mucho mucho mas y no viene a cuento.Si el propio Shader YA PUEDE ESCRIBIR el resultado de su computacion en la memoria incrustada sin penalizaciones, e incluso mas rapido que si delega ese trabajo a un ROP, dediquemos el silicio que tiene asignado esos ROPs a otra cosa, como... no se... ¿un controlador de memoria adicional que permita movimientos de datos dentro y fuera del micro, y los llamamos DME? hecho. ¿Metemos una tarjeta de sonido decente dentro y nos ahorramos comermos core y medio como en la epoca de la X360? me parece buena idea. ¿pero no seria buena idea dejar algun ROP, ya sabes... 'por si acaso'? si, dejemos alguno, seguro que alguien querra seguir programando a la antigua usanza, dejadle los justitos para que los ports de DX11 vayan a 720p, pero para DX12 ya sabeis, pasamos de ROPs y vamos a sacarle todo el jugo a este silicio...
Si quieres saltarte las ROPs debes usar un Compute Shader. Si usas un compute shader no tienes acceso al pipeline fijo de la GPU (las etapas no programables de las que hablaba antes, por lo que por ejemplo tendrás que rasterizar de forma manual...), las cuales hacen un trabajo muy específico y de forma muy eficiente. Si te quitas esto y no lo usas tendrás que hacerlo todo tu (la cosa se empieza a complicar), por lo que quemarás muchos ciclos en esto. A parte tendrás que hilar muy fino en el compute shader para usar bien las memorias compartidas entre las CUs, las caches, y la memoria LDS y sobre todo empezar a usar barreras a punta pala para que la cosa te vaya medio en condiciones...si es q lo consigues.
A dia de hoy tener un rasterizador completo en un Compute Shader es inviable. Lo máximo q se ha llegado, de forma comercial, es ha implementar un Zbuffer a una resolución muy baja para realizar culling (Frostbite Engine).
Si tienes unos shaders "sencillos" puede que llegues a estar limitado por el número de ROPs. Que se considera un shader sencillo?. Todos aquellos q tengan pocas instrucciones, como por ejemplo los efectos de post procesado, o incluso la composición de la iluminación de un deferred rendering. De este tipo de operaciones si se beneficia el puentear las ROPs y por eso los efectos de postprocesado se programan con un Compute Shader...lo q he dicho antes.
Las ROPs no son unidades demasiado grandes como para tener que quitarlas para ahorrar espacio. El número de ROPs va muy de la mano del número de CUs que tengas, y del número de controladores de memoria y el ancho del bus de la memoria.
Un saludo.
f5inet escribió:Polyteres escribió:f5inet escribió:Deberias tener cuidado con lo que escribes, porque tienes cierto prestigio en este foro y textos como el que acabas de exponer te desautorizan completamente. Las GPUs dejaron de tener pipeline fijo desde la epoca de pixel y vertex Shaders, o para afinar mas, desde DirectX 8 y Windows XP (que ya ha llovido, epoca de la Geforce3 y Radeon 8500). De hecho, el driver/controlador de esas GPUs 'autocargan' un shader generico que EMULA el pipeline fijo que historicamente tenian dichas GPUs. es cuando el programador desea aplicar un efecto distinto al programado por el pipeline por defecto, cuando cargan el shader.
Como tu bien apuntas, las primeras tarjetas con shaders programables ERAN MAS LENTAS que sus homologas de pipeline fijo, ya que no es lo mismo ejecutar un programa, que tener el programa 'incrustado' en el silicio con microcodigo. Esto se acentuo aun mas con los shaders totalmente programables, como las tarjetas compatibles con DirectX10 (nVIdia Geforce 8000 y ATI HD2000), pero los shaders unificados permitian usar mas recursos del CU para transformaciones de pixeles o para transformaciones de vertices, permitiendo shaders aun mas flexibles.
Por supuesto, en toda esta carrera por pintar mas y mas pixeles de mundos 3D en pantalla, necesitaron memorias cada vez con mayor ancho de banda, capaz de cargar rapidamente en los CUs los shaders a ejecutar, leer los inputs, y sacar los resultados a VRAM. en esto, se empezaron a dar cuenta que, si escribian los datos a la VRAM tal como eran escupidos por el shader, la latencia de la VRAM mataba el rendimiento del shader. Asi que una optimizacion rapida era meter una memoria local al CU donde almacenar los datos, y que el ROP se encargara de volcar dichos datos a la VRAM. antiguamente, cada CU tenia su propio ROP. Luego, se dieron cuenta que mientras la CU esta computando el shader, el ROP esta ocioso, asi que en lugar de dedicar silicio a 1 ROP por cada 1CU, decidieron poner menos ROPs que CUs, y con el silicio que se ahorraban metian 1 o 2 CUs adicionales. Todo era felicidad y amor en aquella epoca: mientras mas CUs tuviese tu GPU, tus shaders podian ser mas complejos y la escena resultante podia ser mas bonita, y mientras mas ROPs tuviese tu GPU, mayor podia ser la resolucion.
Pero no olvidemos lo principal: los ROPs fueron UN PARCHE para enmascarar la altisima latencia de la VRAM. una VRAM con un ancho de banda bestial, a costa de una latencia altisima. La solucion ideal hubiese sido un enorme ancho de banda con una latencia bajisima, pero eso no existia en ese momento...
Hasta que llegaron los 32 nanometros, y los procesadores Intel SandyBridge con algunos i7 con 15MB de cache L3 dentro del DIE. Oh amigo... la memoria incrustada de altisimo ancho de banda y bajisima latencia ESTABA AQUI.
¿Y sabes que dejo de ser necesario? Los ROPs...
Buenas gente. Dudo que me desautoricen puesto q no he dicho ninguna barbaridad:
http://msdn.microsoft.com/en-us/library ... 0;v=vs.85).aspx
Un pipeline es una "tubería" dividida en etapas. En un pipeline gráfico actual hay etapas programables y otras no programables, pero este pipeline es fijo, es decir hay que seguir un orden en el procesamiento de los datos. Los datos entran por un extremo, se procesan en un orden determinado y acaban saliendo los resultados por el otro extremo. En el caso de un pipeline gráfico, los datos de entrada son los atributos de los vértices y los triángulos, y la salida es un pixel con sus atributos propios.
Tener un pipeline fijo no significa que este no sea programable, al menos parcialmente. Aún así dentro del pipeline gráfico hay etapas programables (vertex shader, geometry shader, hull shader, domain shader, pixel shader) y otras que no lo son, son fijas inmutables y el programador no puede hacer nada pq so fijas, aún a día de hoy (el procesado de geometría/input assembler, la rasterización, el ZCull, Zbuffer, tesselator stage, todo lo que tiene que ver con las ROPs...).
Te has confundido con los shaders programables, no tiene nada que ver con lo que yo había dicho.
Las ROPs no fueron un parche para nada, ni mucho menos. Las ROPs llevan en las GPUs desde el principio, de hecho las primeras tarjetas no eran mas que simples rasterizadores. Las ROPs hacen muchas mas funciones que solo escribir datos en memoria, las transparencias por ejemplo se hacen aquí, el MSAA tb... Quítale ROPs a una GPU y verás como sufre a la hora de trabajar con transparencias, o verás como sufre tu GPU para renderizar una sombra xD.
La optimización más lógica y barata para evitar una latencia, y la usada por los diseñadores, es usar cachés dentro de las ROPs (en este caso dos distintas una para el color y otra para el valor z). De hecho, si profundizamos un poco más... habría formas de renderizar ciertos elementos (partículas por ejemplo) de forma que optimices la caches de las ROPs pero esto es profundizar mucho mucho mas y no viene a cuento.Si el propio Shader YA PUEDE ESCRIBIR el resultado de su computacion en la memoria incrustada sin penalizaciones, e incluso mas rapido que si delega ese trabajo a un ROP, dediquemos el silicio que tiene asignado esos ROPs a otra cosa, como... no se... ¿un controlador de memoria adicional que permita movimientos de datos dentro y fuera del micro, y los llamamos DME? hecho. ¿Metemos una tarjeta de sonido decente dentro y nos ahorramos comermos core y medio como en la epoca de la X360? me parece buena idea. ¿pero no seria buena idea dejar algun ROP, ya sabes... 'por si acaso'? si, dejemos alguno, seguro que alguien querra seguir programando a la antigua usanza, dejadle los justitos para que los ports de DX11 vayan a 720p, pero para DX12 ya sabeis, pasamos de ROPs y vamos a sacarle todo el jugo a este silicio...
Si quieres saltarte las ROPs debes usar un Compute Shader. Si usas un compute shader no tienes acceso al pipeline fijo de la GPU (las etapas no programables de las que hablaba antes, por lo que por ejemplo tendrás que rasterizar de forma manual...), las cuales hacen un trabajo muy específico y de forma muy eficiente. Si te quitas esto y no lo usas tendrás que hacerlo todo tu (la cosa se empieza a complicar), por lo que quemarás muchos ciclos en esto. A parte tendrás que hilar muy fino en el compute shader para usar bien las memorias compartidas entre las CUs, las caches, y la memoria LDS y sobre todo empezar a usar barreras a punta pala para que la cosa te vaya medio en condiciones...si es q lo consigues.
A dia de hoy tener un rasterizador completo en un Compute Shader es inviable. Lo máximo q se ha llegado, de forma comercial, es ha implementar un Zbuffer a una resolución muy baja para realizar culling (Frostbite Engine).
Si tienes unos shaders "sencillos" puede que llegues a estar limitado por el número de ROPs. Que se considera un shader sencillo?. Todos aquellos q tengan pocas instrucciones, como por ejemplo los efectos de post procesado, o incluso la composición de la iluminación de un deferred rendering. De este tipo de operaciones si se beneficia el puentear las ROPs y por eso los efectos de postprocesado se programan con un Compute Shader...lo q he dicho antes.
Las ROPs no son unidades demasiado grandes como para tener que quitarlas para ahorrar espacio. El número de ROPs va muy de la mano del número de CUs que tengas, y del número de controladores de memoria y el ancho del bus de la memoria.
Un saludo.
Me gusta ese razonamiento. Estoy de acuerdo con algunas cosas, pero no con otras, y veo inutil intentar defender mi postura porque veo que tienes la tuya muy definida y no te veo por la labor de cambiar tu argumentario. No importa, puedo vivir con eso. al fin y al cabo, creo que nuestra diferencia principal es semantica, y tu entiendes como 'shader' cosas que yo no entiendo como tales.
Pero si hemos llegado a una conclusion. hemos coincidido que en GPUs antiguas, si cambiabas el shader 'por defecto' para cargar el tuyo propio, el rendimiento de la GPU tendia a caer en picado porque tenia que calcular cosas para las cuales no estaba 'microprogramada'. Bien. Esto se acabo con la generacion GCN de AMD. Oye, pero no hace falta que lo diga yo, supongo que una slide de la GamesDevelopersConference de 2014 tendra mas autoridad:
supongo que el 'bypass ROPs with compute shaders' habla por si mismo...
pero puesto que el slide no tiene autor, y podeis argumentar que ese tipo es un tontolaba, unos slides de ¡2009! de EpicGames tendran mas autoridad aun...
http://graphics.cs.williams.edu/archive ... PG2009.pdf
del cual, los slides 25 y 27 son PODEROSAMENTE llamativos:
echaros un vistazo tambien al slide 34 (Future Graphics: Software Tiled Rendering)
Y no tengo nada mas que objetar, señoria!!!
f5inet escribió:Me gusta ese razonamiento. Estoy de acuerdo con algunas cosas, pero no con otras, y veo inutil intentar defender mi postura porque veo que tienes la tuya muy definida y no te veo por la labor de cambiar tu argumentario. No importa, puedo vivir con eso. al fin y al cabo, creo que nuestra diferencia principal es semantica, y tu entiendes como 'shader' cosas que yo no entiendo como tales.
Pero si hemos llegado a una conclusion. hemos coincidido que en GPUs antiguas, si cambiabas el shader 'por defecto' para cargar el tuyo propio, el rendimiento de la GPU tendia a caer en picado porque tenia que calcular cosas para las cuales no estaba 'microprogramada'. Bien. Esto se acabo con la generacion GCN de AMD. Oye, pero no hace falta que lo diga yo, supongo que una slide de la GamesDevelopersConference de 2014 tendra mas autoridad:
supongo que el 'bypass ROPs with compute shaders' habla por si mismo...
pero puesto que el slide no tiene autor, y podeis argumentar que ese tipo es un tontolaba, unos slides de ¡2009! de EpicGames tendran mas autoridad aun...
http://graphics.cs.williams.edu/archive ... PG2009.pdf
del cual, los slides 25 y 27 son PODEROSAMENTE llamativos:
echaros un vistazo tambien al slide 34 (Future Graphics: Software Tiled Rendering)
Y no tengo nada mas que objetar, señoria!!!
darksch escribió:Si tengo que dar mi opinión de lo que vengo leyendo, me parece que el "fallo" de Polyteres es que sólo considera el caso actual que él mismo conoce, es decir a lo que él mismo usa (que será seguramente PC).
![[sonrisa]](/images/smilies/nuevos/risa_ani1.gif "sonrisa")
Polyteres escribió:[...]El slice que has puesto, si tiene autor. Es Emil Persson, jefe de i+D de Avalanche Studios. Antes hiciste referencia a él, es el famoso Humus3D. Lo q dice en ese papers es lo mismo que llevo yo repitiendo desde que empezó la conversación. Si tienes shaders que tienen muy pocas instrucciones es probable que satures las ROPs pq provocan un cuello de botella en el hardware (hay pocas y les llegan muchas peticiones de las CUs). Puedo saltarme las ROPs?. Si, usa un compute shader para escribir directamente en memoria pero...si uso un Compute Shader no podré tener acceso a ciertos elementos del pipeline gráfico que son vitales para mi. Ok...cuales son esos shaders con pocas instrucciones?. Los shaders de post procesado. Esos se adaptan bien a la estructura de un Compute Shader?. Sip, ok adelante.
Puedo implementar a día de hoy, con la potencia que tengo, un rasterizador software en la GPU mediante GPGPU?. No al menos al nivel que deseo.
[...]
de momento dejo una foto del die de una R9 290X, una tarjeta de la familia VolcanicIslands
Vaya... esa disposicion de los shaders me recuerda algo...
