Rendimiento DirectX 12 y API PS4

Cerrado
1…15, 16, 17, 18, 19…32
eloskuro está baneado del subforo por "flames"
La parienta nos echa de casa.
naxeras escribió:
chris76 escribió:Es una buena solucion,si ya es dificil ver la diferencia entre 900 y 1080 como para ir buscando ahora en que momentos,al menos en TVs de hasta cierto tamaño


Yo por lo menos donde juego en mi tele de 50" se nota a la legua.

Si legua es por debajo de dos metros si.
Empezamos con que si se notan o no pasar de 900 a 1080?
Se nota hasta en las letras del menú.

Parece que nadie tenga un pc y juegue con las resoluciones para darse cuenta que se nota bien el paso de 900 a 1080. :-|
eloskuro está baneado del subforo por "flames"
pabloc escribió:Empezamos con que si se notan o no pasar de 900 a 1080?
Se nota hasta en las letras del menú.

Parece que nadie tenga un pc y juegue con las resoluciones para darse cuenta que se nota bien el paso de 900 a 1080. :-|


Se nota, pero te recuerdo que pasar de tu pc de 900p a 1080p no es lo mismo que en consolas con 1080p reescalados de 900p. (aunque tmb se note)
pabloc escribió:Empezamos con que si se notan o no pasar de 900 a 1080?
Se nota hasta en las letras del menú.

Parece que nadie tenga un pc y juegue con las resoluciones para darse cuenta que se nota bien el paso de 900 a 1080. :-|


No ven ni cuando hay dos frames en la misma imagen como para ver la diferencia 1080p vs 900p
Me da la sensación que se están empezando a mezclar cosas. Si se pudiera mantener mas limpio el hilo mejor, intentemos volver al origen del asunto y centrarse mas en noticias sobre nuevas API.
papatuelo escribió:
pabloc escribió:Empezamos con que si se notan o no pasar de 900 a 1080?
Se nota hasta en las letras del menú.

Parece que nadie tenga un pc y juegue con las resoluciones para darse cuenta que se nota bien el paso de 900 a 1080. :-|


No ven ni cuando hay dos frames en la misma imagen como para ver la diferencia 1080p vs 900p

Es verdad,tienes razón,menuda cagada lo del escalado dinámico,mejor así... [maszz]
darksch escribió:
eRgAlle escribió:


También puedes tener una máquina con una GTX 970 por la mitad de lo que cuesta esa que has puesto (e incluso por menos).

http://www.amazon.es/Ankermann-PC-FX-UL ... 970+gtx+pc

Jaja si vamos, menuda "consola" de 14 Kg [carcajad] Eso lo pongo en cualquier parte. Habrá que ver cuanto consume también. Y el ruido cuando va a tope. No me atrevería a poner eso encima del bluray como tengo ahora la consola la verdad [carcajad]


Eso ya depende de cada uno, de su espacio disponible y organización. Seguro que también hay gente que por ejemplo no tiene espacio para tener una Xbox One, que precisamente pequeña, no es.

Yo por ejemplo tengo en una misma habitación dos PC (uno de ellos conectado a la TV), varias consolas y un proyector (también conectado al PC).

Que uno no pueda/quiera hacer una cosa no significa que no puedan hacerla los demás.
eloskuro está baneado del subforo por "flames"
darksch escribió:Me da la sensación que se están empezando a mezclar cosas. Si se pudiera mantener mas limpio el hilo mejor, intentemos volver al origen del asunto y centrarse mas en noticias sobre nuevas API.

Tienes toda la razón
eloskuro escribió:
darksch escribió:Me da la sensación que se están empezando a mezclar cosas. Si se pudiera mantener mas limpio el hilo mejor, intentemos volver al origen del asunto y centrarse mas en noticias sobre nuevas API.

Tienes toda la razón


Por mí estupendo, mi respuesta anterior era simplemente por alusiones ;)

Saludos.
Puf anda que no llevamos retraso en el software. Habéis visto lo que se mejora en los procesos candidatos a GPGPU usando el modelo completo HSA.

http://www.tomshardware.com/reviews/amd-a10-7800-kaveri-apu-efficiency,3899-5.html

Imagen

