Hablemos del interior de Xbox One

Polyteres escribió:
Horizonte de sucesos escribió:Hasta que una 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] [carcajad] [carcajad] [carcajad] [carcajad] [carcajad] [carcajad] o me lo tomo con humor, o me piro de EOL, no me queda otra [+risas] . 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.


La verdad es que lo mejor que puedes hacer es tomartelo con humor.

A mi lo que me jode son las pseudo informaciones que salen de parte de algunos iluminados. Yo si Microsoft me dice que xbox one soporta DX12 100% por hw me lo creo, y me parece cojonudo. Al igual que los avances de los que hablan los desarrolladores como el tema de aprovechar los multiples cores del procesador. Pero vamos, no pongais esa informacion al lado de las pajas mentales que salen por doquier por ahi (la mayoria sin pies ni cabeza).

Un saludo!
Pero vamos a ver. O sea que algunos son verdades absoluta y los demas iluminados por que algunos lo decis no ?.
Grinch escribió:Pero vamos a ver. O sea que algunos son verdades absoluta y los demas iluminados por que algunos lo decis no ?.


Para mi lo que diga Microsoft es una verdad absoluta, no se para ti.

Al igual que lo que dice mixtermedia (o como se llame), es mas humo que otra cosa.

Un saludo!
Forzimbras escribió:Recopilación y conclusiones de lo que se venía debatiendo hasta que se dinamitó el topic con gilipolleces e idas de pelota varias:

-¿DirectX 12 tiene compatibilidad con One?

-¿Es esa compatibilidad plena (100%)? También.

-¿Facilitará eso el porteo? Muchísimo (varios dev lo han corroborado en el mismo sentido).

-¿Están los componentes preparados para usar una versión completa de DX12? Sí, porque corrieron en desarrollos paralelos. El principal responsable de One, Boyd Multerer, ha hecho hincapié en que One se planificó pensando en la interacción de desarrollos PC-One, por lo que no se hace para nada tedioso, una vez disponibles las herramientas que DX 12 proporciona.

-¿Están las gráficas actuales preparadas para usar DX12 de manera nativa, por hard? No.

-¿Está preparada la gráfica de One para usar DX12 de manera nativa por hard? Sí.

-¿Qué modelo usa entonces la gráfica de One? Es confidencial. Pero sí puede decirse que uno muy personalizado y vanguardista.

A lo que yo añadiría al debate:

-¿Puede estar influyendo en el rendimiento de los juegos actuales el hecho de que One esté tirando de desarrollos con una versión provisional de DX11? Y respondería que casi con toda probabilidad.

A ello le sumaría también el que a causa de DX11, solo 1 de las 8 CU's esté haciendo de "main" tirando de las demás, en lugar de lo que va a ocurrir en cuanto acoja DX12, momento en que las 8 podrán manejar procesamiento de manera simultánea, sin depender una de la otra ni tirar de las demás
.



Esto es lo que por ahora sabemos y esta confirmado.
Es que a misterxmedia nunca se le ha dado credibilidad ni relevancia a efectos oficiales desde MS, no se por qué se sigue sacando lo que dice. Sus entradas son carne de polémica en foros, pero de ahí no pasa. No sería la primera vez que Albert Penello ha hablado con él personalmente y le ha dicho que deje de soltar paridas, aparte de tener que salir alguna que otra vez a desmentir lo que el otro afirma que es cuando le ha dado por publicar alguna burrada.

Misterxmedia es un geek o techie jugando a ser insider. Pero a saber qué fuentes tiene, porque no da una. Lo mismo sus fuentes sobre la One son de Apple o de Google y así salen. A saber...
El hombre sólo hace suposiciones. Creo que has sido tú mismo, Forzimbras, el que ha comentado antes que Microsoft no va a anunciar a los 4 vientos todo la tecnología que esté dentro de los chips que diseña (sólo lo que la ley obliga). Dejando de lado que esto era obvio, también impide que la gente tenga ni pajolera idea de lo que hay, así que sólo puede ir presentando teorías hasta que da con la buena. ¿Qué se monta pajas mentales? Por supuesto. Sólo faltaría. No hay más que mirar atrás y ver la cantidad de pajas mentales que se ha montado el ser humano hasta encontrar la respuesta adecuada (la tierra es el centro de todo, es plana, llueve porque dios lo quiere, el pelo crece más fuerte si te lo cortas, no dejas embarazada a una mujer según el alimento que comas, etc).
framed escribió:El hombre sólo hace suposiciones. Creo que has sido tú mismo, Forzimbras, el que ha comentado antes que Microsoft no va a anunciar a los 4 vientos todo la tecnología que esté dentro de los chips que diseña (sólo lo que la ley obliga). Dejando de lado que esto era obvio, también impide que la gente tenga ni pajolera idea de lo que hay, así que sólo puede ir presentando teorías hasta que da con la buena. ¿Qué se monta pajas mentales? Por supuesto. Sólo faltaría. No hay más que mirar atrás y ver la cantidad de pajas mentales que se ha montado el ser humano hasta encontrar la respuesta adecuada (la tierra es el centro de todo, es plana, llueve porque dios lo quiere, el pelo crece más fuerte si te lo cortas, no dejas embarazada a una mujer según el alimento que comas, etc).


