Nachoyazid escribió:La gente no esta pidiendo explicaciones técnicas de porque sucede. Por mucho que otras marcas tengan fallos, ahora se está hablando de este, y de como se va a solucionar.
Sino no se pueden publicitar 4 GB de VRAM efectiva, cuando no toda funciona a la misma velocidad, punto.
Se puede publicitar 4 GB de VRAM, cuando resulta que sí que es efectiva, sólo con una pérdida del rendimiento del 1-3% por usar el segmento pequeño de VRAM, punto.
La "pérdida de velocidad" se aplica sólo respecto a cómo accede a esa memoria la GTX 980, y hasta ahora nadie la ha notado, ni la habría notado, si no fuera porque por comparación entre usuarios, no hubiera gente que se alarmara al ver sus GTX 970 que no usan la misma VRAM total que las GTX 980.... cuando es precisamente para mantener el mejor rendimiento posible. El razonamiento técnico es necesario porque si no se acaban diciendo burradas como "buses de 208 bits" y cosas más bestias.
Las gráficas usan su memoria tanto para los datos que realmente necesitan (texturas, geometría, buffers y otros datos para renderizar la imagen actual) así como para mantener datos obsoletos o incluso precargar datos que se prediga que harán falta en breve. La idea es, si tienes memoria de sobra, quizás mantener texturas y otros datos en la memoria sin usar, o precargar datos, sirva para evitar tener que cargarlos después cuando hagan falta, total, no hay perjuicio por mantener esos datos en memoria si ésta sobra.
Pero en este caso no es así, existe un perjuicio, pequeño pero real, en usar más de 3,5GB sobre todo si no hace falta (nvidia dice claramente, y también las fuentes de dicha noticia, que sí usa más VRAM la GTX 970, simplemente que sigue una política de evitar su uso si no es realmente necesario, por pequeño que sea el efecto en el rendimiento).
La gráfica direcciona los 4 GB SI (condicional muy importante) los necesita de verdad para renderizar un frame dado. NO los usa como igual sí (afirmativo) lo hace una GTX 980 en las mismas condiciones porque el algoritmo de uso de la VRAM es DISTINTO en ambos casos.
En la GTX 980 -> Uso y CACHEO datos antiguos en la VRAM sin distinción de ningún área porque no suponen ni una brizna de menoscabo de rendimiento y sí puede suponer cierta ventaja en condiciones concretas, evitando carga de datos futuras en, por decir, un bus pci-e antiguo, o aunque sea moderno, ahorrándoselo al driver.
En la GTX 970 -> Usa tanta memoria VRAM como me de la gana, incluido CACHEO de datos no necesarios o antiguos, HASTA los 3,5GB de VRAM, si llego a este límite hay dos rutas:
1.- NECESITO más VRAM para renderizar un frame->Accedo a la memoria extra de 500MB en el otro bloque aunque eso suponga una ligera reducción del rendimiento por sobrecarga del método de acceso a la memoria (posiblemente usando un método de direccionamiento más complejo y menos directo), por hacer una mala comparación, sería como el modo PAE de direccionamiento de memoria por encima del límite de 32 bits en un cpu x86. No es lo mismo, pero se puede hacer un símil porque son barreras existentes en cómo se accede a nivel hard y arregladas en éste con "trucos" cuyo impacto real en rendimiento es bajo, pero existente.
2.- Necesito menos VRAM que el total de 3,5 GB para renderizar el frame actual, pero tengo almacenados datos de cacheo en la VRAM que ocupan parte del espacio necesario->eliminar datos de cacheo hasta tener suficiente hueco en la memoria de acceso rápido->llenar con nuevos datos y renderizar.
Volver a empezar, una y otra vez, hasta que exista la auténtica necesidad de superar la barrera, y sufrir una penalización de un 2-3% del rendimiento.
Addenda----Más que posiblemente muchos chips "capados" tienen problemas similares, todos están basados en multiprocesadores en forma de SMs, SMXs o SMMs, o el equivalente de AMD, que suelen usar un bus tipo Xbar para acceder en conjunto a unos controladores de memoria, una forma rápida de trabajar y hacer un direccionamiento rápido de memoria, es segmentar en bloques la memoria, de fácil manejo, por ejemplo 16 bloques por SMM, o más posiblemente, cuatro particiones por cada SMM dado que tienen 4 schedulers independientes manejando un stream de código distinto con sus requerimientos de acceso a memoria propios (un total de 64 segmentos), y mantener X bits como índice para identificar el bloque y posibles recursos tipo punteros u otros que se necesiten dentro de cada segmento para el código shader a ejecutar.
Curiosamente el número de schedulers de un GM204 (un GK104 usa 32) es de 64, cada uno con un hilo de ejecución, esto es, 2^6. Un bloque de 26 bits por segmento daría un tamaño de bloque de 64 MB, este segmento con un índice de 6 bits como el anterior, daría un direccionamiento de 32 bits en total (4GB). Seguramente para acceder por encima de esta cantidad de VRAM hace falta usar métodos de direccionamiento más complejos o cuanto menos cambiar el tamaño de la palabra usada. Sea como sea, será algo menos eficiente usar tamaños demasiado grandes de memoria, poco, pero curiosamente eso se ha visto en algún caso donde configuraciones con "extra" de memoria no van más rápido hasta que supone un beneficio claro y directo el tener más memoria, de hecho hay casos donde lo que se ha visto es una ligera reducción de rendimiento con tarjetas con "extra" de RAM.
El problema está en que en vez de usar el mismo acceso mediocre que puede haber en otros chips de nvidia, incluidos otros chips capados de ésta de generaciones anteriores, y por supuesto AMD, ya que la estructura de SMMs y SMXs es extremadamente parecida, han buscado un método igual de óptimo que en chips superiores y enteros hasta una capacidad máxima, y después, si hace falta, se usa el resto con el mencionado menoscabo de velocidad, que es muy escaso, pero real, y no tiene sentido provocarlo si un juego no necesita ni se va a beneficiar de cacheos de datos excesivos y en contra del rendimiento. La gracia del cacheo de datos está en evitar transferencias y obtener cargas de datos "gratis" al volver a solicitar datos existentes, esto es, en que su implementación no tiene coste alguno. Si implementar esto tiene coste aunque sea pequeño, no se usa, no por lo menos cuando hablamos de superar los 3,5 GB y asumir el coste de un manejo de memoria algo más complejo que por debajo de esa zona (en realidad sobre los 3,25GB).
Problemas de rendimiento "anómalo" en chips capados siempre se han visto, pero sólo que se asumen con pasmosa facilidad (al fin y al cabo, estás comprando la solución con recortes, no la 100% habilitada, y lo asumes), por ejemplo, en el caso del GM204 es el problema del fillrate:
http://techreport.com/blog/27143/here-another-reason-the-geforce-gtx-970-is-slower-than-the-gtx-980Temas como el pixel rate, cuando va acoplado el funcionamiento del hard en distintos niveles, puede hacer que las cifras teóricas no sean las prácticas, dado que cuando se reduce en un hard concreto, se afecta a toda la "pipeline gráfica" a pesar de que tengamos el potencial teórico de, como en este caso, dibujar tantos o más píxeles en una GTX 970.
Se ve un efecto similar entre la GTX 770 y 760, ya que ambas gráficas comparten tanto bus como ROPs, sólo diferenciándose un poco en frecuencia y algo en ancho de banda. Tanto en pixel fillrate (frecuencia x ops de ROPs) como ancho de banda ambos chips sólo se diferencian en un 10% del rendimiento, y por tanto ésa es la diferencia esperable entre ambas en una prueba teórica de fillrate.
Y sin embargo es el doble, se diferencian en un 20%, una muestra de un tipo de dependencia similar a la vista con el GM204 y vinculada al recorte de SMX/SMM en la gpu.
Si posiblemente no vemos problemas similares en otros chips, es porque sinceramente, estarán usando el modo de direccionamiento a lo bruto si es necesario, aunque eso signifique perjudicar levemente al rendimiento, ya hemos visto que el problema del pixel rate existe. Siendo tan parecidos en cómo funcionan SMX y SMM en kepler y maxwell, es más posible que con kepler simplemente mantengan una forma de acceso "simétrico" a memoria en chips capados pero con la penalización (que nadie podría medir, ya que además de pequeña, estaría integrada de forma natural en pruebas), y que lo de maxwell sea una forma de exprimir mejor las capacidades de chips capados sin forzar a usar métodos de direccionamiento y manejo de memoria que no irían tan finas como el "original" GM204 completo.
![[qmparto]](/images/smilies/net_quemeparto.gif "Que me parto!")
, pero más o menos hecho un resumen del problema,si me equivocado con alguna cosa avisarme y lo rectifico.![[enfado1]](/images/smilies/nuevos/enfado_ani1.gif "enfadado")
.
.
![[toctoc]](/images/smilies/nuevos2/rompiendo.gif "machacando")
![[hallow]](/images/smilies/nuevos/hallowen.gif "calabaza")
![[facepalm]](/images/smilies/facepalm.gif "facepalm")
![[plas]](/images/smilies/aplauso.gif "Aplausos")
![[oki]](/images/smilies/net_thumbsup.gif "Ok!")