En principio cualquier proceso candidato de GPGPU es válido para HSA. El HSA es la versión final y real del GPGPU, ya que en lugar de elegir se usan ambos y además sobre la misma memoria, sin necesidad de copiados.

Resulta que aún nos están quitando partículas y detalles así en consolas que son HSA (perfectas para computar esas cosas), normal si aún se sigue pensando en la PS360, y los motores no dejan de ser los mismos algo variados aunque luego el juego no salga en PS360. Que parece que por 4 cascotes que salten ya tenemos que dar las gracias al cielo.

Ahora que todas las consolas van a llevar AMD con HSA esperemos que sirva de empujón.
eloskuro está baneado del subforo por "flames"
Antes se habalba bastante del HSA, con la llegada de las consolas la cosa la he visto paradita. Supongo que estarán esperando a Vulkan y Directx12 (a parte de los engines renovados y no solo infinítamente parcheados)
Nunca he visto que se hable de HSA para juegos, la verdad. Y solo le veo utilidad para aprovechar la integrada del procesador.
eloskuro está baneado del subforo por "flames"
josemurcia escribió:Nunca he visto que se hable de HSA para juegos, la verdad. Y solo le veo utilidad para aprovechar la integrada del procesador.


Eso decian del GPGPU...
¿Decia quien? NVIDIA lleva mas de 10 años aplicando GPGPU a juegos.
eloskuro está baneado del subforo por "flames"
josemurcia escribió:¿Decia quien? NVIDIA lleva mas de 10 años aplicando GPGPU a juegos.


Interesante ese dato. Con HSA la cosa mejorará aún mas para usar todos los nucleos a la vez etc...Menos latencia y mas rapidez de acceso a los datos entre CPU y GPU. Es lo que tiene que el punto de overhead actual esté en las CPU y no en las tarjetas graficas(que son bestias).

el HSA permitirá que el GPGPU vaya mucho mas fluido.
Considerando que HSA le da mil patadas al GPGPU, ahí tienes tu respuesta.
darksch escribió:Considerando que HSA le da mil patadas al GPGPU, ahí tienes tu respuesta.

HSA es GPGPU. Todo lo que sea utilizar la GPU para computo en lugar de para gráficos es GPGPU.

HSA es utilizar esas técnicas GPGPU junto a la CPU. Que yo creo que viene muy bien para aplicar las ventajas del GPGPU al computo en general que no utiliza la GPU.

¿Pero en juegos? Donde las CPUs ya están saturadas y las GPUs entre gráficos y cómputos también. De donde no hay no se puede sacar.
eloskuro está baneado del subforo por "flames"
josemurcia escribió:
darksch escribió:Considerando que HSA le da mil patadas al GPGPU, ahí tienes tu respuesta.

HSA es GPGPU. Todo lo que sea utilizar la GPU para computo en lugar de para gráficos es GPGPU.

HSA es utilizar esas técnicas GPGPU junto a la CPU. Que yo creo que viene muy bien para aplicar las ventajas del GPGPU al computo en general que no utiliza la GPU.

¿Pero en juegos? Donde las CPUs ya están saturadas y las GPUs entre gráficos y cómputos también. De donde no hay no se puede sacar.


Para eso estan los contextos graficos, la baja latencia de la memoria y que el HSA permita usar la paginación GPUMMU ... oh wait... quizá no en todas las consolas...
Las CPU están saturadas en otras cosas, y de hecho se saturan por no usar HSA entre otras. Imagina el procesado de ciertos elementos y mira esta tabla:

Imagen

Anda, la CPU va muriéndose, se le han cargado tareas que la saturan un 855 respecto a si usara HSA. Con lo cual si:
1) Eliminamos la saturación por culpa de tareas gráficas que no le conciernen (lo que hacen las nuevas API).
2) Reducimos drásticamente la saturación por cómputo sin usar HSA para procesos que sí podrían usarlo.
3) Las nuevas API permiten usar unidades ociosas en cómputo, con lo cual es render + HSA al mismo tiempo.

Con más cálculos resulta que te queda hasta más CPU libre. Es TODO software, y va siendo hora de actualizarlo. Sustituyendo el clásico GPGPU por HSA es = win. ¿Sabés cuanto tiempo se pierde en copiados entre el espacio de memoria de CPU y el de GPU, y luego viceversa?, muchísimo (pista, mira la tabla, OpenCL = GPGPU), y HSA lo corrige, el GPGPU tradicional está ya obsoleto, y no es ni mínimamente comparable al HSA cuando se trata de computar casos reales.