Pero aqui ya entra en juego la paja mental que uno se puede hacer fundamentada en algo, o simplemente lanzar nombres tecnicos entremezclados con palabras biensonantes para que parezca algo mas. Pero claro, cuando eso lo lee alguien que sabe un poco del tema se da cuenta enseguida de lo que pasa.

Un saludo!
Pero no voy a las teorías que haga o deje de hacer. Teorías ya hacen en este hilo mismo (sin atinar en lo más mínimo, todo sea dicho) y no son misterxmedia. Lo que comentaba es que misterxmedia muy frecuentemente publica lo que el llama "información de sus insiders" que nunca dice ni siquiera si son de MS o no. Información como lo de la dGPU y demás movidas rocambolescas de las tantas que ha llegado a publicar. Y el siempre recurre a que todas esas specs que da son "filtraciones" de sus contactos, (en plan "mi insider me ha dicho esto", "mi insider me ha dicho aquello otro") filtraciones que pierdo ya incluso la cuenta de las veces que han sido desmentidas por MS, principalmente por mediación de Albert Penello.

Por eso pienso que a misterxmedia la importancia se la están dando quienes siempre lo traen a colación cuando se trata el tema de las specs, porque fiabilidad de lo que publica, tiene 0.
argam escribió:
framed escribió:El hombre sólo hace suposiciones. Creo que has sido tú mismo, Forzimbras, el que ha comentado antes que Microsoft no va a anunciar a los 4 vientos todo la tecnología que esté dentro de los chips que diseña (sólo lo que la ley obliga). Dejando de lado que esto era obvio, también impide que la gente tenga ni pajolera idea de lo que hay, así que sólo puede ir presentando teorías hasta que da con la buena. ¿Qué se monta pajas mentales? Por supuesto. Sólo faltaría. No hay más que mirar atrás y ver la cantidad de pajas mentales que se ha montado el ser humano hasta encontrar la respuesta adecuada (la tierra es el centro de todo, es plana, llueve porque dios lo quiere, el pelo crece más fuerte si te lo cortas, no dejas embarazada a una mujer según el alimento que comas, etc).


Pero aqui ya entra en juego la paja mental que uno se puede hacer fundamentada en algo, o simplemente lanzar nombres tecnicos entremezclados con palabras biensonantes para que parezca algo mas. Pero claro, cuando eso lo lee alguien que sabe un poco del tema se da cuenta enseguida de lo que pasa.

Un saludo!


Pero es que en todo momento y lo repito por enésima vez, os estáis pensando que solo politeres sabe del tema y que "el tio de 3djuegos" no tiene ni idea. Dais por hecho que polyteres le ha desmontada todas sus teorías y no es así. Solo hay que ver que ha pasado con los Rops.
Papatuelo que intentaba desmontar polyteres nombrando la cantidad de rops?,es que ya me e perdido con tanto tema hoy
chris76 escribió:Papatuelo que intentaba desmontar polyteres nombrando la cantidad de rops?,es que ya me e perdido con tanto tema hoy


Esto ha pasado con los ROPs, y a partir de aqui, no se ha sacado mas el tema...

f5inet escribió:y ahora es cuando llega f5inet y suelta que bajo el nuevo paradigma DX12 usar ROPs no es necesario ya que se saturan en nada, y que han descubierto que es mas rapido meter el rasterizador en el SHADER que se ejecuta en los CU...

pagina 5: http://www.humus.name/Articles/Persson_ ... rGames.pdf

