Articulo de referencia

Computación de propósito general en unidades de procesamiento gráfico

La computación de propósito general en unidades de procesamiento gráfico ( GPGPU , o menos comúnmente GPGP ) consiste en el uso de una unidad de procesamiento gráfico (GPU), que...

La computación de propósito general en unidades de procesamiento gráfico ( GPGPU , o menos comúnmente GPGP ) consiste en el uso de una unidad de procesamiento gráfico (GPU), que normalmente solo se encarga de los cálculos para gráficos por computadora , para realizar cálculos en aplicaciones que tradicionalmente se manejan mediante la unidad central de procesamiento (CPU). [ 1 ] [ 2 ] [ 3 ] [ 4 ] El uso de múltiples tarjetas de video en una computadora, o un gran número de chips gráficos, paraleliza aún más la naturaleza ya paralela del procesamiento gráfico. [ 5 ]

En esencia, una arquitectura GPGPU consiste en un procesamiento paralelo entre una o más GPU y CPU, con instrucciones aceleradas especiales para procesar imágenes u otros tipos de datos gráficos. Si bien las GPU operan a frecuencias más bajas, suelen tener muchas más unidades de procesamiento . Por lo tanto, pueden procesar muchas más imágenes y otros datos gráficos por segundo que una CPU tradicional. Convertir los datos a formato paralelo y luego usar la GPU para procesarlos puede (en teoría) generar una gran aceleración .

Las arquitecturas GPGPU se desarrollaron a principios del siglo XXI para el procesamiento de gráficos (por ejemplo, para obtener mejores sombreadores ). En la historia de la supercomputación , es bien sabido que la computación científica concentra la mayor cantidad de potencia de cálculo de la historia, como se muestra en el TOP500 : la mayoría utiliza GPU en la actualidad .

Las GPGPU más conocidas son las Nvidia Tesla , que se utilizan para Nvidia DGX , junto con las AMD Instinct y las Intel Gaudi.

Historia

En principio, cualquier función booleana arbitraria , incluyendo la suma, la multiplicación y otras funciones matemáticas, puede construirse a partir de un conjunto funcionalmente completo de operadores lógicos. En 1987, el Juego de la Vida de Conway se convirtió en uno de los primeros ejemplos de computación de propósito general que utilizaba un procesador de flujo primitivo llamado blitter para invocar una secuencia especial de operaciones lógicas sobre vectores de bits. [ 6 ]

La computación de propósito general en GPU se volvió más práctica y popular después de 2001, con la llegada de los sombreadores programables y la compatibilidad con coma flotante en los procesadores gráficos. En particular, los problemas que involucran matrices y/o vectores , especialmente vectores bidimensionales, tridimensionales o cuatridimensionales , se podían traducir fácilmente a una GPU, que opera con velocidad nativa y compatibilidad con esos tipos. Un hito significativo para GPGPU fue el año 2003, cuando dos grupos de investigación descubrieron de forma independiente enfoques basados ​​en GPU para la solución de problemas de álgebra lineal general en GPU que se ejecutaban más rápido que en las CPU. [ 7 ] [ 8 ] Estos primeros esfuerzos para usar GPU como procesadores de propósito general requirieron reformular los problemas computacionales en términos de primitivas gráficas, como lo soportan las dos principales API para procesadores gráficos, OpenGL y Direct3D . Esta engorrosa traducción se eliminó con la llegada de lenguajes de programación de propósito general y API como Sh / RapidMind , Brook y Accelerator. [ 9 ] [ 10 ] [ 11 ]  

A estos les siguió CUDA de Nvidia , que permitió a los programadores ignorar los conceptos gráficos subyacentes en favor de conceptos de computación de alto rendimiento más comunes. [ 12 ] Las ofertas más recientes e independientes del proveedor de hardware incluyen DirectCompute de Microsoft y OpenCL de Apple/Khronos Group . [ 12 ] Esto significa que las modernas canalizaciones GPGPU pueden aprovechar la velocidad de una GPU sin requerir una conversión completa y explícita de los datos a un formato gráfico.

Mark Harris, fundador de GPGPU.org, afirma haber acuñado el término GPGPU . [ 13 ]

Implementaciones

Bibliotecas de software y API

Cualquier lenguaje que permita que el código que se ejecuta en la CPU consulte a un sombreador de GPU para obtener valores de retorno, puede crear un marco GPGPU. Los estándares de programación para computación paralela incluyen OpenCL (independiente del proveedor), OpenACC , OpenMP y OpenHMPP .

A partir de 2016OpenCL es el lenguaje dominante de computación GPU de propósito general abierto y un estándar abierto definido por el Grupo Khronos . OpenCL proporciona una plataforma GPGPU multiplataforma que, además, admite computación paralela de datos en CPU. OpenCL cuenta con soporte activo en plataformas Intel, AMD, Nvidia y ARM. El Grupo Khronos también ha estandarizado e implementado SYCL , un modelo de programación de alto nivel para OpenCL como un lenguaje embebido específico de dominio de código fuente único basado en C++11 puro.

El marco propietario dominante es Nvidia CUDA . [ 14 ] Nvidia lanzó CUDA en 2006, un kit de desarrollo de software (SDK) y una interfaz de programación de aplicaciones (API) que permite usar el lenguaje de programación C para codificar algoritmos para su ejecución en GPU GeForce serie 8 y posteriores.

ROCm , lanzado en 2016, es la respuesta de código abierto de AMD a CUDA. A fecha de 2022, está a la par con CUDA en cuanto a funcionalidades, pero aún carece de soporte para el consumidor.

OpenVIDIA fue desarrollado en la Universidad de Toronto entre 2003 y 2005, [ 15 ] en colaboración con Nvidia.

Altimesh Hybridizer, creado por Altimesh, compila Common Intermediate Language a binarios CUDA. [ 16 ] [ 17 ] Admite genéricos y funciones virtuales. [ 18 ] La depuración y el análisis de rendimiento están integrados con Visual Studio y Nsight. [ 19 ] Está disponible como extensión de Visual Studio en Visual Studio Marketplace.

Microsoft presentó la API de computación GPU DirectCompute , lanzada junto con la API Direct3D 11 .

Alea GPU , [ 20 ] creada por QuantAlea, [ 21 ] introduce capacidades de computación GPU nativas para los lenguajes F# [ 22 ] yC#de Microsoft .NET. Alea GPU también proporciona un modelo de programación GPU simplificado basado en GPU parallel-for y parallel aggregate mediante delegados y gestión automática de memoria. [ 23 ]

MATLAB admite la aceleración GPGPU mediante Parallel Computing Toolbox y MATLAB Distributed Computing Server , [ 24 ] y paquetes de terceros como Jacket .

El procesamiento GPGPU también se utiliza para simular la física newtoniana mediante motores de física , [ 25 ] y las implementaciones comerciales incluyen Havok Physics, FX y PhysX , ambos utilizados normalmente para juegos de ordenador y videojuegos .

C++ Accelerated Massive Parallelism ( C++ AMP ) es una biblioteca que acelera la ejecución del código C++ aprovechando el hardware de paralelismo de datos en las GPU.

Computadoras móviles

Debido a la tendencia al aumento de la potencia de las GPU móviles, la programación de propósito general también se hizo disponible en los dispositivos móviles que ejecutan los principales sistemas operativos móviles .