Si quieres, un ejemplo práctico, imaginemos que un juego calcula hasta 100 partículas usando un núcleo (por dar cifras inventadas), usando las unidades ociosas y HSA, ese mismo juego podría poner entre 200+ partículas usando medio núcleo de CPU. Más CPU libre con más contenido en pantalla. Me he basado en la tabla, entre usar CPU y usar HSA tenemos 8 veces más rendimiento, al usar medio núcleo y no entero bajamos a 4x (de 100 a 400 sería), pero al no tener todas las unidades disponibles y usar las ociosas lo bajamos algo (se queda en 200+), y usando menos CPU.
Las partículas no es el ejemplo más acertado ya que las computa enteramente la GPU. En los juegos no existe la ineficiencia que ves en libreoffice por el simple motivo de que la CPU hace lo que mejor sabe hacer y la GPU hace lo que mejor sabe hacer, mientras que Libreoffice Calc o la CPU hace los cálculos(los que se le dan bien y se le dan mal) o la GPU los hace(los que se les da bien y los que se les dan mal), pero no trabajan en conjunto y o se desaprovecha uno o se desaprovecha otro. Y como ya he dicho, no he visto a nadie hablando de HSA para juegos, no veo a ningún desarrollador ilusionado en acelerar los algoritmos GPGPU 8 veces gracias a HSA(Y aquí no hay NDA que valga que la especificación de HSA es pública).
Es un ejemplo perfecto.

https://devtalk.nvidia.com/default/topic/784909/directx-and-direct-compute/directcompute-physx-particles/

Sorry, we currently don't support creating particles through device buffers, neither in APEX nor in PhysX


Sigues teniendo que copiar entre espacios, lo cual es muy lento y pérdida de tiempo.

Todo lo que quieras hacer "sólo" en GPU va a ser más falso que Barrio Sésamo, ya que no puede interactuar en nada con los datos del juego. Por lo tanto olvídate de partículas que rebotan con el escenario y cosas así. El sólo GPGPU sin HSA se queda sólo para demos y benchmarks específicamente hechos para presumir, luego en la vida real no sirven de mucho, y hacen falta copiados entre CPU y GPU con lo cual se pierde gran parte de la gracia del GPGPU.

Si queremos aplicar GPGPU al juego y no como algo superpuesto sin relación alguna, el uso de HSA permite mayor número de elementos y encima consumiendo menos CPU. Se supone que el objetivo es mejorar los elementos del juego como físicas, IAs, y etc. y HSA es lo que lo permite.

Y como ya he dicho, no he visto a nadie hablando de HSA para juegos, no veo a ningún desarrollador ilusionado en acelerar los algoritmos GPGPU 8 veces gracias a HSA(Y aquí no hay NDA que valga que la especificación de HSA es pública).

Te recuerdo como he empezado:
Puf anda que no llevamos retraso en el software.

Si quieres te menciono más, como ese tile-rendering con documentación del EUROGRAPHICS 2012 y que aún no usa casi ni el tato, sabiendo que supone mejora de rendimiento en TODAS las plataformas. ¿Lo ha mencionado alguien como interesado en usarlo?.

Si estas consolas (y en PC pero digo consolas como algo comparable consigo misma al ser cerrada) usaran el conjunto completo: nueva API + parallel computing + HSA + Forward+, de verdad que se mearían literalmente en lo que vemos ahora mismo. Están absolutamente capadas en modelos obsoletos que no usan ninguna de sus funciones.
Deberías echarle un vistazo al sistema de partículas de infamous second son.
josemurcia escribió:Deberías echarle un vistazo al sistema de partículas de infamous second son.

PS4 = HSA, juego exclusivo = uso de sus funciones. Imagina si lo usaran todo como he añadido a mi post anterior. ¿Aún dudas que no habría una gran mejora?.

Y ese ISS es solo el comienzo porque el modelo de programación HSA pues imagina lo verde que andaría aún.

