Los componentes de un PC cada día están más interconectados entre sí, lo cual es una ventaja sin duda, ya que no quedan aislados y se pierde latencia. Pero cuando hablamos de CPU y de GPU siempre surge una duda a la hora de mirar el rendimiento en gaming. ¿Puede un procesador usar la VRAM de la GPU para su propio beneficio? ¿Gana rendimiento en tal caso o lo pierde? Veámoslo.
Pues es un tema muy a debate realmente, porque hay muchos falsos mitos alrededor de lo que puede o no puede hacer un procesador y de cómo puede hacerlo con la VRAM de la gráfica. Vamos a intentar despejar los mitos de una vez por todas para que entendamos los límites de ambos.
El procesador y la VRAM, ¿relación de amor/odio?
Lo primero que debemos tener claro son términos como acceso y capacitación. La CPU tiene acceso a la VRAM de forma muy limitada, simplemente para asignarle lotes de memoria y ubicaciones como tal, pero dentro de este concepto de acceso hay que matizar un poco.
La CPU y su controlador PCIe así como la VRAM no están conectados directamente como es el caso de la GPU. Se necesita acceder al bus PCIe mediante el driver, BIOS/Firmware de la GPU que a su vez maneja la API gráfica (DX12 en este caso) y de ahí se obtiene un acceso limitado a la VRAM como decimos, mediante asignación de bloques. El problema llega mediante la asignación de búferes para los vértices, o VB, ya que estos se tienen que decidir mediante la API gráfica hacia dónde tiene que ir la información y cómo se accede a ella.
Para ello se utilizan atributos de vértices o VAF, los cuales y por norma general no se implementan bien en la mayoría de juegos, ya que la CPU trabaja las direcciones y la información para la GPU, pasa por las cachés y de ahí van a la RAM del sistema, la cual manda las indicaciones para la carga de DRAWs en el bus PCIe desde la DDR y curiosamente de ahí van a la caché de la GPU.
Esto ahorra un paso previo, pero como vemos saltamos completamente la VRAM, por lo que los programadores y Microsoft, junto con NVIDIA y AMD vieron que había un camino mucho más óptimo para enlazar la VRAM y la CPU.
PCI-SIG ReBar y la VRAM
Como seguro sabemos, el acceso a la VRAM se hacía hasta la implementación de las dos compañías en bloques de 256 MB segmentados, pero estos tenían que recorrer la estructura de la que hemos hablado antes. Lo gracioso es que no era necesario porque PCI-SIG ya tenía ReBar en sus filas desde el PCIe 2.0 como tal, así que ambas iban con retraso con esta limitación.
Resizable Bar y Smart Access Memory quitaban el problema añadiendo un trabajo de copia de la información que se asigna a un subcore, es decir, a un hilo del procesador (por norma general, es paralelizable, pero repercute en el rendimiento de este).
Por lo tanto, el camino ahora era de dos sentidos distintos. En uno la CPU escribe la información en la RAM tras ser trabajada por la caché, mientras que por otro lado hay una copia que es mandada a través del PCIe hacia la VRAM y luego ya de ahí pasa a la caché para terminar en el VAF como tal.
¿Qué conseguimos con ello? Que la CPU escriba directamente una copia de la información en la VRAM y que sea trabajada por la caché de la tarjeta gráfica, para cuando sea necesario y se estime oportuno mediante la API se acceda a la información desde la RAM, la cual ya la tiene asignada antes de la llamada, se descargan las texturas a la VRAM (RAMDisk) y de ahí pasan a la GPU tras el trabajo previo de su caché, lo cual reduce el tiempo de acceso total y aumenta el rendimiento por norma general.
En definitiva, la CPU puede acceder a la VRAM, sí, pero solo para enviarle una copia de la información que trabaja para que esto ahorre tiempo de renderizado y descarga de buses, así como unas idas y venidas sin sentido entre CPU y GPU, por supuesto todo gracias a GART y a las unidades DMA.
Lo que también tiene que quedar claro es que la CPU «no ve» la VRAM como una unidad de memoria como tal. Lo que ve es un dispositivo (GPU) conectado al bus PCIe y que tiene asignada un tipo de memoria, tan simple como eso. Es la API y el driver los que se encargan (previa carga del firmware) de trabajar en un sentido o en otro, porque como decimos, el desarrollador también tiene que disponer de un motor que pueda realizar estas cargas y copias. Debido a ello, la CPU y la VRAM trabajarán de una manera u otra, con un método u otro.