Google Android 4.2 permitió ejecutar código RenderScript en la GPU del dispositivo móvil. [ 26 ] Desde entonces, RenderScript ha sido obsoleto en favor de los sombreadores de cómputo OpenGL [ 27 ] y posteriormente de Vulkan Compute. [ 28 ] OpenCL está disponible en muchos dispositivos Android, pero no cuenta con el soporte oficial de Android. [ 29 ] Apple introdujo la API propietaria Metal para aplicaciones iOS , capaz de ejecutar código arbitrario a través de los sombreadores de cómputo de la GPU de Apple.

GPU vs. CPU

Originalmente, los datos se transmitían simplemente en una dirección desde una unidad central de procesamiento (CPU) a una unidad de procesamiento gráfico (GPU), y luego a un dispositivo de visualización . Sin embargo, con el tiempo, se volvió valioso para las GPU almacenar, primero simples y luego complejas, estructuras de datos para ser devueltas a la CPU que analizaba una imagen o un conjunto de datos científicos representados en un formato 2D o 3D que una tarjeta de video puede entender. Debido a que la GPU tiene acceso a cada operación de dibujo, puede analizar los datos en estos formatos rápidamente, mientras que una CPU debe sondear cada píxel o elemento de datos mucho más lentamente, ya que la velocidad de acceso entre una CPU y su mayor cantidad de memoria de acceso aleatorio (o, en un caso aún peor, un disco duro ) es más lenta que la de las GPU y las tarjetas de video, que generalmente contienen cantidades menores de memoria más costosa a la que se accede mucho más rápido. Transferir la porción del conjunto de datos que se va a analizar activamente a esa memoria de GPU en forma de texturas u otros formatos de GPU fácilmente legibles resulta en un aumento de velocidad. La característica distintiva de un diseño GPGPU es la capacidad de transferir información bidireccionalmente de vuelta de la GPU a la CPU; En general, el rendimiento de datos en ambas direcciones es idealmente alto, lo que produce un efecto multiplicador en la velocidad de un algoritmo específico de uso intensivo .

Las canalizaciones GPGPU pueden mejorar la eficiencia en conjuntos de datos especialmente grandes y/o datos que contienen imágenes 2D o 3D. Se utilizan en canalizaciones gráficas complejas, así como en computación científica ; sobre todo en campos con grandes conjuntos de datos, como el mapeo del genoma , o donde el análisis bidimensional o tridimensional resulta útil , especialmente en el análisis de biomoléculas , el estudio de proteínas y otras áreas complejas de la química orgánica . Un ejemplo de estas aplicaciones es el paquete de software de NVIDIA para el análisis del genoma . 

Estas arquitecturas también pueden mejorar enormemente la eficiencia en el procesamiento de imágenes y la visión artificial , entre otros campos, así como en el procesamiento paralelo en general. Algunas arquitecturas altamente optimizadas han logrado aumentos de velocidad de varios cientos de veces con respecto a la arquitectura original basada en CPU en una tarea de uso intensivo.

Un ejemplo sencillo sería un programa de GPU que recopila datos sobre los valores promedio de iluminación mientras renderiza una vista, ya sea de una cámara o de un programa de gráficos por computadora, y los envía al programa principal en la CPU, para que esta pueda realizar ajustes a la vista general de la pantalla. Un ejemplo más avanzado podría usar la detección de bordes para devolver información numérica y una imagen procesada que represente los contornos a un programa de visión artificial que controle, por ejemplo, un robot móvil. Debido a que la GPU tiene acceso rápido y local al hardware de cada píxel u otro elemento de la imagen, puede analizarla y promediarla (para el primer ejemplo) o aplicar un filtro de bordes Sobel u otro filtro de convolución (para el segundo) con mucha mayor velocidad que una CPU, que normalmente debe acceder a copias de la gráfica en cuestión almacenadas en memoria de acceso aleatorio ( RAM), que son más lentas .

GPGPU, como concepto de software, es un tipo de algoritmo , no un equipo. Sin embargo, los diseños de equipos especializados pueden mejorar aún más la eficiencia de las arquitecturas GPGPU, que tradicionalmente ejecutan relativamente pocos algoritmos en grandes cantidades de datos. Las tareas masivamente paralelizadas con datos gigantescos pueden paralelizarse aún más mediante configuraciones especializadas como la computación en rack (muchas máquinas similares y altamente personalizadas integradas en un rack ), que añade una tercera capa : muchas unidades de computación, cada una con múltiples CPU para corresponder a múltiples GPU. Algunos mineros de Bitcoin utilizaron estas configuraciones para el procesamiento de grandes volúmenes de datos. La lista TOP500 de supercomputadoras ofrece información detallada sobre los sistemas más grandes del mundo . 

Cachés

Históricamente, las CPU han utilizado cachés gestionadas por hardware , pero las primeras GPU solo proporcionaban memorias locales gestionadas por software. Sin embargo, a medida que las GPU se utilizan cada vez más para aplicaciones de propósito general, las GPU de última generación se diseñan con cachés multinivel gestionadas por hardware, lo que ha ayudado a las GPU a avanzar hacia la computación convencional. Por ejemplo, las GPU de la serie GeForce 200 con arquitectura GT200 no contaban con una caché L2, la GPU Fermi  tiene una caché de último nivel de 768 KiB, la GPU Kepler  tiene una caché de último nivel de 1,5 MiB, [ 30 ] la GPU Maxwell tiene una caché de último nivel de 2  MiB y la GPU Pascal  tiene una caché de último nivel de 4 MiB.

Archivo de registro

Las GPU tienen archivos de registro muy grandes , lo que les permite reducir la latencia de cambio de contexto. El tamaño del archivo de registro también está aumentando en las diferentes generaciones de GPU, por ejemplo, el tamaño total del archivo de registro en las GPU Maxwell (GM200), Pascal y Volta es de 6  MiB, 14  MiB y 20  MiB, respectivamente. [ 31 ] [ 32 ] En comparación, el tamaño de un archivo de registro en las CPU es pequeño, típicamente decenas o cientos de kilobytes.

En esencia: casi todas las cargas de trabajo de GPU son inherentemente masivamente paralelas de naturaleza CARGA-COMPUTACIÓN-ALMACENAMIENTO, como la renderización en mosaico . Incluso almacenar un vector temporal para su posterior recuperación (CARGA-COMPUTACIÓN-ALMACENAMIENTO-COMPUTACIÓN-CARGA-COMPUTACIÓN-ALMACENAMIENTO) es tan costoso debido al problema del muro de memoria que debe evitarse a toda costa. [ 33 ] El resultado es que el tamaño del archivo de registros tiene que aumentar. En las CPU estándar es posible introducir cachés (una D-cache ) para resolver este problema, sin embargo, estas son relativamente tan grandes que no es práctico introducirlas en las GPU que necesitarían una por elemento de procesamiento. ILLIAC IV resolvió innovadoramente el problema alrededor de 1967 al introducir una memoria local por elemento de procesamiento (una PEM): una estrategia copiada por el Aspex ASP .

Recursos de ejecución

Las GPGPU difieren enormemente entre sí en la cantidad de recursos de ejecución que se asignan a cada grupo de "núcleos" que realiza un flujo de operaciones, denominados de diversas maneras "multiprocesador de flujo" (SM) por Nvidia, unidad de cómputo (CU) o procesador de grupo de trabajo (WGP) por AMD según la microarquitectura, "Xe Core" por Intel, todos diseñados para realizar lo que OpenCL denomina un "grupo de trabajo" . [ 34 ] De manera similar a como las CPU pueden optar por implementar instrucciones vectoriales más amplias en partes más pequeñas (por ejemplo, AMD Bulldozer admitía las instrucciones AVX de 256 bits dividiéndolas en dos operaciones de 128 bits) para ahorrar energía y/o área del chip, [ 35 ] los diseñadores de GPU también varían la cantidad de unidades de ejecución para ajustarse a sus cargas de trabajo previstas.

