naxeras escribió:Fie escribió:yo soy otro de los que piensan que para jugar a 1080p no vamos a necesitar mas de 2gb vram.
Juego de lanzamiento 1080p y 30fps sin filtros, cuando porten juegos Next-Gen a PC es cuando saldremos de dudas.
Y esto es para jugar a calidad consola claro en una posible configuración recomendada en Ultra...
Un Saludo.
Estuve leyendo el PDF que has linkado antes, y habría que aclarar ciertos puntos.
1.- La "shared memory" no es memoria gráfica:
La primera área definida de la shared memory es "display list x2", que yo intuí como un área donde se almacenaban las drawcalls desde la cpu para la gráfica, por lo leido en páginas posteriores, es lo más parecido que hay en DX a usar una command list pero con la flexibilidad de poder hacer la descripción de toda la imagen al completo y sin problemas (la ventaja está en las drawcalls realizadas en paralelo, command lists es un truco en windows para paralelizar algunas drawcalls con secuencias claras y prefijadas en paralelo, pero vamos, "área para uso de draw calls" es un término que se adapta bien). Hay dos buffers para estas drawcalls, así que entiendo que hay un límite de 32 MB para cada display list (un número máximo por tanto de drawcalls por frame a generar, aunque igual no sea fijo dependiendo de la complejidad de las drawcalls).
Después hay dos áreas similares pero distintas, gpu y cpu scratch, al principio no tenía muy claro a qué se refería, pero deduzco por el término que se parece el término a "scratchpad" por alguna razón, y aunque nada que ver con estas memorias internas de algunos chips, sí puede ser un área donde una parte, la cpu o la gpu, pueden escribir lo que quieran PERO NO la contraria, y donde hay posibilidad de lectura de ambos componentes, esto es, que sería un área donde una y otra se pueden comunicar reservando zonas donde sólo pueden escribir datos una de las partes, y ambas pueden leer y quizás así comunicarse con la otra parte usando su "scratch".
Después hay un área de queries/labels, que posiblemente tenga que ver con la gestión de los recursos a subir a la memoria gráfica (en todo este diseño no parece haber un uso mixto real de zonas de memoria). Y por último hay una streaming pool que no es más que la mínima expresión de ésta necesaria en "memoria principal" y gestionada por la cpu, ya que es ésta la que gestionará el streaming desde discos a la VRAM, y por tanto necesita esta área de memoria mínima para usar de "puente" con la VRAM a la que no tiene un acceso directo (aquí no parece haber hUMA a la vista, o por lo menos no usado masivamente).
Por tanto entiendo que la shared memory no se puede sumar a la memoria gráfica, por la razón de que casi todas estas áreas especificadas tienen algún tipo de equivalente en modelos de programación de PC donde equivaldrían sino directamente, sí por funcionalidad equivalente, a gestiones que hace la cpu preparando datos para la gráfica o mecanismos para la comunicación entre cpu y gpu básicos.
2.- Así que nos quedaría el tema de la VRAM siendo ésta realmente 3 GB justos, veamos cómo se distribuye:
Aquí hay varias áreas interesantes, vemos cómo hay texturas cargadas fuera del streaming (supongo que son texturas bastante frecuentes o que no se puede asumir que haya problemas de popping por el streaming en su representación por su importancia en calidad), que es con diferencia la sección de la VRAM que más se lleva por sí sóla.
Con algo más de 1,25 GB de texturas, lo que no sabemos es si son estrictamente necesarias mantenerlas en VRAM para ir realizando el trabajo pendiente, no podemos olvidar que básicamente la cpu y su memoria no va a almacenar texturas para hacer upstreaming desde memoria, sino que se cargan las texturas directamente en el área controlada por la gpu, ergo existe un problema de base, si necesitas cargar una cantidad de texturas y además las necesitas para YA, tienes que acceder a disco para cargarlas, como no accedes a memoria principal como sería el modelo típico de PC (donde suele haber una réplica de las texturas a usar en memoria principal, o una colección de las texturas que se usan en tal o cual mapeado), sino a disco, tienes una enorme latencia y transferencia muy lenta de estos datos, como esto no es admisible para generar cada frame, esto explica porqué el área de VRAM dedicada a las texturas precargadas y sin streaming en tiempo real de éstas es tan grande. No se puede aceptar que se usen sólo "justo las texturas necesarias" por cada frame, dado la baja velocidad de transferencia entre disco y memoria VRAM (otro caso sería si el área de datos de memoria principal fuera más grande y almacenara las texturas en vez de mantener tantas precargadas en la VRAM, se podría trabajar al vuelo, pero creo que el modelo de uso en este caso para la PS4 es correcto, no tiene sentido mantener las texturas precargadas en "memoria principal" cuando ésta y la VRAM se definen dinámicamente y, por tanto, meter una gran cantidad de "moves" en este caso, en PC puede tener sentido (memoria jerárquica y de muy distinto tamaño, normalmente)).
Para que quede claro que no se precargan texturas ni datos similares en el área de memoria principal, pongo la gráfica de cómo se administra ésta aquí:
Como bien se ve, en el área de memoria de sistema se almacenan muchos tipos de datos, pero básicamente ninguno relacionado con geometría o texturas a usar (sí sin embargo datos de "orden superior" como entidades, supongo que mapeado desde un punto de vista físico, etc).
Siguiendo este análisis de la VRAM usada con Killzone, tenemos como segundo gran consumidor los "render targets", que evidentemente son todo tipo de buffers intermedios usados por el deferred shading usado por el juego, así como los buffers finales como framebuffers y otros relacionados con el postproceso.
Después hay un área dedicada al pool para texturas cargadas por streaming, ahí muestra que la relación es 3:1 entre las texturas que están "relacionadas" con la escena a renderizar y las texturas que realmente usará (con el nivel de detalle necesario o con la carga de sólo aquellas texturas que realmente se muestran o lo que sea de esta colección de texturas "usadas" por streaming desde disco). Este área es de hecho sensiblemente más pequeño que el área de texturas precargadas, lo cual señala que es más importante para este juego mantener cierta colección de texturas fuera de los mecanismos de streaming que depender mucho de él, y otra vez señalo que esto es un reflejo de la distinta jerarquía de cómo funciona la consola y su memoria que la existente en PC.
Después meshes (geometrías), unas pilas que no sé bien de qué, y unos buffers aparentemente relacionados con los ¿geometry shaders y de éstos a los vertex shaders? (¿ES? ¿uso de geometry shaders? un poco raro).
Pero estos últimos puntos son pequeños (excepto quizás meshes, la geometría que define cada objeto, que es un área de cierto peso aunque más compacto que los tres mencionados el comienzo de este punto), así que se pueden despreciar, son las texturas sobre todo las precargadas las que pesan en el juego, y los render targets (buffers de renderizado).
Aquí he de decir que el juego si no usa "filtros" es porque no puede, su objetivo es 1080p a 30 fps, y dice que lo han logrado, pero desde luego no han llegado a los 60 fps (y eso a pesar de varias "optimizaciones" donde han reducido la resolución a la mitad (en realidad un cuarto) de cálculo para varios efectos como niebla volumétrica, reflejos, etc), y por tanto, si con estas condiciones no usan AA, no es porque no puedan, sino porque no hay potencia en la gpu.
Así que es un caso bastante extremo de uso del hard donde están cerca de los límites (según ellos mismos, dados sus objetivos), y donde gran parte de la VRAM consumida está relacionada más que posiblemente por su nula existencia en la memoria de sistema, y por el claro evitamiento del uso de ésta para almacenar datos con los que va a trabajar la gpu.
Esta misma escena en PC posiblemente consumiría menos datos, porque por su jerarquía de memorias puede permitirse más la carga "bajo demanda" de texturas a usar en cada escena, si así lo necesita. Se lo puede permitir pero además es que en el PC se debe evitar sobrecargar de datos la VRAM si puedes tener muchos de éstos en RAM principal. Está claro que si sobra la VRAM en un caso, se puede hacer de forma similar, pero hay una gran diferencia entre esto y que sea obligatorio este tipo de usos (otra vez, el gran desencadenante de si es necesario o no sería conocer qué texturas se usan en "non-streaming" y si son necesarias o no para cada frame renderizado tener esta cantidad precargada).
Los render targets serían los que básicamente se amplificarían al subir resoluciones y al usar AA, también crecerían si varios efectos como el del humo volumétrico y otros se calcularan a la resolución "nativa" de la escena, pero vamos, en principio en PC para lo mismo debería llegar pero seguro con 3GB, y de hecho más que posiblemente llegara con mantener unos 2 GB de VRAM (todo depende del balance de texturas precargadas y obligatorias y hasta qué punto el pool de texturas por streaming es necesario que tenga ese tamaño, no podemos olvidar que en PC hay un mayor ancho de banda desde disco y la RAM principal sobra para estas tareas, a base de incrementar el tamaño del pool en "el otro lado", en la memoria de sistema).
Vamos, que aunque sea un ejemplo de uso de 3 GB de VRAM en consolas, tanto por los objetivos de rendimiento (al límite, 1080p y 30 fps), como por la jerarquía de memoria y por la falta de necesidad de usar la memoria principal como zona de precarga de datos, al final estamos viendo un uso que no tiene porqué reflejar las necesidades en PC (yo, sinceramente, balancearía mucho más el tema de texturas cargadas en VRAM con la memoria de sistema, entiendo porqué se hace así en la PS4, pero también entiendo que en PC por su arquitectura lo mismo se puede hacer de formas distintas, de hecho se debería, lo que sobra en PC es la ram principal, no tanto la VRAM que además no es dinámica).
No hay que olvidar cómo contra las cuerdas pone este juego a la gpu (30 fps y sin AA), y aún así consume esos 4 GB de VRAM sólo por la enorme cantidad de texturas precargadas (para evitar tener que cargarlas desde disco, aquí como VRAM y memoria principal son lo mismo, o mejor dicho, están en el mismo área y uno crece a costa del otro, no tiene sentido el sistema jerárquico visto en el PC donde la RAM principal es muy grande (programas 64 bits y un PC con 8 GB o más de RAM), frente a una VRAM ultrarrápida comparativamente, pero aún así relativamente pequeña (lo normal hoy en día siguen siendo entre 2-3 GB y en las gráficas de gama alta de última generación, las de gama más baja o de la generación anterior, usan 1-2 GB).
Saludos.
PD: En el documento se confirma el uso de 6 cores en la PS4 para la aplicación, con 6 "workers" en los planificadores de carga usados en el desarrollo.
romanturbo-reborn escribió:Tened en cuenta que los primeros juegos aprovechan mal las consolas, por lo cual no estan del todo optimizados y no se les puede sacar mucho jugo usando menos requisitos
Eso con los títulos exclusivos y más los desarrollados por first parties no cuenta. Durante el primer año de vida de la PS3 salieron varios títulos exclusivos que demostraban lo que técnicamente se podía hacer con ella en vez de ser como el resto de juegos simples ports de juegos para PS2 con mayor resolución.
Y eso en un caso como la PS3, donde el modelo de programación era mucho más arisco que ahora con la PS4. Joder, si hasta el cambio desde la PS3 a la PS4 es "poco traumático" debido a que el modelo de programación adoptado para la PS3 se puede trasbasar casi íntegramente (uso del multithread masivamente, también de la orientación a "jobs" para realizar el trabajo, digamos que esa naturaleza de la PS3 de tener una cpu/core "directora" y las demás trabajando en sets de trabajos bien separados se adapta bien a la PS4, excepto por algún detalle que en este pdf hablan sobre qué hay que evitar hacer como en la PS3 y qué prácticas ya no tienen riesgo).
![[+risas]](/images/smilies/nuevos/risa_ani3.gif "más risas")
nos demos cuenta y estas empresas no. Ahora no me vengais que lo hacen para hacernos pasar por caja etc etc... porque el que se compre ahora una 290x o una 290 e incluso 280x, 770, 780 ti (ghz o cualquier modelo de esta grafica) Titan, tiene gráfica para toda la generación, os recuerdo que las consolas "next gen" se quedarán en 1080p(no voy a entrar en la discusion de X1 a 720p etc ) El que decía por aqui que a ver quien juega en 1080 en el 2020, ya te digo yo que todo dios, ya que en 6 años el precio del 4k no se terminará de estabilizar, e incluso hoy en día hay muchísima gente jugando en hd ready, 1280x1024 etc...![[sonrisa]](/images/smilies/nuevos/risa_ani1.gif "sonrisa")
.
.
