Que sepas de arranque que yo no estoy diciendo que no puedas tener razón, sino que no hay pruebas concluyentes en este caso y veo cosas que apunta a más posibilidades. Si te gusta bien, y si no también, es mi opinión, arranquemos:
Dfx escribió:Claro que en vídeo es mas difícil apreciarlo, pero a ver, en el vídeo se ve porque jugando se ve, quieres que te grabe un vídeo a 120fps?
Mira que llevaba pensando rato de volver a grabar ese vídeo ya que el OSD no estaba marcando el consumo en la RAM que debía, que ronda los 3,6 a 3,8 normalmente, esos 3GB solo los ha marcado ahi por un error, es imposible que este consumiendo menos que en ultra, cosa que tu mismo, te deberías de haber dado cuenta.
El SLI en Doom va perfecto, en AFR la sincronización no es obviamente la mejor porque una de las GPU tiene que esperar a renderizar su frame y entregarlo en el momento adecuado, asi que una tiene mas carga y la otra menos, en el video en Ultra a 1080p con SLI puedes ver de sobra que funciona estupendamente en tasas de mas de 100fps.
El stuttering esta o no esta, yo no fuerzo nada, y si en un shooter encima de los rápidos no te mueves rápido girando la camara de forma habitual, ya me dirás. Si no hubiera stuttering no se vería, por mucho que gire o no la cámara o lo vaya buscando.
Te recuerdo que la GTX 970 tiene problemas a partir de los ultimos 512MB de VRAM y justamente hice el video a 1500p para forzar un consumo mayor en Ultra y Pesadilla, donde se aprecia mas stuttering cuanto mas uso de VRAM hay. De hecho en el ultimo video en pesadilla con la demo al principio del juego, con un uso de 3,5GB dentro de la base el stuttering prácticamente desaparece ¿Casualidad? lo dudo bastante.
Que vamos, si quieres te repito la prueba a 1080p en pesadilla para que veas que el consumo de VRAM superaba los 3,5GB o si quieres vamos buscando entre zonas que consuman mas de 3,5GB y menos para que lo tengas mas claro y veas que si es conclusivo, que el uso de esa VRAM si esta afectando al rendimiento y ojo te lo dice alguien que tiene 2 GTX 970 y tuve una tercera, pero soy realista, esto no suele pasar en todos los titulos, pero si hay ocasiones que pasa y justamente el SLI ayuda a hacerlo mas evidente al aumentar el techo de potencia de GPU sin aumentar la VRAM.
Pero vamos, ponerse a hablar de virus, de fallos en el motor de ID, etc... es mas fácil que reconocer que no se tenia razon y que la VRAM si afecta cuando el consumo sobrepasa los 3,5GB en este titulo en concreto.
Y fullkiller, cuando pongas un video para demostrar que no hay stuttering, pon uno que efectivamente no sufra de stuttering y cuando hables de la misma zona, que sea de la misma zona, no has puesto ni un solo video en el infierno en la situación de mas carga que tiene el titulo.
1.- Y precisamente porque me he dado cuenta te lo señalo, si es por un error del OSD o no ya es otra razón. Yo no creo que sea el OSD, sino a algo que está pasando realmente en el SLI.
2.- Cada gpu renderiza un frame alternativo, es la mejor forma de reparto de carga entre gpus, dado que si es por áreas de un mismo frame, resulta que la geometría procesada y tiempo total de renderizado puede ser muy distinto (cielo en la parte alta de la pantalla, por ejemplo, contra geometría de una ciudad, personas y coches abajo).
Como son dos frames alternativos pero seguidos, la posibilidad de que tengan una carga gráfica similar es enorme. El envío de los dos frames a procesar desde el sistema se intenta que no sea a la vez en el tiempo para precisamente evitar problemas de mal framepacing, y que sea representativo cada frame de una temporización dentro del juego lo más útil posible. Una gráfica envía ambas imágenes procesadas, pero es un tema baladí ya que lo que se hace es un uso de mínimo un doble buffer donde se almacenan los frames renderizados por la tarjeta maestra y por la esclava (que debe enviarla a la maestra nada más lo acabe) y se van añadiendo nuevos frames en dicho doble buffer o superior, siguiendo una ordenación en forma de cola (pero recogida de frames a pantalla como si fuera una pila) y destruyendo los frames más antiguos. Pila para sacar los frames más recientes, cola para organizar y destruir los frames antiguos.
No sé qué problema ves en este método, es el más efectivo, aunque sí mete una latencia mayor entre lo que se muestra en pantalla y lo que está haciendo el jugador, incluso a pesar de algoritmos de framepacing.
3.- No me recuerdes nada que yo hasta hace nada las tenía, y me han usado hasta los 4 GB de marcador sin problemas.
![[oki]](/images/smilies/net_thumbsup.gif "Ok!")
Lo que pase en Doom no necesariamente tiene que ser un problema por la VRAM, insisto. Es que da igual que pase de 3,5 GB, el microstuttering normalmente lo provocan accesos aún más lentos a memoria principal, por ejemplo (bus pci-e). Para ser apreciable ese "delay" tiene que tener unos cuantos ms de más añadidos y de forma espontánea a un frame de vez en cuando, y eso es más el comportamiento típico de acceder a RAM del sistema en vez de VRAM. Esto es, ese comportamiento lo puedes ver en una tarjeta de 4 GB puros igualmente.
4.- No sé si va por mí porque yo no he hablado de ningún virus, pero sí del motor de ID, pero te recuerdo que el streaming desde disco a VRAM de dicho motor es no ya reconocido, sino usado de forma MASIVA en este motor por la tecnología megatexture, es algo que está pasando como pocos otros juegos, de forma seguida. Eso incluye la descompresión en tiempo real de dichas texturas en la gpu vía gpgpu (CUDA u OpenCL, CUDA seguro en RAGE, y en Doom seguramente es OpenCL aunque podría usarse CUDA para las nvidia, al fin y al cabo ya tenían esto implementado en el motor de antes).
La mayoría del microstuttering que los usuarios aprecian en sus equipos es debido a accesos a disco, que son infinitamente más lentos que la RAM "cojita" de la GTX 970, y con una latencia de respuesta mucho mayor. Incluso si habláramos de un SSD, ya ni digo un HD.
Yo no veo que demuestres nada, acepto la presencia de microstuttering en tus vídeos con un gran salto de fe ya, pero no hay evidencias de que sean por la VRAM (¿consume menos cuando haces giros rápidos a propósito o cuando hay combates? pone lo mismo y no se aprecia entonces MS, ¿no aparecen más justo en el principio de la fase esos microparones?, eso no apunta a que sea un problema por la VRAM en sí, sino más bien por el streaming de datos).
Es que ya te digo, da igual si son 3 GB que si son 3,6 GB, lo cierto es que el OSD en principio no miente si te funciona bien en otras ocasiones (la función del API a la que accede para leer el registro de la VRAM usada por gpu es LA MISMA cada vez que has pasado una prueba, excepto que, por ejemplo, hayas cambiado de driver al vuelo sin reiniciar o algo del estilo, el registro de VRAM usada tiene que ser igual de fiable en un caso que en otro).
De todas formas, ¿sabes si la demo permite poner en modo pesadilla el juego? Más que nada porque así le doy un garbeo y vuelvo a comprobar el tema, a ver si veo yo ese comportamiento que dices y que además se aprecie que sea por VRAM (truco simple, mirar la luz de acceso a disco de reojo cuando se vea ms a ver si se enciende alguna vez, así se descarta por lo menos una potencial explicación). Aún tengo por aquí una GTX 970 disponible.
Bueno, y ya aparte está que lo pongas a ¿1500p==1440p?, evidentemente ahí pedirá más que a 1080p.
PD: La única vez que ví un comportamiento tan anómalo como el del SLI con la VRAM y esos 3 GB es con Tomb Raider cuando en las kepler de entonces "no cabía" en VRAM el tema de TressFX (memoria insuficiente) y de pronto se hacía "un hueco" en ésta a la vez que bajaba el rendimiento de forma muy notoria.
Lo que en realidad pasaba en estas ocasiones (que tras varios drivers y arreglar el consumo de VRAM-bug de TressFX que comía memoria como loco, hasta 400 MB el efecto sólo) es que TressFX, que corría por GPGPU, no podía localizar en la VRAM el espacio de memoria que necesitaba para procesar el pelo, entonces lo que hacía era localizar dicha RAM totalmente en bloque en la principal (MUY NORMAL con código GPGPU dado que usan la memoria VRAM/principal casi como un continuo, o mejor dicho, se puede usar al localizar un área para gpgpu la ram principal si no existe suficiente VRAM en la tarjeta), y usar transferencias via pci-e de dichos datos entre gpu y memoria principal.
El resultado de renderizar el pelo sería guardado en un buffer o RT de la VRAM de la gpu y se seguiría con el render del frame, dejando ese curioso "agujero" de desaparecer espontáneamente el espacio de memoria en VRAM de usar TressFX (fácil forzarlo entonces al meter SSAAx en las opciones gráficas en tarjetas de 2 GB de NVIDIA en exclusiva, para más inri).
Es posible que esté pasando algo del estilo en Doom al usar SLI, ya te digo que no creo que el OSD mida mal en un caso y bien en el otro, y menos si no has hecho algo como reinstalar drivers gráficos o similar, que sí puede falsear registros del API/driver. No olvides que el streaming de texturas se descomprime al vuelo usando también gpgpu, si por algún casual no pudiera llegarle la VRAM que queda en las gpus, podría tirar de memoria principal.
Ojo, que yo no digo que no sea un problema con el juego real en pesadilla, pero no necesariamente es la VRAM.
![[fiu]](/images/smilies/fiu.gif "disimulando")
![[+risas]](/images/smilies/nuevos/risa_ani3.gif "más risas")
![[facepalm]](/images/smilies/facepalm.gif "facepalm")
![[beer]](/images/smilies/nuevos2/brindando.gif "brindis")
![[carcajad]](/images/smilies/nuevos/risa_ani2.gif "carcajada")