En una GPGPU, cada uno de los siguientes recursos puede variar libremente en proporción a los demás: FP64 (FMA), FP32 (FMA), FP16 (FMA), Int32 Add, Int32 Mul, RCP/RSQRT. (Se puede ver un ejemplo en la documentación de Nvidia sobre los recursos de ejecución que se encuentran en cada SM de diferente generación (capacidad de cómputo) de GPU. El FP16 no matricial es manejado por los núcleos FP32. [ 36 ] ) Las GPGPU destinadas a la computación científica a menudo tienen una mayor inversión en FP64, mientras que las diseñadas para el aprendizaje profundo tienden a tener una mayor inversión en FP16, operaciones de enteros "empaquetados" de menor ancho de bits y unidades adicionales dedicadas a la multiplicación de matrices ("unidades de matriz", "núcleos tensoriales"). [ 37 ] [ 38 ]

Por lo tanto, no basta con calificar las capacidades computacionales de una GPU simplemente en términos de FLOPS: los valores de FLOPS deben presentarse por separado para los modos de matriz y no matriz, y las cifras de (T)OPS también deben presentarse para las operaciones con enteros.

eficiencia energética

El alto rendimiento de las GPU conlleva un alto consumo de energía, que bajo carga completa es, de hecho, tanta energía como el resto del sistema de PC combinado. [ 39 ] El consumo máximo de energía de la GPU de la serie Pascal (Tesla P100) se especificó en 250 W. [ 40 ]

En términos de potencia de cálculo bruta (FLOPS, TOPS, etc.), las GPU suelen ofrecer un mayor rendimiento por vatio que una CPU típica. Sin embargo, se requiere un programa bien escrito y una carga de trabajo adecuada para aprovechar al máximo esta potencia, ya que, de lo contrario, la mayor parte del tiempo (y la energía) se desperdiciaría en el acceso a la memoria local y del host.

GPGPU clásica

Antes de que se publicara CUDA en 2007, GPGPU era "clásico" e implicaba la reutilización de primitivas gráficas. Una estructura estándar de este tipo era:

  1. Cargar matrices en texturas
  2. Dibuja un cuadrilátero
  3. Aplicar sombreadores de píxeles y texturas al cuadrilátero
  4. Lee los valores de los píxeles en el cuadrilátero como una matriz.

En la parte 4 de GPU Gems 2 se encuentran más ejemplos . [ 41 ]

Álgebra lineal

El uso de GPU para álgebra lineal numérica comenzó al menos en 2001. [ 42 ] Se había utilizado para el solucionador de Gauss-Seidel, gradientes conjugados, etc. [ 43 ]

Soporte de hardware

Las tarjetas gráficas para ordenador son fabricadas por diversos proveedores, como Nvidia y AMD . Las tarjetas de estos proveedores difieren en la compatibilidad con distintos formatos de datos, como enteros y de coma flotante (32 y 64 bits). Microsoft introdujo el estándar Shader Model para clasificar las distintas características de las tarjetas gráficas mediante un sencillo número de versión (1.0, 2.0, 3.0, etc.).

Números enteros

Las tarjetas de video anteriores a Direct3D 9 solo admitían colores con paleta o enteros. A veces se agrega otro valor alfa para usarlo con transparencia. Los formatos comunes son:

  • 8 bits por píxel: a veces se utiliza el modo paleta, donde cada valor es un índice en una tabla con el valor de color real especificado en uno de los otros formatos. A veces se utilizan tres bits para el rojo, tres bits para el verde y dos bits para el azul.
  • 16 bits por píxel: normalmente, los bits se asignan de la siguiente manera: cinco bits para el rojo, seis bits para el verde y cinco bits para el azul.
  • 24 bits por píxel: hay ocho bits para cada uno de los colores rojo, verde y azul.
  • 32 bits por píxel: hay ocho bits para cada uno de los colores rojo, verde, azul y alfa .

Números de punto flotante

Para las primeras tarjetas gráficas de función fija o programabilidad limitada (es decir, GPU compatibles con Direct3D 8.1 inclusive), esto era suficiente, ya que también es la representación utilizada en las pantallas. Sin embargo, esta representación tiene ciertas limitaciones. Con suficiente potencia de procesamiento gráfico, incluso los programadores gráficos desearían utilizar formatos mejores, como los formatos de datos de punto flotante , para obtener efectos como imágenes de alto rango dinámico . Muchas aplicaciones GPGPU requieren precisión de punto flotante, que venía incluida con las tarjetas de video compatibles con la especificación Direct3D 9.

Direct3D 9 Shader Model 2.x sugería la compatibilidad con dos tipos de precisión: precisión completa y precisión parcial. La precisión completa podía ser FP32 o FP24 (punto flotante de 32 o 24 bits por componente) o superior, mientras que la precisión parcial era FP16. La serie Radeon R300 de GPU de ATI solo admitía precisión FP24 en la canalización de fragmentos programable (aunque FP32 era compatible con los procesadores de vértices), mientras que la serie NV30 de Nvidia admitía tanto FP16 como FP32; otros proveedores, como S3 Graphics y XGI, admitían una combinación de formatos de hasta FP24.

Las implementaciones de punto flotante en las GPU de Nvidia son en su mayoría compatibles con IEEE ; sin embargo, esto no se aplica a todos los fabricantes. [ 44 ] Esto tiene implicaciones para la precisión, consideradas importantes para algunas aplicaciones científicas. Si bien los valores de punto flotante de 64 bits (doble precisión) están comúnmente disponibles en las CPU, no son compatibles universalmente con las GPU. Algunas arquitecturas de GPU sacrifican la compatibilidad con IEEE, mientras que otras carecen de doble precisión. Se han realizado esfuerzos para emular valores de punto flotante de doble precisión en las GPU; sin embargo, la pérdida de velocidad anula cualquier beneficio de descargar el cálculo a la GPU. [ 45 ]

Vectorización

La mayoría de las operaciones en la GPU funcionan de forma vectorizada: una operación puede aplicarse a hasta cuatro valores simultáneamente. Por ejemplo, si se desea modular un color R1, G1, B1 ⟩ con otro color R2, G2, B2 , la GPU puede generar el color resultante R1*R2, G1*G2, B1*B2 en una sola operación. Esta funcionalidad resulta útil en gráficos porque casi todos los tipos de datos básicos son vectores (de 2, 3 o 4 dimensiones). Algunos ejemplos son los vértices, los colores, los vectores normales y las coordenadas de textura.

Procesamiento de flujos

Las GPU se diseñaron originalmente para gráficos, por lo que presentan limitaciones en cuanto a operaciones y programación. Debido a su diseño, las GPU solo son efectivas para problemas que pueden resolverse mediante procesamiento de flujos de datos , y su hardware solo puede utilizarse de ciertas maneras.

En los inicios de la era GPGPU, las GPU solo podían procesar vértices y fragmentos de forma independiente, pero podían procesar muchos de ellos en paralelo. Esto resultaba especialmente eficaz cuando el programador deseaba procesar varios vértices o fragmentos simultáneamente. En este sentido, las GPU son procesadores de flujo : procesadores que pueden operar en paralelo ejecutando un kernel sobre múltiples registros de un flujo a la vez. Los programadores utilizaban API gráficas ( OpenGL o Direct3D ) para realizar cálculos de propósito general. 