Actualmente el 90% del uso que se hace de las nuevas consolas son como PS360 más potentes y ya está. Y el otro 10% usa alguna función nueva, pero ninguno las usa todas.
El modelo de partículas de ISS es GPGPU tradicional solo que aprovechando las ventajas de la memoria compartida, y es como se hace el GPGPU en consolas. Las limitaciones de PhysX y CUDA en general es que no comparten memoria con la CPU y nunca lo harán. Y ahí es donde intervienen los nuevos tipos de memoria y NVLink para reducir estas limitaciones.

De ahí mi comentario inicial, esto en juegos la única ventaja que va a traer es aprovechar las GPUs integradas liberando de tareas de cómputo a la dedicada, lo cual va a ser anecdótico y olvidable con la siguiente iteración de GPUs, debido al ritmo al que están evolucionando estas.
El modelo de partículas de ISS es GPGPU tradicional solo que aprovechando las ventajas de la memoria compartida

La coherencia es parte fundamental del HSA. Si encima añadimos apoyo por parte de la CPU mejor aún.

De ahí mi comentario inicial, esto en juegos la única ventaja que va a traer es aprovechar las GPUs integradas liberando de tareas de cómputo a la dedicada

Ni de lejos, y menos aún en consolas.
El tiempo hablará. Ya digo que si esto fuera significativo tendríamos a devs igual de ilusionados con HSA que con Vulkan y DX12.
eloskuro está baneado del subforo por "flames"
darksch escribió:
El modelo de partículas de ISS es GPGPU tradicional solo que aprovechando las ventajas de la memoria compartida

La coherencia es parte fundamental del HSA. Si encima añadimos apoyo por parte de la CPU mejor aún.

De ahí mi comentario inicial, esto en juegos la única ventaja que va a traer es aprovechar las GPUs integradas liberando de tareas de cómputo a la dedicada

Ni de lejos, y menos aún en consolas.


Tambien apoya al offload de procesos
josemurcia escribió:El tiempo hablará. Ya digo que si esto fuera significativo tendríamos a devs igual de ilusionados con HSA que con Vulkan y DX12.

Pues supongo que sí, pero tampoco parecen muy "ilusionados" en actualizar motores a nuevos sistemas de render como ya dije. La máxima sabemos que es máximo beneficio haciendo el mínimo posible.

El problema es el de siempre, la retrocompatibilidad, la misma razón por la cual no han actualizado motores aún. Igual que antes el problema ha sido la PS360, ahora lo será el PC, ya que sólo le sacarían partido aquellos que tengan una APU HSA.

Pero el uso de HSA es como meterle un boost acojonante a la CPU. Algo parecido a cuando antes tenías o no FPU en la CPU cuando tocaba poner algo con punto flotante.
Porque Forward+ no representa un cambio tan significativo en la mayoría de juegos respecto a Deferred Shading.

De hecho el motor de TW3 tiene pipeline tanto Deferred como Forward+.
Mira las tarjetas y mira la mejora.

http://www.slideshare.net/fullscreen/takahiroharada/forward-34779335/21

Anda por lo menos entre el 20-30%, en GPUs más o menos limitadas como las de las consolas pues nos fijamos que como suele ser habitual es donde más se nota.

TW3 no creo que presuma mucho porque eso es sobre todo para iluminación y al final en la versión final le han quitado toda la iluminación volumétrica y demás y la han dejado plana. En el propio hilo del juego alguien lo ha puesto el antes y el ahora.
Mejora mucho para esa situación concreta, en TW3 como tu mismo dices lo más seguro es que la diferencia sea mínima, y por el mismo motivo no se usa en la mayoría de juegos.
josemurcia escribió:Mejora mucho para esa situación concreta, en TW3 como tu mismo dices lo más seguro es que la diferencia sea mínima, y por el mismo motivo no se usa en la mayoría de juegos.

Claro una situación de gran complejidad en iluminación. El problema es que en TW3 han hecho downgrade masivo de la luz. Se supone que hay que mejorar no poner gráficos PS360 mejorados y punto. Es que todas las cosas nuevas que se han decidido montar es precisamente para dejar atrás los modelos antiguos, no simplemente para mejorarlos algo.
Si tienen un pipeline forward+ y han hecho downgrade masivo es porque ni con esa técnica completamente nueva han conseguido milagros. Las consolas nuevas no dan para más y hay que asumirlo.
.
Si no sabemos hablar y debatir, empezamos a repartir premios.
¿El motor de The Witcher 3 es Forward+? :-?
josemayuste escribió:¿El motor de The Witcher 3 es Forward+? :-?

