Hace algunas semanas ya hablamos sobre el hecho de elegir dentro de lo que consideramos «multi GPU» una opción de renderizado que fuese conveniente para la API y el motor del juego en cuestión. En dicho artículo comentábamos las bondades de usar AFR o Alternate Frame Rendering, así que en esta ocasión vamos a conocer a su rival directo: SFR o Split Frame Rendering. ¿Qué es y qué ventajas tiene uno frente a otro?

Haciendo un poco de memoria, cuando vimos AFR para SLI y CrossFire entendimos que la forma de trabajar era repartirse cada GPU un frame, de manera que una de las tarjetas gráficas tendría los pares y la otra los impares. ¿Es esto lo mejor y más eficiente? ¿qué aporta SFR frente a su rival y cómo trabaja?
Split Frame Rendering: una técnica no demasiado eficiente, pero que se sigue usando


Si AFR conseguía asignar cada frame a una tarjeta gráfica y con ello dividir el trabajo en un orden establecido, SFR es prácticamente lo contrario. En vez de dividir cada frame para una GPU en cuestión, SFR divide la pantalla en dos o más secciones (dependiendo del número de tarjetas gráficas en el sistema) de forma vertical, como si de un juego multijugador retro hablásemos.
Una GPU representará y renderizará una parte de la pantalla y la otra GPU la contraria. Evidentemente, esto en la teoría suena genial, pero todos sabemos que, jugando, muchas veces una parte del escenario está mucho más cargado que la otra, por lo que una GPU va a tener más trabajo y entregará los frames varios milisegundos más tarde que su hermana.
SFR por su naturaleza, tiene implementado un sistema de carga dinámica equilibrada en el driver correspondiente, de manera que, si una GPU está muy saturada, la otra GPU irá en su ayuda. Esto genera una carga de trabajo mucho mayor, ya que ambas GPUs tienen que intercambiar constantemente la posición de los frames para intentar que el trabajo sea el más óptimo.
El problema es que muchas veces dicho trabajo puede duplicarse con cambios de escena muy rápidos, por lo que la sobrecarga de comunicación es mayor y necesitará un bus directo como SLI o NVLink para paliar este déficit dentro de la medida de lo posible.
¿Por qué se sigue usando SFR si el rendimiento no es el más óptimo?


Por cánones de la industria básicamente. Muchos desarrolladores trabajan de forma más simple si usan SFR frente a AFR o SLI híbrido o incluso SLIAA. Desde el punto de vista del programador y el motor usado, es más sencillo trabajar sabiendo que la disposición del reparto de la carga se hará en base a una división vertical de la pantalla y no a cada frame que se vaya generando.
De hecho, hay compañías y motores que trabajan tan bien con SFR que es incluso preferible a AFR por la cantidad de horas y optimizaciones que ha ido adquiriendo el motor con el paso del tiempo.


Evidentemente, estos ejemplos son pocos, pero curiosamente donde se logra una gran implementación, el stuttering final suele ser menor, aunque el rendimiento no es tan bueno como con AFR.
Por lo tanto, hablamos de casos particulares y muy específicos, algo por lo que SFR todavía no ha dicho adiós como tecnología de renderizado para sistemas de más de una GPU. De hecho, AMD por ejemplo usa SFR más en DX12 que en DX11, donde curiosamente se apoyaba en AFR debido al hecho de no requerir una cola de frames, algo que les beneficia gracias a la computación asíncrona, algo muy discutido a la salida de la versión 12 de la API de Microsoft.
The post Split Frame Rendering (SFR), así funciona la tecnología de renderizado para SLI y Crossfire appeared first on HardZone.