Antiguamente se dejaba a los ROPs escribir los resultados del shader en la VRAM para que el codigo a ejecutar por el shader fuese mas corto. Hoy dia, con la posibilidad que dan las arquitecturas GCN de shaders larguisimos, pueden meter la escritura a la VRAM dentro del mismo shader.

antiguamente, con el ROP, el shader (o el CU, si asi lo preferiis) quedaba 'congelado' hasta que los resultados se hubiesen escrito en la VRAM. Esto se hacia asi porque la VRAM que se solia montar solia tener MUCHA LATENCIA. si se pueden meter las escrituras dentro del shader, porque hay espacio dentro del shader, y el acceso a la VRAM no esta penalizado por latencia (fijese usted que casualidad, que tenemos unos fastuosos 32MB de rapidisima memoria eSRAM), los ROPs son INNECESARIOS.

pero vamos, algunos seguiran diciendo que 32ROPs es mejor que 16ROPs, que 64 son mejores que 32, y que la memoria RAM-BUS es mejor que la actual DDR3...
Sí eso lo recuerdo,pero no encuentro ahora el "que" era imposible por los Rops [angelito]
Ahi lo tienes:
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º] [360º] ...

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í.


¬_¬ ¬_¬ ¬_¬ es q no se quiere decir [+risas] . Habla de compiladores?. De operaciones por ciclo?. Pq mete C++?. Las GPUs de la generación de Xbox360/Ps3 eran muy sensibles al como se ejecutaban las distintas tareas, como empaquetaras ciertos datos, como usaras el paso de varibles entre los shaders, cuando leer una textura para ocultar latencias... Pero todo eso ha quedado atrás, en la arquitectura GCN no es necesario ser tan "tiquismiquis" con las instrucciones debido a como están diseñadas (con arquitecturas anteriores de AMD por ejemplo basadas en VLIW el como y donde poner las instrucciones era VITAL). No obstante todo esto se hace a nivel de hardware y driver.

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.


¬_¬ ¬_¬ ¬_¬ ¬_¬ ¬_¬ . Solo con esa frase te das cuenta de que lo que dice no tiene ni pies ni cabeza. Que tiene que ver la optimización a nivel de operaciones con la paralelización de diferente granularidad???.

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


¬_¬ no se q quiere decir con esto.

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.
creo que intentaba ser ironico :P
Esto es un no parar....que ganas de que llegue el E3 y se plasme en juegos.
Ok gracias,sólo quería volver a leerlo,para nada estoy siendo irónico con nadie,además pienso que el que escribe por aquí con conocimientos es muy valiente de dar su opinión pública,sea del agrado del hilo o no,todos los puntos de vista son importantes
Llevo leyendo este hilo desde que se abrió, todos y cada uno de los post, todos y cada uno de los enlaces y he llegado a una conclusión...todos los que saben tienen preferencias y se nota...leo a uno ..pues tendrá razón...leo al otro y digo. .pues parece lógico lo que dice...y al final de todo he llegado a cosas comunes..
Que la gpu de la one se parece como un huevo a una castaña a la 77 no se que
Que direct x12 es muy muy importante.
Que la consola básicamente esta basada en la optimización y no en la potencia bruta.
De resto...no me enterado un carajo.
Entonces sino querias ser ironico te aconsejo usar el buscador . Ejemplo :

search.php?st=0&sk=t&sd=d&keywords=rops&t=1992540&sf=msgonly&ch=-1
Buenas gente. Con respecto al tema de las ROPs. Estaba respondiendo a lo que decía el mensaje que estábamos comentando sobre el 16 ROPs "nuevas" vs 64 ROPs antiguas.

Me autocito:

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).


Una cosa es eso, cosa que ya puntualizo en su momento y otra muy distinta prescindir de las ROPs. Ahora mismo con el hardware que hay (y en esto incluyo a XboxOne/Ps4 y PC y por bastante tiempo) es inviable implementar toda la funcionalidad fija de una GPU con trabajo GPGPU. Una GPU tiene un pipeline fijo, dividido en etapas por los que se tiene q pasar. Todo diseñado para ese fin, y de hecho lo hace de forma muy eficiente. Si usas por ejemplo un Compute Shader o un kernel de CUDA para implementar cualquier función no usas dicha funcionalidad fija y esto es un handicap. A parte de q hay ciertas funciones implementadas directamente en el hardware que se hacen de forma muy eficiente (el ZCull por ejemplo, la interpolación entre los distintos atributos, la rasterización...).

