Archivo

Categories
Portada (146)

Archive 2018
Julio (1)
Mayo (1)

Archive 2017
Julio (3)
Junio (9)
Abril (1)
Enero (8)

Archive 2016
Junio (8)
Mayo (4)
Abril (3)
Marzo (3)
Enero (7)

Archive 2015
Agosto (3)
Julio (2)
Junio (1)
Mayo (1)
Abril (2)
Marzo (4)
Enero (9)

Archive 2014
Agosto (12)
Julio (53)
Junio (11)

Portada

Notapor f5inet » 23 Nov 2015, 13:43

Creo que ya es el momento de comenzar a hablar de HSA.

Imagen

Que significa HSA:
HSA son las siglas de HETEROGENEOUS SYSTEM ARCHITECTURE

Que es HSA:
HSA es una nueva ISA (Instruction Set Architecture) o arquitectura de computación, cuya función principal es integrar CPU y GPU en el mismo bus, con listas de tareas y pozos de memoria unificados y compartidos.

(Advertencia: voy a usar muy a menudo el término ‘pozo’ como traducción de ‘pool’ cuando nos referimos a ‘memory pool’, en lugar de otro término que también podría usar como ‘piscina’. Cuando leais ‘pozo’ entended que estoy haciendo referencia al equivalente inglés ‘memory pool’)

El objetivo principal de la plataforma HSA es reducir la latencia de la comunicación entre la CPU, la GPU y otros dispositivos de cómputo compatibles HSA, y hacer que todos estos dispositivos, tan diferentes entre sí, sean vistos de la misma forma por el desarrollador, aliviando a este último de la tarea de planificar movimientos de datos entre dispositivos con distintos pozos de memoria, cómo debe realizarse actualmente con OpenCL o CUDA.

HSA no sustituye a OpenCL o CUDA, es más, puesto que HSA no es más que una arquitectura sobre la cual OpenCL y CUDA pueden ejecutarse (con su correspondiente cadena de intérpretes y compiladores JIT), estos lenguajes pueden apoyarse en HSA para aumentar su rendimiento, al no tener que preocuparse en mover buffers de memoria entre diferentes pozos.

Un poco de ‘memoria’:
Introducida originariamente por el Cell Broadband Engine, la posibilidad de compartir la memoria directamente por varias unidades de cómputo de arquitectura distinta a la CPU principal se fue popularizando.
La computación heterogénea, se refiere a sistemas que contienen múltiples unidades de cómputo (Como CPUs, GPUs, DSPs, o diversos ASICs) y en cómo todas estas unidades ven la memoria en un pozo unificado, donde todas pueden acceder simultáneamente.

Sin embargo, puesto que cada unidad de cómputo (CU - Compute Unit) necesita, por razones de rendimiento, memoria cercana donde operar a máxima velocidad, y las distintas unidades de cómputo (a partir de ahora, CUs) pueden tener necesidades específicas respecto a velocidades, ancho de banda o latencia, la arquitectura HSA consigue este objetivo ofreciendo un ESPACIO DE DIRECCIONES VIRTUAL UNIFICADO.

Las CPUs ya disponían de este espacio de direcciones unificado, de hecho, a dia hoy, una CPU puede acceder a toda la memoria instalada en el equipo este donde este, como, por ejemplo, acceder a la memoria de la GPU a traves del bus PCI-Express.

Las MMUs, las grandes protagonistas:
Lo anterior se conseguía a través de un elemento adicional, la Unidad de Gestión de Memoria (a partir de ahora, MMU - Memory Management Unit). La MMU (por última vez, Unidad de Gestión de Memoria), ofrecía a la CPU un espacio ‘virtualmente ilimitado’, o bueno, limitado por el espacio máximo direccionable de la CPU (32bits=4GB, 64bits=16EB), ‘mapeando‘ dentro de dicho espacio virtual, otras memorias adicionales existentes en el sistema.

Por ejemplo, en un sistema con 2GB de RAM y 1GB de VRAM (RAM de Video), la MMU ‘mapeaba’ el GB de VRAM justo a continuación de la RAM Principal. Cuando la CPU hacía referencia al byte que está en la posición ‘2,5GB’, la MMU sabe que tiene que realizar esa petición, via PCI-Express, a la GPU.

Sin embargo, eso no tiene porque ser asi, y de hecho, no es asi. La MMU es programable, y el sistema operativo puede ‘modelar’ las memorias del equipo en la configuración que quiera. En el caso de Windows 32 bits (desde XP en adelante), ese GB de VRAM, se ubica (más correctamente, ‘se mapea’) entre la posición 3GB y 4GB, dejando los 2 primeros GB para la RAM principal, y teniendo un hueco entre los gigas 2 y 3. es lo que se conoce como ‘configuración de memoria virtual’.