Así lo anunciaron hace 2 años.
http://www.examiner.com/article/possibl ... nouncement

A flexible renderer prepared for deferred or forward+ rendering pipelines has a wide array of cinematic post-processing effects, including bokeh depth-of-field, color grading and flares from many lights.
Tengo una duda, hasta ahora cuando hablan del multiadapter siempre hablan de usar conjuntamente la integrada y la discreta. ¿¿¿Pero servida igualmente para dos discretas???

Hay alguna confirmación?
DX12 no se, pero si la hay por parte de Vulkan. No creo que DX12 sea menos.

Imagen
Me equivoqué, si esta confirmado.

Imagen
ahona escribió:Si no sabemos hablar y debatir, empezamos a repartir premios.

Perdona pero no sé el por qué de la edición. Es un no estar de acuerdo de toda la vida.

@josemayuste es "flexible", con lo cual no sé yo que tanto se puede sacar de ahí, y del uso de tile-rendering en un motor que va a funcionar en deferred también pues más dudas aún.
Buenas gente. Aunq llego un poco tarde al debate sobre HSA que habéis tenido @darksch y @josemurcia me gustaría recuperar ciertos comentarios y puntualizar algunos detalles.

Actualmente se está usando de forma masiva GPGPU para juegos. Una tarea que es ejecutada en la GPU sin usar el pipeline gráfico es una tarea de propósito general. Éstas no tienen pq ser cálculo de físicas o más generales, de hecho principalmente son tareas asociadas a procesos gráficos, puesto que no olvidemos estamos haciendo juegos y gráficos. Por ejemplo aplicar la iluminación en un Compute Shader es GPGPU, o realizar un efecto DOF, al igual que calcular la posición y velocidad de un sistema de partículas o la deformación de los vértices de un tejido. Realizar tareas gráficas usando un Compute Shader en vez de usar el pipeline fijo tiene ciertas ventajas q mejoran el rendimiento (generalmente derivadas del uso más eficiente de los accesos a memoria). Lo que HSA intenta es "facilitar" el uso de la GPU para programadores más ajenos a este tipo de arquitecturas, mediante herramientas de más alto nivel y sin tener que profundizar mucho como se hace ahora mismo, y para ello se necesitan una serie de características tanto hardware como de soporte por parte del SO, el driver, y los compiladores.

No todas las tareas puede ser ejecutadas en una GPU de forma eficiente (con o sin HSA). Debido a las características propias de la arquitectura de una GPU ciertas tareas son más amigables y se consigue una enorme mejora de rendimiento si son ejecutadas en una GPU frente a una CPU. Por ejemplo cualquier código q tenga gran cantidad de saltos o tareas que se ejecuten sobre pocos datos suelen dar malos resultados cuando se llevan a la GPU.

Las copias de datos entre distintos espacios de direcciones perjudican el rendimiento. Tener un espacio de direcciones común ayuda. Este es uno de los aspectos más destacados de la arquitectura HSA, pero, no siempre se necesitan copiar datos (de hecho en la arquitectura HSA no toda la memoria es "común", la GPU puede tener partes privadas de acceso muy rápido). Un claro ejemplo de esto que digo es el sistema de párticulas que habíais comentado anteriormente. En este caso concreto se crean buffers de posición, velocidad, aceleración... en la memoria de la GPU, se hacen los cálculos pertinentes mediante un Compute Shader, y el buffer de posición se pasa a un vertex shader para dibujar, 0 copias. Esto se puede aplicar a simulaciones de ropa por ejemplo, cálculo de huesos en animaciones... Todos los filtros q se aplican a una imagen, el calculo de la iluminación... no necesitan copias puesto q no es necesario devolver datos a la CPU. Incluso, mediante Indirect Draw, una GPU podría "enviarse" drawcalls a sí misma sin necesidad de intervención de una CPU, sin overhead de la API...y eso se puede hacer actualmente sin Vulkan ni DirectX12.

