Buenas gente.
@darksch las necesidades de memoria de
este tipo de GPUs usadas en HPC van acordes
a los tamaños de los problemas con los que tienen que lidiar. Los problemas
a los que te enfrentas son los mismos que cuando haces GPGPU en una gráfica de escritorio: las copias de datos entre host/device, el tamaño del problema
a partir del cual una GPU es claramente superior
a una CPU
y merece la pena
ser usada, el tipo de tarea que estás intentando implementar (por ejemplo códigos con muchos saltos condicionales no son buenos candidatos para una GPU), sincronizaciones/comunicación...
A todo esto súmale que una GPU de
este tipo puede estar recibiendo trabajos de más de una CPU
a la vez, tiene encolados una serie de tareas que tiene que realizar... Como te digo la saturación del bus, la copia
y la comunicación siempre es el problema xD.
Como he dicho en alguna ocasión anterior, por la propia arquitectura de una GPU, por el tipo de sistemas que son, por como son diseñadas, su principal necesidad es una memoria rápida, con
un grandísimo ancho de banda (cuanto más mejor), dejando las latencias en
un segundo plano (o tercero) pq las GPUs de base son tragonas de datos. Si
a esto le sumas la adicción de cachés generales de nivel L2, cachés de nivel L1 para cada CU o SM,
y para sincronización
y compartición de datos entre las distintas unidades tienes una caché dedicada, la latencia
aún cobra menos importancia como habeis puesto en el párrafo de sebbbi.
@Szasz es justo todo lo contrario de lo que dices. En HPC probablemente sea de los sitios donde más se cuidan las temperaturas, los consumos
y los precios, es vital en sistemas como estos,
y es uno de los motivos por los que se usan GPUs pq por 240W tienes 4.2TFlops en
un espacio muy reducido.
Todo sistema se pretende que esté balanceado
y no tenga cuellos de botella, da igual que sea una consola o una HPC de 10.000 núcleos. El problema es q estas cosas son delicadas
y no siempre se consigue jeje. Como dije todas las máquinas tienen debilidades. No obstante una cosa es que el sistema esté balanceado
y otra la potencia. Dos sistemas pueden tener potencias diferentes
y sin embargo ambos estar balanceados.
@Aldebaran323 ![[beer]](/images/smilies/nuevos2/brindando.gif "brindis")
@KinderRey - Supongo que querrías decir coprocesadores ARM no?. Ha llegado
un punto que la relación consumo/potencia de
un procesador ARM comienza
a ser relevante para
ser introducido en
este tipo de sistemas, vamos que por muy poco consumo tienes una cantidad de potencia bastante maja. No obstante no tiene mucha relación con las consolas.
- Lo de los FPGAs es el cuento de nunca acabar,
a ver si se acaba introduciendo aunq por lo q he podido ver tiene mucho mas futuro en servidores donde puedes hacer la implementación hardware de
un algoritmo en concreto que en centros de calculo intensivo.
- La GDDR se abandonará en favor de...cualquier sistema de memoria que permita
un ancho de banda mayor con
un menor consumo, lo lógico, como le pasa
a la DDR4 frente
a la DDR3, o como le pasó
a...cualquier nuevo estándar de memoria. No obstante hasta dentro de
un tiempecito no parece que lo vayamos
a oler. Además estas configuraciones de memoria, HBM por ejemplo, se parecen como
un huevo
a una castañ
a a las que tenemos hoy en dia en cualquier dispositivo.
- Abandono de la interfaz PCIe: si te refieres
a Nvlink de Nvidia hasta dentro de 2
años nada,
a parte de que para q algo funcione tiene q estar estandarizado, veremos que hacen AMD e Intel. Además hablar de PCIe o Nvlink en consolas no tiene sentido.
- Uso de cloud computing para aliviar cargas de trabajo: esto no lo entiendo pq si estamos hablando de HPC no veo
a q te refieres o q quieres decir.
- Mayor protagonismo al middleware. Simplificar el desarrollo para HPC: eso no es una tendencia actual, eso es una máxima en cualquier sistema de cualquier tipo sea
un HPC o sea cualquier otro sistema.
@jose1024 pq hay muchas tareas de propósito general cuya finalidad está directamente relacionada con producir
un render. Es q de hecho ese tipo de tareas son la mayorí
a dentro de una GPU. Como he dicho más arriba hay ciertas tareas que no se adecuan
a la arquitectura de una GPU, por ejemplo todo aquello que tenga muchos saltos condicionales no es muy eficiente en una GPU.
Por ejemplo una tarea de propósito general que se puede hacer en una GPU que directamente está relacionada con el render es, crear las listas de luces que afectan
a cada pixel en
un Forward+, o componer
un deferred rendered, o calcular la iluminación indirecta de una escena con
un cone tracing... muchas cosas (
y las que están por llegar) que una CPU
serí
a incapaz de hacerlo en el tiempo que requiere
un frame.
Por otro lado puedes tener otras tareas que te permiten tener mayor variedad o escala de lo que quieres implementar. Por ejemplo si llevas
a la GPU la simuluación de
un sistema de partículas puedes tener una mayor cantidad de ellas, puedes tener colisiones sobre objetos, o puedes tener movimiento de tela
y ropa realistas...son cosas que las si delegas
a una CPU por muy potente que sea es incapaz de gestionar
a tiempo.
Con respecto
a Ps4, no ha reservado nada, no obstante no es el hilo para hablar de ella.
Un saludo.
,ingenieros informarnos a los mortales de alguna novedad ![[360º]](/images/smilies/nuevos/vueltas.gif "como la niña del exorcista")
. ![[sonrisa]](/images/smilies/nuevos/risa_ani1.gif "sonrisa")
.
. Pero es q además digo lo mismo que antes, es absurdo simular una arquitectura de memoria (más allá de un laboratorio de desarrollo). Para que quieres hacer eso?. 