Para eso, la MMU tiene unas tablas denominadas ‘Entradas de Tabla de Paginas’, o en su original ingles, PTE (Page Table Entry). Estas tablas se encargan de ‘emparejar’ las direcciones lógicas (o virtuales) con la ubicacion física (o real) de la información.

¿Qué sucede si una aplicación intenta acceder al ‘hueco’ entre los 2 y 3GB? la MMU no sabra a que direccion física corresponde esa direccion logica, y lanzará una excepción a la CPU, que a su vez, el sistema operativo tratara. El sistema operativo grabara al disco duro unos bloques de 4KB que están en la RAM y que hace mucho tiempo que no se usan, dirá a la MMU que esos bloques de 4KB están libres, y que la dirección ‘lógica’ (o virtual) que estaba accediendo ‘lo mapee’ en esos bloques que ahora están libres. La MMU ahora actualiza su PTE, especificando la nueva configuración ‘virtual’

¿Qué sucede si se vuelven a necesitar los bloques de 4KB que ahora están en disco duro? La MMU volvera a lanzar una excepcion, porque dicha ubicacion ‘logica/virtual’ no esta en memoria RAM, el sistema operativo tratara esa excepción, verá cuales ‘paginas/bloques’ de 4KB hace mas tiempo que no se usan, las sacara a disco duro, leera las antiguas paginas del disco duro a RAM, y le comunicara a la MMU el trabajo realizado y que actualice su PTE para reflejar la nueva configuración de la RAM

Esto, que sucede MILLONES Y BILLONES de veces en el proceso normal de un sistema operativo, es lo que se conoce como ‘memoria virtual’ o ‘direccionamiento virtual’, en el cual todos los accesos a memoria son supervisados por una MMU que es la que ‘casa/empareja’ la dirección lógica a la que un programa quiere acceder con la dirección física en la cual están ubicados los datos. De hecho, los programas de hoy dia, jamas ven direcciones físicas, solo virtuales/lógicas, pero desde el punto de vista del programador eso no tiene importancia. De hecho, solo el sistema operativo y la MMU ven direcciones físicas. Nadie mas las ve.

Como os podéis imaginar, este proceso de memoria virtual, con todas las escrituras, lecturas y reasignaciones desde y hacia disco, acaba con la memoria ‘física’ totalmente desordenada en un auténtico caos. Es algo que no importa, porque la memoria RAM es de acceso aleatorio, y tiene la misma velocidad se acceda como se acceda (o al menos, teóricamente, en realidad, si se accede en bloques de 4KB el acceso es más rápido porque solo necesitas una resolución de la MMU y de su PTE).

Es importante que entendáis todo este asunto de las MMUs y el direccionamiento virtual, porque HSA se basa MUCHÍSIMO en ello.

No MMU, no party:
Sin embargo, la GPU no es capaz de acceder a la memoria principal de la CPU, ya que no entiende todo el galimatías de direcciones físicas y lógicas. Para la GPU la VRAM siempre ha sido suya y es un pozo gigantesco donde hacer sus cosas sin problemas de ninguna clase. En este aspecto, las GPUs se han comportado como un acelerador tonto, al cual le decías ‘haz esto aquí’ o ‘haz eso allí’ y simplemente lo hacía.

La GPU, simplemente no es capaz de acceder a la RAM principal porque directamente no la entiende, además, qué en cualquier momento, el sistema operativo, atendiendo una petición de la MMU de la CPU, podría escribir aleatoriamente en cualquier parte de la RAM para poner nuevos datos, provocando multitud de colisiones con los accesos de la GPU.

No, simplemente, todos los accesos a RAM deben ser administrados por la CPU, con su MMU y con el soporte del sistema operativo.

Esto funcionó bien mientras la GPU no era más qué un acelerador esclavo de la CPU, pero con la posibilidad actual de ejecutar código en la GPU qué ofrece DX10 y sus shaders unificados, asi como CUDA, OpenCL y DirectCompute, la GPU está dejando poco a poco de ser un ‘acelerador esclavo’ para pasar a ser una unidad de cómputo completa.

HSA al rescate:
Y de eso precisamente habla HSA. de una Arquitectura para un Sistema Heterogéneo, donde cualquier unidad de cómputo (CU) puede acceder a la RAM en cualquier lugar, y donde una única (o varias) MMUs tienen una visión global de cómo está configurada la memoria

Ahondaremos en profundidad en estos y otros temas en un futuro, de momento, creo qué tenéis mucho qué leer, y qué comprender.
Ir al hilo: HSA101 - INTRODUCCION A HSA
Comentarios: 30

cron