Respecto a los motores Forward+ y otros basados en tiles. Hay muchas formas de sacar un render dependiendo de que renderices en cada momento y como (deferred rendering, forward rendering, deferred shading, deferred lighting, light prepass, miles de combinaciones posibles...) y dependiendo de como compongas el frame, o como calcules la iluminiación puedes hacerlo por tiles o "del tirón". Usar tiles no es exclusivo del forward+, los deferred tb los usan de forma muy intensa (Frostbyte Engine desde los tiempos de Ps3 o por ejemplo el motor de Naughty Dog). Es más se puede hacer un forward+ sin tiles ni Compute Shaders funcionando en una GPU de smarthphone XD XD XD y con muy buen rendimiento.

Los motores son herramientas cuya función es plasmar la idea que tiene el artista de la manera más eficiente posible, molestando lo menos posible al proceso de producción. No hay una forma universal y mágica de sacar frames, cada estudio tiene unas necesidades y dependiendo de estas se elige uno u otro.

Un saludo.
darksch escribió:
ahona escribió:Si no sabemos hablar y debatir, empezamos a repartir premios.

Perdona pero no sé el por qué de la edición. Es un no estar de acuerdo de toda la vida.

@josemayuste es "flexible", con lo cual no sé yo que tanto se puede sacar de ahí, y del uso de tile-rendering en un motor que va a funcionar en deferred también pues más dudas aún.


Gracias por responder , no pretendía sacar conclusiones de éso , sólo era un dato que desconocía.
Polyteres escribió:Buenas gente. Aunq llego un poco tarde al debate sobre HSA que habéis tenido @darksch y @josemurcia me gustaría recuperar ciertos comentarios y puntualizar algunos detalles.

Actualmente se está usando de forma masiva GPGPU para juegos. Una tarea que es ejecutada en la GPU sin usar el pipeline gráfico es una tarea de propósito general. Éstas no tienen pq ser cálculo de físicas o más generales, de hecho principalmente son tareas asociadas a procesos gráficos, puesto que no olvidemos estamos haciendo juegos y gráficos. Por ejemplo aplicar la iluminación en un Compute Shader es GPGPU, o realizar un efecto DOF, al igual que calcular la posición y velocidad de un sistema de partículas o la deformación de los vértices de un tejido. Realizar tareas gráficas usando un Compute Shader en vez de usar el pipeline fijo tiene ciertas ventajas q mejoran el rendimiento (generalmente derivadas del uso más eficiente de los accesos a memoria). Lo que HSA intenta es "facilitar" el uso de la GPU para programadores más ajenos a este tipo de arquitecturas, mediante herramientas de más alto nivel y sin tener que profundizar mucho como se hace ahora mismo, y para ello se necesitan una serie de características tanto hardware como de soporte por parte del SO, el driver, y los compiladores.

No todas las tareas puede ser ejecutadas en una GPU de forma eficiente (con o sin HSA). Debido a las características propias de la arquitectura de una GPU ciertas tareas son más amigables y se consigue una enorme mejora de rendimiento si son ejecutadas en una GPU frente a una CPU. Por ejemplo cualquier código q tenga gran cantidad de saltos o tareas que se ejecuten sobre pocos datos suelen dar malos resultados cuando se llevan a la GPU.

Las copias de datos entre distintos espacios de direcciones perjudican el rendimiento. Tener un espacio de direcciones común ayuda. Este es uno de los aspectos más destacados de la arquitectura HSA, pero, no siempre se necesitan copiar datos (de hecho en la arquitectura HSA no toda la memoria es "común", la GPU puede tener partes privadas de acceso muy rápido). Un claro ejemplo de esto que digo es el sistema de párticulas que habíais comentado anteriormente. En este caso concreto se crean buffers de posición, velocidad, aceleración... en la memoria de la GPU, se hacen los cálculos pertinentes mediante un Compute Shader, y el buffer de posición se pasa a un vertex shader para dibujar, 0 copias. Esto se puede aplicar a simulaciones de ropa por ejemplo, cálculo de huesos en animaciones... Todos los filtros q se aplican a una imagen, el calculo de la iluminación... no necesitan copias puesto q no es necesario devolver datos a la CPU. Incluso, mediante Indirect Draw, una GPU podría "enviarse" drawcalls a sí misma sin necesidad de intervención de una CPU, sin overhead de la API...y eso se puede hacer actualmente sin Vulkan ni DirectX12.