Con la introducción de las API de computación de propósito general CUDA (Nvidia, 2007) y OpenCL (independiente del proveedor, 2008), en los nuevos códigos GPGPU ya no es necesario asignar el cálculo a primitivas gráficas. La naturaleza de procesamiento de flujo de las GPU sigue siendo válida independientemente de las API utilizadas. (Véase, por ejemplo, [ 46 ] ).

Un flujo de datos es simplemente un conjunto de registros que requieren cálculos similares. Los flujos proporcionan paralelismo de datos. Los kernels son las funciones que se aplican a cada elemento del flujo. En las GPU, los vértices y los fragmentos son los elementos de los flujos, y los sombreadores de vértices y fragmentos son los kernels que se ejecutan sobre ellos. Para cada elemento, solo podemos leer de la entrada, realizar operaciones sobre él y escribir en la salida. Es posible tener múltiples entradas y múltiples salidas, pero nunca una porción de memoria que sea a la vez legible y escribible.

La intensidad aritmética se define como el número de operaciones realizadas por palabra de memoria transferida. Es importante que las aplicaciones GPGPU tengan una alta intensidad aritmética, ya que de lo contrario la latencia de acceso a la memoria limitará la aceleración computacional. [ 47 ]

Las aplicaciones GPGPU ideales cuentan con grandes conjuntos de datos, alto paralelismo y una dependencia mínima entre los elementos de datos.

conceptos de programación de GPU

Recursos computacionales

La GPU dispone de diversos recursos computacionales:

  • Los procesadores programables (vertex, primitivos, fragmentos y principalmente pipelines de cómputo) permiten al programador ejecutar kernels en flujos de datos.
  • Rasterizador: crea fragmentos e interpola constantes por vértice, como coordenadas de textura y color.
  • Unidad de textura: interfaz de memoria de solo lectura
  • Framebuffer: interfaz de memoria de solo escritura

De hecho, un programa puede sustituir el framebuffer por una textura de solo escritura para la salida. Esto se realiza mediante renderizado a textura (RTT), renderizado a copia de backbuffer a textura (RTBCTT) o el método más reciente de flujo de salida.

Texturas como flujo

La forma más común que puede adoptar un flujo de datos en GPGPU es una cuadrícula 2D, ya que se ajusta de forma natural al modelo de renderizado integrado en las GPU. Muchos cálculos se adaptan naturalmente a las cuadrículas: álgebra matricial, procesamiento de imágenes, simulación basada en la física, etc.

Dado que las texturas se utilizan como memoria, las búsquedas de texturas se utilizan como lecturas de memoria. Gracias a esto, la GPU puede realizar ciertas operaciones automáticamente.

Núcleos de cálculo

Los núcleos de cómputo pueden considerarse como el cuerpo de bucles . Por ejemplo, un programador que opera en una cuadrícula en la CPU podría tener un código similar a este:

// Las cuadrículas de entrada y salida tienen 10000 x 10000 o 100 millones de elementos.void transform_10k_by_10k_grid ( float in [ 10000 ][ 10000 ], float out [ 10000 ][ 10000 ]) { for ( int x = 0 ; x < 10000 ; x ++ ) { for ( int y = 0 ; y < 10000 ; y ++ ) { // La siguiente línea se ejecuta 100 millones de veces out [ x ][ y ] = do_some_hard_work ( in [ x ][ y ]); } } }

En la GPU, el programador solo especifica el cuerpo del bucle como el núcleo y qué datos recorrer invocando el procesamiento de geometría.

Control de flujo

Para obtener información técnica precisa sobre este tema, consulte Predication_(computer_architecture)#SIMD,_SIMT_and_vector_predication e ILLIAC IV "ramching" (el término "máscara de predicado" no existía en 1967).

En el código secuencial es posible controlar el flujo del programa mediante sentencias if-then-else y diversos bucles. Estas estructuras de control de flujo están disponibles en las GPU. [ 48 ] Se podían realizar escrituras condicionales mediante una serie de operaciones aritméticas/bits diseñadas adecuadamente, pero no era posible realizar bucles ni bifurcaciones condicionales.

Las GPU recientes permiten ramificaciones, pero generalmente con una penalización en el rendimiento. Por lo general, se deben evitar las ramificaciones en los bucles internos, ya sea en el código de la CPU o de la GPU, y se pueden utilizar varios métodos, como la resolución estática de ramificaciones, el preprocesamiento, la predicción, la división de bucles [ 49 ] y la eliminación de Z [ 50 ], para lograr ramificaciones cuando no existe soporte de hardware.

métodos de GPU

Mapa

La operación de mapeo simplemente aplica la función dada (el núcleo) a cada elemento del flujo. Un ejemplo sencillo es multiplicar cada valor del flujo por una constante (aumentando el brillo de una imagen). La operación de mapeo es fácil de implementar en la GPU. El programador genera un fragmento para cada píxel en pantalla y aplica un programa de fragmento a cada uno. El flujo resultante, del mismo tamaño, se almacena en el búfer de salida.

Reducir

Algunos cálculos requieren obtener una secuencia más pequeña (posiblemente de un solo elemento) a partir de una secuencia más grande. Esto se denomina reducción de la secuencia. Generalmente, la reducción se puede realizar en varios pasos. Los resultados del paso anterior se utilizan como entrada para el paso actual y el rango sobre el que se aplica la operación se reduce hasta que solo queda un elemento de la secuencia.

Filtrado de flujo

El filtrado de flujos de datos es esencialmente una reducción no uniforme. El filtrado implica eliminar elementos del flujo en función de ciertos criterios.

Escanear

La operación de escaneo, también denominada suma de prefijo paralela , toma como entrada un vector (flujo) de elementos de datos y una función binaria asociativa (arbitraria) '+' con un elemento identidad 'i' . Si la entrada es [a0, a1, a2, a3, ...], un escaneo exclusivo produce la salida [i, a0, a0 + a1, a0 + a1 + a2, ...], mientras que un escaneo inclusivo produce la salida [a0, a0 + a1, a0 + a1 + a2, a0 + a1 + a2 + a3, ...] y no requiere la existencia de un elemento identidad. Si bien a primera vista la operación puede parecer inherentemente serial, existen algoritmos de escaneo paralelo eficientes que se han implementado en unidades de procesamiento gráfico. La operación de escaneo tiene aplicaciones, por ejemplo, en el algoritmo Quicksort y en la multiplicación de matrices dispersas por vectores. [ 46 ] [ 51 ] [ 52 ] [ 53 ]

Dispersión

La operación de dispersión se define de forma más natural en el procesador de vértices. Este procesador permite ajustar la posición del vértice , lo que posibilita al programador controlar dónde se deposita la información en la cuadrícula. También son posibles otras extensiones, como controlar el área que afecta el vértice.

El procesador de fragmentos no puede realizar una operación de dispersión directa, ya que la ubicación de cada fragmento en la cuadrícula es fija desde su creación y el programador no puede modificarla. Sin embargo, en ocasiones, una operación de dispersión lógica puede reformularse o implementarse con un paso de recopilación adicional. Una implementación de dispersión primero emitiría un valor de salida y una dirección de salida. Una operación de recopilación posterior utiliza comparaciones de direcciones para determinar si el valor de salida se corresponde con la ranura de salida actual.