Dicho lo cual, y puesto q el número de ROPs siempre suele ser un factor limitante se están buscando ciertas formas de evitar este cuello de botella sobre aquellas operaciones que se presten a ello (que no todas), como por ejemplo la composición de la iluminación de un Deferred Rendering (Frostbite Engine) y efectos de post procesado.

Pero como digo esto es una cosa y otra decir que las ROPs son innecesarias.

Un saludo.
Sólo queda esperar, xq está claro que tu sabes de lo que hablas, pero creo que no sabes de lo que el habla.
papatuelo escribió:Sólo queda esperar, xq está claro que tu sabes de lo que hablas, pero creo que no sabes de lo que el habla.


Buenas gente. Si te refieres a @FlashBackMan360 dudo que ni siquiera el lo sepa.

Un saludo.
Bueno, no tengo xq desconfiar de ti, yo por desgracia soy un ignorante en esos temas y no puedo juzgaros.

El tiempo os dará la razón a uno de los dos.
De los tres . QU el ateoria de fin5t esta ahi tambien y siempre que le he leido explica las cosas muy bien y tiende a acertar u tener razon .
Yo creo que aquí la verdad es que tampoco veo a nadie seguro de lo que dice. Más que nada porque, tal y como me han recordado, en este mismo hilo se saltó en un comienzo del "Xbox One no será compatible con DX12", pasando por el (una vez se confirmó que si lo era) "Xbox seguro que solo es compatible con DX12 por emulación", al (una vez confirmado que la compatibilidad iba por hard) "ya veremos".

El caso es que siempre tiene que haber algún "pero" para no admitir completamente nada.
Forzimbras escribió:Yo creo que aquí la verdad es que tampoco veo a nadie seguro de lo que dice. Más que nada porque, tal y como me han recordado, en este mismo hilo se saltó en un comienzo del "Xbox One no será compatible con DX12", pasando por el (una vez se confirmó que si lo era) "Xbox seguro que solo es compatible con DX12 por emulación", al (una vez confirmado que la compatibilidad iba por hard) "ya veremos".

El caso es que siempre tiene que haber algún "pero" para no admitir completamente nada.


Buenas gente. Yo no he cambiado mi discurso. De hecho un año antes de que saliera XboxOne, donde todo eran especulaciones, y se empezaba a saber lo q iba a montar, ya intuí y así lo deje escrito, los problemas que podría tener XboxOne con esa arquitectura.

Un saludo.
f5inet, kinderRey y FlashBackMan360 hablan de cosas similares.
Polyteres escribió:
Forzimbras escribió:Yo creo que aquí la verdad es que tampoco veo a nadie seguro de lo que dice. Más que nada porque, tal y como me han recordado, en este mismo hilo se saltó en un comienzo del "Xbox One no será compatible con DX12", pasando por el (una vez se confirmó que si lo era) "Xbox seguro que solo es compatible con DX12 por emulación", al (una vez confirmado que la compatibilidad iba por hard) "ya veremos".

El caso es que siempre tiene que haber algún "pero" para no admitir completamente nada.


Buenas gente. Yo no he cambiado mi discurso.

Un saludo.


No lo digo por tí, Polyteres. Se que tú sabes que puede hacerlo perfectamente.
Que por cierto KinderRey ha hablado muchísimas veces de virtualización y por lo que voy entendiendo ese va a ser el nucleo de la cuestión, FlashBackMan360 añadió que desde cloud se podía virtualizar cualquier hardware xq lo que... dónde estarían los límites del hardware de la ONE? dónde estaría el famoso "el hardware es el que es"?
Sabeis el unico problema que se ve aqui,que las compañias hasta hace poco estaban trabajando con sdk mierderas y desde hace poco no,aqui radica el tema,ni la consola es una mierda como muchos pregonan y se lo creen ni tampoco es un pepino a dia de hoy,es decir ni tan poco ni tanto,a mi nadie me a convenzer de nada,por que ni me creo a este o al otro,aqui los unicos fiables son los que hicieron la consola,lo demas pajas mentales de aqui y alli y el tiempo dejare a cada uno en su sitio,eso si cansa la misma cantinela de la que la one lleva tal grafica que algunos pregonan por que es falso,pero que lo sigan diciendo que puede que dentro de unos años boommmm [buenazo]
Me da que no hara falta "dentro de UNOS años"
Menos de un año, no sé si será en el e3 o después. Pero de 2015 no pasa.
Buenas gente. A mi personalmente XboxOne no me parece una mierda ni mucho menos, me parece un gran hardware. También he dicho varias veces que a lo largo de su vida XboxOne va a dar juegos muy muy buenos técnicamente, una cosa no está reñida con la otra.