Respecto a los motores Forward+ y otros basados en tiles. Hay muchas formas de sacar un render dependiendo de que renderices en cada momento y como (deferred rendering, forward rendering, deferred shading, deferred lighting, light prepass, miles de combinaciones posibles...) y dependiendo de como compongas el frame, o como calcules la iluminiación puedes hacerlo por tiles o "del tirón". Usar tiles no es exclusivo del forward+, los deferred tb los usan de forma muy intensa (Frostbyte Engine desde los tiempos de Ps3 o por ejemplo el motor de Naughty Dog). Es más se puede hacer un forward+ sin tiles ni Compute Shaders funcionando en una GPU de smarthphone XD XD XD y con muy buen rendimiento.

Los motores son herramientas cuya función es plasmar la idea que tiene el artista de la manera más eficiente posible, molestando lo menos posible al proceso de producción. No hay una forma universal y mágica de sacar frames, cada estudio tiene unas necesidades y dependiendo de estas se elige uno u otro.

Un saludo.

Rebienvenido al topic!

Quería hacerte una pregunta. Existen bastantes benchmarks hablando de un aumento muy grande de drawcalls, mucha gente lo asocia directamente a un aumento proporcional del rendimiento. Me gustaría preguntarte si dicho aumento tiene que ir ligado de una potencia de cálculo grande, una gran cantidad de ACEs, CUs, nuevas arquitecturas, etc. para poder hablar de aumento de rendimiento o per se ya es un cambio significativo.
Hemos de suponer que a todo eso el async shader (o nombre que le de la API) debería ayudar bastante.

Luego como dije pues para partículas independientes ok, pero si quieres elementos que interactúen (mas reales) por ejemplo que reboten contra el escenario etc. pues el espacio común ayuda mucho, para las colisiones con el escenario (el mapa de colisiones que no tendrías en la GPU). También esta por ver los elementos comunes a un juego (colisiones, visibilidad, IA, etc.) cuales son o tienen elementos paralelizables lo cual le podrían sacar buen partido al HSA.

También tener mas drawcalls por segundo implica hacer las mismas en menos tiempo, reduciendo la latencia, lo cual es importante para cumplir con el tiempo por frame requerido.

Por eso es importante que se aplique todo, no nada como hacen ahora la mayoría de los juegos (multis especialmente) o tan solo alguna. Es decir, que cuando dejen de programarse como PC con CPU Intel y se empiecen a programar como consolas con APU AMD y nueva API debería notarse una buena mejora.
Buenas gente. @J_Ark bueno un aumento en las drawcalls es eso...un aumento en las drawcalls jajaja, "nada mas". Cuando digo "nada mas" no le estoy quitando importancia (q me conozco a algunos ya saltando [+risas] ), te permite hacer de forma más "sencilla" lo q ahora haces de otro modo. Podríamos decir que para el programador es una cosa menos de la q preocuparse.

Aumentar el numero de drawcalls no aumenta de forma proporcional el rendimiento, solo te está diciendo que puedes enviar más trabajo pero la GPU tiene q ser capaz de comerse ese trabajo y sino lo es...por mucho trabajo que le envies si no lo puede sacar estamos en las mismas. Es como un jefe y un empleado, puedes tener un jefe que te de muy pocas tareas pero q esas tareas sean muy complejas de hacer y por tanto con dos tareas te tiras todo el día, o puede estar dandote muchas ordenes, mas o menos complejas, y q o bien te de tiempo a hacerlas o tengas que dejarlo para mañana xD.

Generalmente los juegos tienden a ser GPU-bound y si no lo eres siempre puedes ajustar la carga gráfica para que así lo sea (aumentar la resolución por ejemplo, o meter un AA más complejo hace que seas GPU-bound rápidamente). Si eres CPU-bound por un margen suficiente, podrías aumentar por ejemplo la resolución que los fps no variarían.

Actualmente agrupar mallas en batch usando virtual texturing por ejemplo te permite dibujar muchos elementos con muy pocas llamadas o usando Indirect Draw consigues un rendimiento muy bueno, de forma que con muy pocas llamadas estás saturando la GPU y maximizando su uso.