En los núcleos de cómputo dedicados , la dispersión se puede realizar mediante escrituras indexadas.

Recolectar

La operación de recolección (gather) es la inversa de la de dispersión (scatter). Después de que la dispersión reordena los elementos según un mapa, la recolección puede restaurar el orden de los elementos según el mapa utilizado por la dispersión. En los núcleos de cómputo dedicados, la recolección puede realizarse mediante lecturas indexadas. En otros sombreadores, se realiza mediante búsquedas de texturas.

Clasificar

La operación de ordenación transforma un conjunto desordenado de elementos en un conjunto ordenado. La implementación más común en GPU utiliza la ordenación por radix para datos enteros y de punto flotante, y la ordenación por fusión de grano grueso y las redes de ordenación de grano fino para datos comparables generales. [ 54 ] [ 55 ]

La operación de búsqueda permite al programador encontrar un elemento determinado dentro del flujo de datos, o bien encontrar elementos vecinos de un elemento específico. Generalmente, el método de búsqueda utilizado es la búsqueda binaria sobre elementos ordenados.

Estructuras de datos

En la GPU se pueden representar diversas estructuras de datos:

Aplicaciones

A continuación se presentan algunas de las áreas en las que se han utilizado las GPU para la computación de propósito general:

Bioinformática

Uso de GPGPU en bioinformática: [ 71 ] [ 96 ]

Dinámica molecular

  1. 1 2 Las mejoras de velocidad esperadas dependen en gran medida de la configuración del sistema. El rendimiento de la GPU se compara con el de un socket de CPU x86 multinúcleo. El rendimiento de la GPU se evalúa en las funciones compatibles con la GPU y puede tratarse de una comparación de rendimiento entre núcleos . Para obtener más información sobre la configuración utilizada, consulte el sitio web de la aplicación. Las mejoras de velocidad se basan en las pruebas internas de Nvidia o en la documentación del proveedor de software independiente (ISV).
  2. 1 2 Q= GPU Quadro , T= GPU Tesla . GPU recomendadas por Nvidia para esta aplicación. Consulta con el desarrollador o el proveedor de software independiente para obtener información sobre la certificación.

Véase también