Y si por ejemplo Ms saliera y dijera, mira no os hemos contado toda la verdad, la eSRAM es de 128MB, tenemos 30 CUs, tenemos esto, esto y esto...yo seré el tío más feliz del mundo, aunq no os lo creais XD , pq ya tendría para dias y dias de lectura y entretenimiento xD.

Un saludo.
Pues todos contentos, creo que no te vas a aburrir.
Polyteres escribió:Buenas gente. Con respecto al tema de las ROPs. Estaba respondiendo a lo que decía el mensaje que estábamos comentando sobre el 16 ROPs "nuevas" vs 64 ROPs antiguas.

Me autocito:

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).


Una cosa es eso, cosa que ya puntualizo en su momento y otra muy distinta prescindir de las ROPs. Ahora mismo con el hardware que hay (y en esto incluyo a XboxOne/Ps4 y PC y por bastante tiempo) es inviable implementar toda la funcionalidad fija de una GPU con trabajo GPGPU. Una GPU tiene un pipeline fijo, dividido en etapas por los que se tiene q pasar. Todo diseñado para ese fin, y de hecho lo hace de forma muy eficiente. Si usas por ejemplo un Compute Shader o un kernel de CUDA para implementar cualquier función no usas dicha funcionalidad fija y esto es un handicap. A parte de q hay ciertas funciones implementadas directamente en el hardware que se hacen de forma muy eficiente (el ZCull por ejemplo, la interpolación entre los distintos atributos, la rasterización...).

Dicho lo cual, y puesto q el número de ROPs siempre suele ser un factor limitante se están buscando ciertas formas de evitar este cuello de botella sobre aquellas operaciones que se presten a ello (que no todas), como por ejemplo la composición de la iluminación de un Deferred Rendering (Frostbite Engine) y efectos de post procesado.

Pero como digo esto es una cosa y otra decir que las ROPs son innecesarias.

Un saludo.


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...

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...
Qwertydhf escribió:Amén.


Jajajaja me lo has quitado de la punta del teclado. Ha faltado el ALELUYA hermanos!

PD: f5 ftw. La verdad está en sus palabras.
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...

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...


Me gusta tu explicacion, de hecho es infinitamente mejor que el batiburrillo de FlashBackMan360.

Respecto a los ROPs, creo que tanto Polyteres como tu estais diciendo algo parecido en el tema de que se esta intentando pasar de ellos. La gran diferencia es que el apunta que hay funciones que todavia se tendran que seguir haciendo en los ROPs, mientras que tu das por hecho que basicamente se hara todo sin pasar por ellos.

Un saludo!
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 ... 82(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 aa 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ó: 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...

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...

Y yo pregunto ¿por que las empresas especialistas en tarjetas gráficas siguen usando los ROPs en su hardware de ultima generación?

Nvidia Titan Black http://www.anandtech.com/show/7765/nvidias-geforce-gtx-titan-black-no-compromises-for-gaming-compute

Radeon R9 290xhttp://www.anandtech.com/show/7457/the-radeon-r9-290x-review
SangReal está baneado del subforo por "Flamer anti Xbox One"
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 ... 82(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 aa 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.

Amen hermano, eres el unico que explica las cosas imparcialmente, dando explicaciones y sin usar insiders o metaforas fuera de lugar
Surrealista del todo este hilo...uno que sabe da una explicación y los demás...tu eres la bomba...otro que también sabe da otra explicación...no no la bomba eres tu...
kamikaze2052 escribió:
f5inet escribió: 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...

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...

Y yo pregunto ¿por que las empresas especialistas en tarjetas gráficas siguen usando los ROPs en su hardware de ultima generación?

Nvidia Titan Black http://www.anandtech.com/show/7765/nvidias-geforce-gtx-titan-black-no-compromises-for-gaming-compute

Radeon R9 290xhttp://www.anandtech.com/show/7457/the-radeon-r9-290x-review


Intel por ejemplo esta siguiendo el mismo camino que ha elegido MS. Ya lo dije antes y nadie me hace ni puto caso pero bueno. Quieren coge cacho de mercado y sus nuevas graficas integradas son del mismo palo que la de One. Que yo sepa Intel no son gilipollas y sus micros se crujen con mucho a los de AMD.
Del mismo modo para poder trabajar con las graficas hacen falta herramientas de programacion y vaya fijate por donde eso lo proporciona MS.
Estamos en una transicion del mismo modo que se vivio hace unos años cuando 360 introdujo la primera grafica de ALUS unificados que Nvidia tanto se resisitia a seguir y que finalmente adopto.
Ya lo dice el dicho: la potencia sin control no sirve de nada.
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 aa 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:
Imagen
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:
Imagen
Imagen

echaros un vistazo tambien al slide 34 (Future Graphics: Software Tiled Rendering)

Y no tengo nada mas que objetar, señoria!!!
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 aa 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:
Imagen
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:
Imagen
Imagen

echaros un vistazo tambien al slide 34 (Future Graphics: Software Tiled Rendering)


Y no tengo nada mas que objetar, señoria!!!



Se agradecen esos enlaces que pones asi poco a poco me voy hasta enterando yo .. Pero poco a poco . QUe no tengo tantos conocimientos como vosotros :)


Por cierto al final se me ha venido esto a la cabeza .. xD
Imagen
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).