http://www.openglsuperbible.com/2013/10 ... ion-draws/

Dicho esto, y para que quede constancia, poder hacer mas drawcalls (mas que el número de drawcalls lo realmente importante es poder trabajar a mas bajo nivel sin depender tanto del driver) es una mejora muy significativa y muy importante [beer] .

@darksch poder ejecutar tareas de propósito general en los "huecos" que la GPU deja por estar saturada en algún punto del pipeline gráfico no tiene mucho que ver con HSA. Como dije en mi mensaje anterior HSA implica muchos detalles donde el espacio comun de direcciones es solo una pequeña parte, hay otra serie de características que se deben cumplir para que un sistema sea HSA compilant y q en aplicaciones como juegos (por su exigencia y necesidad de control por parte de los programadores) son menos relevantes. Puedes tener un sistema que tenga un espacio de direcciones común pero no ser HSA compilant y seguir beneficiandote de no necesitar hacer copias entre espacios de direcciones.

Puedes tener perfectamente un sistema de colisiones con el escenario enteramente en la GPU sin necesidad de intervención de la CPU, es más...es preferible. Ten en cuenta que la posición/rotación de las particulas/mallas es consumida enteramente por la GPU por lo q no sería necesario que la CPU sepa nada de esto y que las colisiones con el escenario serían datos de solo lectura, las cuales la CPU tampoco necesita saber nada...todo se puede quedar en la memoria de la GPU sin necesidad de pasar ni por las cachés de la CPU ni ser copiado a ningún otro sitio:

https://www.youtube.com/watch?v=zPnwmsTokso

Una ventaja del espacio unificado de direcciones es que puedes pasarle a la GPU estructuras de datos complejas (como por ejemplo listas enlazadas, o árboles) y que tanto GPU como CPU puedan operar de forma conjunta con dichas estructuras. Los patrones de acceso a memoria, el uso de cachés y memorias privadas en las GPUs actuales son muy importantes para conseguir un buen rendimiento.

Un saludo.
Polyteres escribió:Aumentar el numero de drawcalls no aumenta de forma proporcional el rendimiento, solo te está diciendo que puedes enviar más trabajo pero la GPU tiene q ser capaz de comerse ese trabajo y sino lo es...por mucho trabajo que le envies si no lo puede sacar estamos en las mismas.

Vale, es como imaginaba, gracias crack.
Aumentar el numero de drawcalls es bueno, pero luego hay que procesarlas, ahi veremos quien se saturara.

Pero vamos, ya lo vimos en la presentacion de windows 10, 600% de drawcalls en la pantalla y phil spencer hablaba de otro porcentaje de rendimiento. Las drawcalls son una parte de un mundo.
Que incidencia tendría el aumento de los draw calls en la iluminación?

Xq Wardell siempre dice a partir de ahora tendremos fuentes de luz prácticamente ilimitadas???

Creo que este aumento en la capacidad de asimilar calls tiene algo que ver con la cantidad de objetos en pantalla y las fuentes de luz.

Fijaros en este test:

http://forums.steampowered.com/forums/showthread.php?t=3222234

La 280x saca los mismos frames a 1080p que a 2K, si el command processor le permitiera manejar mas call casi con toda seguridad sacaría más frames. Si os dais cuenta el primer test tiene un aumento de frames del 166% y en el segundo caso del 200%.

Y sin embargo en ninguno de los dos casos supera los 50 frames. Al menos en el primero de los casos según el razonamiento de polyteres podemos decir que "solo" obtenemos el 166 por el cuello de botella en la CPU, pero problamente dicho cuello no esta en la CPU si no en el command processor.

De hecho es seguro, xq el usuario siguiente utilza un I7 2600 y se vuelve a quedar clavado en 52 frames.

Si estos es así una 285 debería pasarle la mano por la cara a esa 280X, pero no he encontrado ningun test con la 285.

Por lo tanto tenemos que en estos escenarios con infinidad de fuentes de luz y mucho elementos en pantalla, aunque el aumento de los call no es directamente proporcional 1:1 al aumento de frmaes sí es proporcional. Y tenemos que el command processor de un 7970 limita en ocasiones su rendimiento.
1577 respuestas
Cerrado
1…15, 16, 17, 18, 19…32
Volver a General