Referencias

  1. Fung, James; Tang, Felix; Mann, Steve (7–10 de octubre de 2002). Realidad mediada mediante hardware de gráficos por computadora para visión artificial (PDF) . Actas del Simposio Internacional sobre Computación Portátil 2002 (ISWC2002). Seattle, Washington, EE. UU. págs. 83–89 . Archivado del original (PDF) el 2 de abril de 2012. 
  2. Aimone, Chris; Fung, James; Mann, Steve (2003). " Estimación de movimiento proyectivo sin características basada en video Eye Tap asistida por seguimiento giroscópico para realidad mediada por computadora portátil" . Personal and Ubiquitous Computing . 7 (5): 236– 248. doi : 10.1007/s00779-003-0239-6 . S2CID 25168728 . 
  3. "Procesamiento de señales de visión por computadora en unidades de procesamiento gráfico", Actas de la Conferencia Internacional IEEE sobre Acústica, Habla y Procesamiento de Señales (ICASSP 2004). Archivado el 19 de agosto de 2011 en Wayback Machine : Montreal, Quebec, Canadá, 17-21 de mayo de 2004, págs. V-93-V-96.
  4. Chitty, DM (2007, julio). Un enfoque de paralelismo de datos para la programación genética utilizando hardware gráfico programable. Archivado el 8 de agosto de 2017 en Wayback Machine . En Actas de la 9.ª conferencia anual sobre computación genética y evolutiva (págs. 1566-1573). ACM.
  5. "Uso de múltiples tarjetas gráficas como computadora paralela de propósito general: aplicaciones a la visión por computadora", Actas de la 17.ª Conferencia Internacional sobre Reconocimiento de Patrones (ICPR2004) Archivado el 18 de julio de 2011 en Wayback Machine , Cambridge, Reino Unido, 23-26 de agosto de 2004, volumen 1, páginas 805-808.
  6. Hull, Gerald (diciembre de 1987). "LIFE" . Amazing Computing . 2 (12): 81– 84.
  7. Krüger, Jens; Westermann, Rüdiger (julio de 2003). "Operadores de álgebra lineal para la implementación en GPU de algoritmos numéricos" . ACM Transactions on Graphics . 22 (3): 908–916 . doi : 10.1145/882262.882363 . ISSN 0730-0301 . 
  8. Bolz, Jeff; Farmer, Ian; Grinspun, Eitan; Schröder, Peter (julio de 2003). "Solucionadores de matrices dispersas en la GPU: gradientes conjugados y multigrid" . ACM Transactions on Graphics . 22 (3): 917–924 . doi : 10.1145/882262.882364 . ISSN 0730-0301 . 
  9. Tarditi, David; Puri, Sidd; Oglesby, Jose (2006). "Acelerador: uso del paralelismo de datos para programar GPU para usos de propósito general" (PDF) . ACM SIGARCH Computer Architecture News . 34 (5). doi : 10.1145/1168919.1168898 .
  10. ^ Che, Shuai; Boyer, Michael; Meng, Jiayuan; Tarjan, D.; Sheaffer, Jeremy W.; Skadron, Kevin (2008). "Un estudio de rendimiento de aplicaciones de uso general en procesadores gráficos que utilizan CUDA". J. Computación Paralela y Distribuida . 68 (10): 1370–1380 . CiteSeerX 10.1.1.143.4849 . doi : 10.1016/j.jpdc.2008.05.014 . 
  11. Glaser, J.; Nguyen, TD; Anderson, JA; Lui, P.; Spiga, F.; Millan, JA; Morse, DC; Glotzer, SC (2015). "Escalado fuerte de simulaciones de dinámica molecular de propósito general en GPU" . Computer Physics Communications . 192 : 97–107 . arXiv : 1412.3387 . Bibcode : 2015CoPhC.192...97G . doi : 10.1016/j.cpc.2015.02.028 .
  12. 1 2 Du, Peng; Weber, Rick; Luszczek, Piotr; Tomov, Stanimire; Peterson, Gregory; Dongarra, Jack (2012). "De CUDA a OpenCL: hacia una solución de rendimiento portátil para la programación de GPU multiplataforma". Computación paralela . 38 (8): 391– 407. Bibcode : 2012ParC...38..391D . CiteSeerX 10.1.1.193.7712 . doi : 10.1016/j.parco.2011.10.002 . 
  13. Harris, Mark (25 de enero de 2017). "Una introducción aún más fácil a CUDA" . Nvidia . Recuperado el 16 de febrero de 2025 .
  14. "OpenCL gana terreno a CUDA" . 28 de febrero de 2012. Archivado del original el 23 de abril de 2012. Consultado el 10 de abril de 2012 ."Como los dos principales marcos de programación para la computación con GPU, OpenCL y CUDA han estado compitiendo por captar la atención de la comunidad de desarrolladores durante los últimos años."
  15. Fung, James; Mann, Steve ; Aimone, Chris (6–11 de noviembre de 2005). «OpenVIDIA: Visión artificial paralela con GPU» (PDF) . Actas de la 13.ª conferencia internacional anual de la ACM sobre multimedia . Singapur: Association for Computing Machinery (publicado el 6 de noviembre de 2005). págs. 849–852 . doi : 10.1145/1101149.1101334 . ISBN  1595930442Archivado del original (PDF) el 23 de diciembre de 2019. Consultado el 18 de marzo de 2025 .
  16. "Hybridizer" . Hibridizer . Archivado del original el 17 de octubre de 2017.
  17. "Página principal" . Altimesh . Archivado del original el 17 de octubre de 2017.
  18. "Genéricos hibridadores y herencia" . 27 de julio de 2017. Archivado del original el 17 de octubre de 2017.
  19. "Depuración y creación de perfiles con Hybridizer" . 5 de junio de 2017. Archivado del original el 17 de octubre de 2017.
  20. "Introducción" . GPU Alea . Archivado del original el 25 de diciembre de 2016. Consultado el 15 de diciembre de 2016 .
  21. "Página principal" . Quant Alea . Archivado del original el 12 de diciembre de 2016. Consultado el 15 de diciembre de 2016 .
  22. "Use F# for GPU Programming" . F# Software Foundation. Archivado del original el 18 de diciembre de 2016. Consultado el 15 de diciembre de 2016 .
  23. "Características de la GPU Alea" . Quant Alea . Archivado del original el 21 de diciembre de 2016. Consultado el 15 de diciembre de 2016 .
  24. "MATLAB añade compatibilidad con GPGPU" . 20 de septiembre de 2010. Archivado del original el 27 de septiembre de 2010.
  25. 1 2 Joselli, Mark; Clua, Esteban; Montenegro, Anselmo; Conci, Aura; Pagliosa, Paulo (2008). "Un nuevo motor de física con distribución automática de procesos entre CPU y GPU" . Actas del simposio ACM SIGGRAPH 2008 sobre videojuegos . págs. 149–156 . doi : 10.1145/1401843.1401871 . ISBN  978-1-60558-173-6.
  26. "API de Android 4.2 - Desarrolladores de Android" . developer.android.com . Archivado del original el 26 de agosto de 2013.
  27. "Migrar scripts a OpenGL ES 3.1" .
  28. "Migrar scripts a Vulkan" .
  29. McIntosh-Smith, Simon (15 de julio de 2020). "Poniéndonos al día con Khronos: Preguntas y respuestas de expertos sobre OpenCL 3.0 y SYCL 2020" . The Khronos Group . Consultado el 16 de febrero de 2025 .
  30. "Nvidia-Kepler-GK110-Architecture-Whitepaper" (PDF) . Archivado (PDF) del original el 21 de febrero de 2015.
  31. " Dentro de Pascal: la plataforma informática más reciente de Nvidia" Archivado el 7 de mayo de 2017 en Wayback Machine "
  32. " Dentro de Volta: La GPU para centros de datos más avanzada del mundo " Archivado el 1 de enero de 2020 en Wayback Machine "
  33. Li, Jie; Michelogiannakis, George; Cook, Brandon; Cooray, Dulanya; Chen, Yong (2023). "Análisis de la utilización de recursos en un sistema HPC: un estudio de caso de Perlmutter de NERSC" . Computación de alto rendimiento . Notas de clase en ciencias de la computación. Vol. 13948. págs. 297–316 . doi : 10.1007/978-3-031-32041-5_16 . ISBN   978-3-031-32040-8.
  34. "Guía de mejores prácticas de OpenCL" (PDF) . Nvidia . 2011.
  35. Lam, Chester. "AMD's Zen 4 Parte 1: Frontend y motor de ejecución" . chipsandcheese.com .
  36. "Guía de programación CUDA C++ — Guía de programación CUDA C++" . docs.nvidia.com .
  37. Lam, Chester. "Arquitectura de computación CDNA 3 de AMD" . chipsandcheese.com .
  38. Lam, Chester. "Radeon Instinct MI210 de AMD: GCN sigue vivo" . chipsandcheese.com .
  39. " https://www.tomshardware.com/reviews/geforce-radeon-power,2122.html ¿Cuánta potencia necesita tu tarjeta gráfica?"
  40. " https://images.nvidia.com/content/tesla/pdf/nvidia-tesla-p100-PCIe-datasheet.pdf Acelerador GPU Nvidia Tesla P100 Archivado el 24 de julio de 2018 en Wayback Machine "
  41. Pharr, Matt, ed. (2006). «Parte IV: Computación de propósito general en GPU: una introducción» . GPU gems 2: técnicas de programación para gráficos de alto rendimiento y computación de propósito general (3.ª ed. impresa). Upper Saddle River, NJ Múnich: Addison-Wesley. ISBN  978-0-321-33559-3.
  42. Larsen, E. Scott; McAllister, David (10 de noviembre de 2001). «Multiplicaciones rápidas de matrices mediante hardware gráfico» . Actas de la conferencia ACM/IEEE de 2001 sobre supercomputación . ACM. pág. 55. doi : 10.1145/582034.582089 . ISBN  978-1-58113-293-9.
  43. Krüger, Jens; Westermann, Rüdiger (2005). "Operadores de álgebra lineal para la implementación en GPU de algoritmos numéricos" . Cursos de ACM SIGGRAPH 2005 - SIGGRAPH '05 . ACM Press. pág. 234. doi : 10.1145/1198555.1198795 . 
  44. Harris, Mark (2005). "Mapeo de conceptos computacionales a GPU" . Cursos de ACM SIGGRAPH 2005 - SIGGRAPH '05 . págs. 50–es. doi : 10.1145/1198555.1198768 . ISBN  9781450378338. S2CID 8212423 . 
  45. Doble precisión en GPU (Actas de ASIM 2005) Archivado el 21 de agosto de 2014 en Wayback Machine : Dominik Goddeke, Robert Strzodka y Stefan Turek. Aceleración de simulaciones de doble precisión (FEM) con (GPU). Actas de ASIM 2005 18.º Simposio sobre Técnicas de Simulación, 2005. 
  46. ^ "D. Göddeke, 2010. Solucionadores de redes múltiples de elementos finitos rápidos y precisos para simulaciones de PDE en clústeres de GPU. Tesis doctoral, Technischen Universität Dortmund" . Archivado desde el original el 16 de diciembre de 2014.
  47. Asanovic, K.; Bodik, R.; Demmel, J .; Keaveny, T.; Keutzer, K.; Kubiatowicz, J.; Morgan, N.; Patterson, D.; Sen, K.; Wawrzynek, J.; Wessel, D.; Yelick, K. (2009). "Una visión del panorama de la computación paralela" . Commun. ACM . 52 (10): 56– 67. doi : 10.1145/1562764.1562783 .
  48. "Capítulo 34. Modismos de control de flujo de GPU" . NVIDIA Developer .
  49. Future Chips . "Tutorial sobre cómo eliminar ramas", 2011
  50. Artículo de revisión sobre GPGPU archivado el 4 de enero de 2007 en Wayback Machine : John D. Owens, David Luebke, Naga Govindaraju, Mark Harris, Jens Krüger, Aaron E. Lefohn y Tim Purcell. "Una revisión de la computación de propósito general en hardware gráfico". Computer Graphics Forum, volumen 26, número 1, 2007, págs. 80-113.
  51. "S. Sengupta, M. Harris, Y. Zhang, JD Owens, 2007. Primitivas de escaneo para computación GPU. En T. Aila y M. Segal (eds.): Hardware gráfico (2007)" . Archivado del original el 5 de junio de 2015. Recuperado el 16 de diciembre de 2014 .
  52. Blelloch, GE (1989). "Scans as primitive parallel operations" (PDF) . IEEE Transactions on Computers . 38 (11): 1526– 1538. Bibcode : 1989ITCmp..38.1526B . doi : 10.1109/12.42122 . Archivado del original (PDF) el 23 de septiembre de 2015. Recuperado el 16 de diciembre de 2014 .
  53. "Capítulo 39. Suma de prefijos paralela (escaneo) con CUDA" . NVIDIA Developer .
  54. Merrill, Duane. Diseño de algoritmos orientados a la asignación con aplicación a la computación en GPU . Tesis doctoral, Departamento de Ciencias de la Computación, Universidad de Virginia. Diciembre de 2011.
  55. Sean Baxter. GPU moderna. Archivado el 7 de octubre de 2016 en Wayback Machine , 2013.
  56. Leung, Alan, Ondřej Lhoták y Ghulam Lashari. « Paralelización automática para unidades de procesamiento gráfico ». Actas de la 7.ª Conferencia Internacional sobre Principios y Práctica de la Programación en Java. ACM, 2009.
  57. Henriksen, Troels, Martin Elsman y Cosmin E. Oancea. « Segmentación por tamaño: un enfoque híbrido para la inferencia de tamaño en futhark ». Actas del 3er taller ACM SIGPLAN sobre computación funcional de alto rendimiento. ACM, 2014.
  58. ^ Baskaran, Muthu Manikandan; Bondhugula, Uday; Krishnamoorthy, Sriram; Ramanujam, J.; Rountev, Atanas; Sadayappan, P. (2008). "Un marco de compilación para la optimización de nidos de bucles afines para gpgpus" . Actas de la 22ª conferencia internacional anual sobre supercomputación - ICS '08 . pag. 225.doi : 10.1145 /1375527.1375562 . ISBN  9781605581583. S2CID 6137960 . 
  59. "Capítulo 30. Simulación y renderizado en tiempo real de fluidos 3D" . NVIDIA Developer .
  60. "M. Harris, 2004. Simulación rápida de dinámica de fluidos en la GPU. En Nvidia: GPU Gems, Capítulo 38" . NVIDIA Developer . Archivado del original el 7 de octubre de 2017.
  61. Block, Benjamin; Virnau, Peter; Preis, Tobias (2010). "Simulaciones Monte Carlo multiespín aceleradas por múltiples GPU del modelo de Ising 2D". Computer Physics Communications . 181 (9): 1549– 1556. arXiv : 1007.3726 . Bibcode : 2010CoPhC.181.1549B . doi : 10.1016/j.cpc.2010.05.005 . S2CID 14828005 . 
  62. Boyle, Peter. "Nuevas tendencias computacionales en la teoría de gauge reticular" (PDF) . Laboratorio Nacional Lawrence Berkeley . Consultado el 16 de febrero de 2025 .
  63. Sun, S.; Bauer, C.; Beichel, R. (2011). "Segmentación 3D automatizada de pulmones con cáncer de pulmón en datos de TC mediante un nuevo enfoque de modelo de forma activa robusta" . IEEE Transactions on Medical Imaging . 31 (2): 449– 460. doi : 10.1109/TMI.2011.2171357 . PMC 3657761. PMID 21997248 .  
  64. Jiménez, Edward S., y Laurel J. Orr. « Repensando la unión de la reconstrucción por tomografía computarizada y la computación GPGPU ». Penetrating Radiation Systems and Applications XIV. Vol. 8854. Sociedad Internacional de Óptica y Fotónica, 2013.
  65. Sorensen, TS; Schaeffter, T.; Noe, KO; Hansen, MS (2008). "Aceleración de la transformada rápida de Fourier no equiespaciada en hardware gráfico comercial" . IEEE Transactions on Medical Imaging . 27 (4): 538– 547. Bibcode : 2008ITMI...27..538S . doi : 10.1109/TMI.2007.909834 . PMID 18390350. S2CID 206747049 .  
  66. Garcia, Vincent; Debreuve, Eric; Barlaud, Michel (2008). "Búsqueda rápida de k vecinos más cercanos usando GPU". arXiv : 0804.1448 [ cs.CV ].
  67. Cococcioni, Marco; Grasso, Raffaele; Rixen, Michel (2011). «Prototipado rápido de aplicaciones de computación difusa de alto rendimiento mediante programación GPU de alto nivel para el apoyo a operaciones marítimas» . Simposio IEEE de 2011 sobre Inteligencia Computacional para Aplicaciones de Seguridad y Defensa (CISDA) . págs. 17-23 . doi : 10.1109/CISDA.2011.5945947 . ISBN  978-1-4244-9939-7. S2CID 2089441 . 
  68. Whalen, Sean (10 de marzo de 2005). Audio y la unidad de procesamiento gráfico . CiteSeerX 10.1.1.114.365 . 
  69. Wilson, Ron (3 de septiembre de 2009). "DSP te trae un paseo lunar en alta definición" . EDN . Consultado el 3 de septiembre de 2009. Según se informa , Lowry está utilizando GPU (unidades de procesamiento gráfico) Nvidia Tesla programadas en la arquitectura CUDA (Compute Unified Device Architecture) de la compañía para implementar los algoritmos. Nvidia afirma que las GPU son aproximadamente dos órdenes de magnitud más rápidas que los cálculos de la CPU, lo que reduce el tiempo de procesamiento a menos de un minuto por fotograma.{{cite news}}: CS1 maint: servicio de archivado obsoleto ( enlace )
  70. Alerstam, E.; Svensson, T.; Andersson-Engels, S. (2008). "Computación paralela con unidades de procesamiento gráfico para simulación Monte Carlo de alta velocidad de migración de fotones" ( PDF) . Journal of Biomedical Optics . 13 (6): 060504. Bibcode : 2008JBO....13f0504A . doi : 10.1117/1.3041496 . PMID 19123645. Archivado (PDF) del original el 9 de agosto de 2011. 
  71. 1 2 3 Hasan, Khondker S.; Chatterjee, Amlan; Radhakrishnan, Sridhar; Antonio, John K. (2014). "Modelo y análisis de predicción de rendimiento para tareas computacionalmente intensivas en GPU" (PDF) . Ingeniería avanzada de sistemas de información (PDF) . Notas de clase en ciencias de la computación. Vol. 7908. págs. 612–617 . doi : 10.1007/978-3-662-44917-2_65 . ISBN   978-3-642-38708-1.
  72. "Física computacional con GPU: Observatorio de Lund" . www.astro.lu.se . Archivado del original el 12 de julio de 2010.
  73. "Cómo funciona GIMPS" . Great Internet Mersenne Prime Search . Consultado el 6 de marzo de 2025 .
  74. Schatz, Michael C; Trapnell, Cole; Delcher, Arthur L; Varshney, Amitabh (2007). "Alineación de secuencias de alto rendimiento mediante unidades de procesamiento gráfico" . BMC Bioinformatics . 8 474. doi : 10.1186/1471-2105-8-474 . PMC 2222658. PMID 18070356 .  
  75. Svetlin A. Manavski; Giorgio Valle (2008). "Tarjetas GPU compatibles con CUDA como aceleradores de hardware eficientes para el alineamiento de secuencias de Smith-Waterman" . BMC Bioinformatics . 9 (Supl. 2): S10. doi : 10.1186/1471-2105-9-s2-s10 . PMC 2323659. PMID 18387198 .  
  76. Olejnik, M; Steuwer, M; Gorlatch, S; Heider, D (15 de noviembre de 2014). "gCUP: predicción rápida del uso del correceptor del VIH-1 basada en GPU para la secuenciación de próxima generación" . Bioinformatics . 30 (22): 3272–3 . doi : 10.1093/bioinformatics/btu535 . PMID 25123901 . 
  77. Wang, Guohui, et al. " Aceleración de algoritmos de visión artificial mediante el marco OpenCL en la GPU móvil: un estudio de caso ". Conferencia Internacional IEEE de 2013 sobre Acústica, Habla y Procesamiento de Señales. IEEE, 2013.
  78. Boyer, Vincent; El Baz, Didier (2013). «Avances recientes en computación GPU en investigación operativa» . Simposio Internacional IEEE de Procesamiento Paralelo y Distribuido de 2013, Talleres y Foro de Doctorado (PDF) . págs. 1778–1787 . doi : 10.1109/IPDPSW.2013.45 . ISBN  978-0-7695-4979-8. S2CID 2774188 . 
  79. Bukata, Libor; Sucha, Premysl; Hanzalek, Zdenek (2014). "Resolución del problema de programación de proyectos con restricciones de recursos mediante la búsqueda tabú paralela diseñada para la plataforma CUDA". Journal of Parallel and Distributed Computing . 77 : 58–68 . arXiv : 1711.04556 . doi : 10.1016/j.jpdc.2014.11.005 . S2CID 206391585 . 
  80. Bäumelt, Zdeněk; Dvořák, Jan; Šůcha, Přemysl; Hanzálek, Zdeněk (2016). "Un enfoque novedoso para la reorganización de enfermeras basado en un algoritmo paralelo". Revista europea de investigación operativa . 251 (2): 624– 639. doi : 10.1016/j.ejor.2015.11.022 .
  81. CTU-IIG Archivado el 9 de enero de 2016 en Wayback Machine Universidad Técnica Checa de Praga, Grupo de Informática Industrial (2015).
  82. NRRPGpu Archivado el 9 de enero de 2016 en Wayback Machine Universidad Técnica Checa en Praga, Grupo de Informática Industrial (2015).
  83. Naju Mancheril. "Ordenación basada en GPU en PostgreSQL" (PDF) . Escuela de Ciencias de la Computación – Universidad Carnegie Mellon . Archivado (PDF) del original el 2 de agosto de 2011.
  84. Manavski, Svetlin A. " GPU compatible con CUDA como acelerador de hardware eficiente para criptografía AES. Archivado el 7 de mayo de 2019 en Wayback Machine ". Conferencia Internacional IEEE de 2007 sobre Procesamiento de Señales y Comunicaciones. IEEE, 2007.
  85. Harrison, Owen; Waldron, John (2007). "Implementación y análisis del cifrado AES en unidades de procesamiento gráfico comerciales". Hardware criptográfico y sistemas embebidos - CHES 2007. Notas de clase en ciencias de la computación. Vol. 4727. pág. 209. CiteSeerX 10.1.1.149.7643 . doi : 10.1007/978-3-540-74735-2_15 . ISBN    978-3-540-74734-5.
  86. AES y modos de operación en GPU compatibles con SM4.0. Archivado el 21 de agosto de 2010 en Wayback Machine. Owen Harrison, John Waldron, Criptografía práctica de clave simétrica en hardware gráfico moderno. En las actas de USENIX Security 2008.
  87. Harrison, Owen; Waldron, John (2009). "Aceleración eficiente de la criptografía asimétrica en hardware gráfico". Progress in Cryptology – AFRICACRYPT 2009. Lecture Notes in Computer Science. Vol. 5580. p. 350. CiteSeerX 10.1.1.155.5448 . doi : 10.1007/978-3-642-02384-2_22 . ISBN    978-3-642-02383-5.
  88. "Problemas con los teraflops: la potencia de las unidades de procesamiento gráfico podría amenazar el sistema mundial de seguridad de contraseñas" . Instituto de Investigación de Georgia Tech . Archivado del original el 30 de diciembre de 2010. Consultado el 7 de noviembre de 2010 .
  89. "¿Quieres disuadir a los hackers? Alarga tu contraseña" . NBC News . 19 de agosto de 2010. Archivado del original el 11 de julio de 2013. Consultado el 7 de noviembre de 2010 .
  90. Lerner, Larry (9 de abril de 2009). "Punto de vista: GPU masivas, no CPU para simulaciones EDA" . EE Times . Consultado el 14 de septiembre de 2023 .
  91. "W2500 ADS Transient Convolution GT" . Acelera las simulaciones de integridad de señal en estaciones de trabajo que cuentan con unidades de procesamiento gráfico (GPU) basadas en la arquitectura de dispositivo unificado de computación (CUDA) de Nvidia.
  92. GrAVity: Un motor antivirus masivamente paralelo. Archivado el 27 de julio de 2010 en Wayback Machine . Giorgos Vasiliadis y Sotiris Ioannidis, GrAVity: Un motor antivirus masivamente paralelo. En las actas de RAID 2010.
  93. "Kaspersky Lab utiliza tecnologías de Nvidia para mejorar la protección" . Kaspersky Lab . 14 de diciembre de 2009. Archivado del original el 19 de junio de 2010. Durante las pruebas internas, la Tesla S1070 demostró un aumento de 360 ​​veces en la velocidad del algoritmo de definición de similitud en comparación con el popular procesador central Intel Core 2 Duo que funciona a una velocidad de reloj de 2,6 GHz.
  94. Gnort: Detección de intrusiones en redes de alto rendimiento mediante procesadores gráficos. Archivado el 9 de abril de 2011 en Wayback Machine . Giorgos Vasiliadis et al., Gnort: Detección de intrusiones en redes de alto rendimiento mediante procesadores gráficos. En las actas de RAID 2008.
  95. Coincidencia de expresiones regulares en hardware gráfico para detección de intrusiones. Archivado el 27 de julio de 2010 en Wayback Machine . Giorgos Vasiliadis et al., Coincidencia de expresiones regulares en hardware gráfico para detección de intrusiones. En las actas de RAID 2009.
  96. "Aplicaciones aceleradas por GPU" (PDF) . Archivado (PDF) del original el 25 de marzo de 2013. Recuperado el 12 de septiembre de 2013 .
  97. Langdon, William B; Lam, Brian Yee Hong; Petke, Justyna; Harman, Mark (2015). "Mejora del software de análisis de ADN CUDA con programación genética". Actas de la Conferencia de Computación Genética y Evolutiva de 2015 - GECCO '15 . págs. 1063–1070 . doi : 10.1145/2739480.2754652 . ISBN  9781450334723. S2CID 8992769 . 

Lecturas adicionales

  • Owens, JD; Houston, M.; Luebke, D.; Green, S.; Stone, JE; Phillips, JC (mayo de 2008). "Computación con GPU". Actas del IEEE . 96 (5): 879– 899. doi : 10.1109/JPROC.2008.917757 . ISSN 0018-9219 . S2CID 17091128 .  
  • Brodtkorb, André R.; Hagen, Trond R.; Sætra, Martin L. (1 de enero de 2013). "Estrategias de programación de unidades de procesamiento gráfico (GPU) y tendencias en computación GPU" . Journal of Parallel and Distributed Computing . Metaheurísticas en GPU. 73 (1): 4– 13. Bibcode : 2013JPDC...73....4B . doi : 10.1016/j.jpdc.2012.04.003 . hdl : 10852/40283 . ISSN 0743-7315 .