› Foros › Multiplataforma › General
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.
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.
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.
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
darksch escribió:eRgAlle escribió:eloskuro escribió:Una compañia seria. Toma tu "consola"
http://www.amazon.es/Asus-G20AJ-DE028S-Ordenador-procesador-reproductor/dp/B00QIFZAW4/ref=sr_1_5?s=computers&ie=UTF8&qid=1431366893&sr=1-5&keywords=gtx+970
1600€
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 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
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.
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
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.
josemurcia escribió:¿Decia quien? NVIDIA lleva mas de 10 años aplicando GPGPU a juegos.
darksch escribió:Considerando que HSA le da mil patadas al GPGPU, ahí tienes tu respuesta.
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.
Sorry, we currently don't support creating particles through device buffers, neither in APEX nor in PhysX
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).
Puf anda que no llevamos retraso en el software.
josemurcia escribió:Deberías echarle un vistazo al sistema de partículas de infamous second son.
El modelo de partículas de ISS es GPGPU tradicional solo que aprovechando las ventajas de la memoria compartida
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
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.
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.
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.
josemayuste escribió:¿El motor de The Witcher 3 es Forward+?
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.
ahona escribió:Si no sabemos hablar y debatir, empezamos a repartir premios.
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.
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 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.
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.