Sin embargo porque una cosa (en la actualidad GCN) parezca que tiene que ser de una manera, no significa que deba serlo, porque nos estamos olvidando de algunos factores:

- Bajo la misma base se evoluciona, que yo sepa a cada modelo que tarjeta que sale, aunque no cambie su arquitectura (no siempre pasa sobre todo en el pasado que se liaron a sacar), logran que corra un poco más que la anterior, optimizan por otros medios que no sea el cambio de la arquitectura base.

- El nota ese que habla de "los datos en el lugar correcto en el momento adecuado...", es de XOne, porque no es una arquitectura igual que las otras GCN y punto se acabó ya tiene que ser igual a todo lo demás GCN sin el más mínimo cambio. Se ha diseñado con unidades custom (extiende la arquitectura base de AMD) y para trabajar sobre ESRAM, que recordemos no son 32MB (eso son los de uso general) sino que tiene más añadido (no se si eran 4 u 8 MB o más) exclusivos para trabajar con las Command Unit. Y sí en buses está claro que la XO gana, basta con ver los diagramas, se puede sincronizar perfectamente (cosa que dependerá del driver y/o SDK, el software) el caso de no colisión, dejando siempre trabajando a todas sus unidades sin tiempos de espera (o muy cortos éstos).

Vamos que tras tanto tiempo ya desde estas presentaciones y seguimos con la cantinela de que "es como mi Radeon 7000". No.
Algunos no se enteran que todo evoluciona y que Microsoft a creado una xbox diferente..y algunos solo lo comparan con el pasado..

Nadie sabe de lo que es capaz la xboxone ya que no es como la otra que es mucho mas parecida a un pc actual..

Pero bueno siempre esta bien leer..xddd

Esta claro que veo que la tecnología es mucho mas fácil que sumar 2+2..lo que no entiendo entonces porque para trabajar en las empresas mas importantes del mundo buscan a los mejores, si hoy día la tecnología es igual que hace 10 años leyendo a algunos..

Me alegro que Microsoft haya sacado una consola diferente que nadie conoce aunque insistan en decirnos como funciona..
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:
Imagen
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:
Imagen
Imagen

echaros un vistazo tambien al slide 34 (Future Graphics: Software Tiled Rendering)

Y no tengo nada mas que objetar, señoria!!!


Buenas gente. No hemos llegado a la misma conclusión. Te has equivocado con lo del pipeline fijo y te vuelves a equivocar con lo del shader por defecto y la serie GCN.

Me explico. Hace muuuucho muuucho tiempo cuando salieron las primeras GPUs con vertex y pixel shader programables, estoy hablando antes del lanzamiento de Xbox (la primera), se produjo un cambio muy profundo a nivel de arquitectura, yo creo q el más importante. Al meter un pipeline fijo pero programable, las unidades fijas que hacían ese trabajo no eran necesarias y se eliminaron, puesto que ahora dicho trabajo se lo comían las unidades de computo (vertex y pixel proccessor se llamaban por aquel entonces). Este cambio, como es lógico, trajo consigo un cambio a nivel de software puesto que ahora no solo tenías que enviarle los datos a la gráfica, sino que debías escribir una serie de programas (unos que se ejecutaban sobre los vértices y otros sobre los pixeles...vertex/pixels program o simplemente shaders) que debían suplir dicho trabajo (por ejemplo tenías que hacer la transformación y la iluminación por tu cuenta).

Pero...si habíamos quitado estas unidades...que pasaba con los juegos que no habían sido programados para esta arquitectura y si hacían uso de la funcionalidad fija no programable?. En teoría no podrían ejecutarse en las nuevas gráficas. Para subsanar este problema los fabricantes, a nivel de driver, tenían definidos una serie de shaders por defecto que se encargaban de hacer la funcionalidad no programable para poder darle compatibilidad a los juegos existentes.

Esto no tiene nada que ver con lo que estamos hablando. Una cosa es darte la libertad para que programes una unidad que hasta entonces no había sido programable, es decir, me das la libertad para que una etapa del pipeline gráfico la programe como quiera y otra es pasarte por el forro todos los estados fijos (es decir saltarte todo el pipeline gráfico del tirón) de la GPU renunciando a ellos y usando un compute shaders para hacer todo lo demas, cuando no se está preparado para ello. Como dije en mi mensaje anterior eso hoy por hoy es inviable. Parece que la tendencia será esa...aunq personalmente tengo mis dudas.

Qué es lo proximo que se podría hacer?. Permitid programar las ROPs como yo quiera, es decir, hacer programables las ROPs, Eso no ha pasado aún.

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 aa de hoy, con la potencia que tengo, un rasterizador software en la GPU mediante GPGPU?. No al menos al nivel que deseo.

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).


Eso es lo q dices tu... [sonrisa]

Un saludo.
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 aa de hoy, con la potencia que tengo, un rasterizador software en la GPU mediante GPGPU?. No al menos al nivel que deseo.
[...]


o sea, que la discusion que traemos es por tu crees que XboxONE no posee la potencia necesaria para implementar un rasterizador por 'software' en la GPU via GPGPU y yo creo que si.

Tu defiendes el uso de los ROPs porque con la potencia actual no se podria desarrollar un shader programable que realize el mismo todo el proceso de rasterizacion, y es mejor seguir usando la tecnologia y el know-how actual.

Yo defiendo que no se deben usar los ROPs porque la tecnologia y la arquitectura ha llegado un nivel suficiente para implementar dicho rasterizador por software y obtener aun mas rendimiento que con el pipeline fijo.

basicamente es eso, ¿no? bueno, pues ya veremos quien tiene razon al final... y todo dependera de si la GPU de la XboxONE esta basada al 100% en SeaIslands o 'coge prestada' algunas de las nuevas caracteristicas de VolcanicIslands y/o PirateIslands...

de momento dejo una foto del die de una R9 290X, una tarjeta de la familia VolcanicIslands
Imagen
Vaya... esa disposicion de los shaders me recuerda algo...
f5inet escribió:o sea, que la discusion que traemos es por tu crees que XboxONE no posee la potencia necesaria para implementar un rasterizador por 'software' en la GPU via GPGPU y yo creo que si.

Tu defiendes el uso de los ROPs porque con la potencia actual no se podria desarrollar un shader programable que realize el mismo todo el proceso de rasterizacion, y es mejor seguir usando la tecnologia y el know-how actual.

Yo defiendo que no se deben usar los ROPs porque la tecnologia y la arquitectura ha llegado un nivel suficiente para implementar dicho rasterizador por software y obtener aun mas rendimiento que con el pipeline fijo.

basicamente es eso, ¿no? bueno, pues ya veremos quien tiene razon al final... y todo dependera de si la GPU de la XboxONE esta basada al 100% en SeaIslands o 'coge prestada' algunas de las nuevas caracteristicas de PirateIslands...


Buenas gente. Para seguir manteniendo la calidad que poseemos actualmente no, ni aunque coja prestadas características de PirateIsland. Podrás hacer ciertas cosas un Compute Shaders?. Si sin duda, lo he dicho antes, hay cosas son perfectas para este tipo de cosas, pero todo el pipeline gráfico en esta generación?. Lo dudo mucho.

Ya hay implementado un pipeline gráfico completamente en una GPU pero los resultados...

http://highperformancegraphics.org/prev ... _Laine.pdf

Un saludo.
17587 respuestas