c++ - mundo - programacion cuda linux

Trabajando con muchas matrices de tamaño fijo en núcleos CUDA (1)

Estoy buscando trabajar alrededor de 4000 matrices de tamaño fijo (3x3, 4x4), haciendo cosas como inversión de matriz y descomposición propia.

Me parece que la mejor manera de paralelizar esto sería dejar que cada uno de los muchos hilos de la GPU trabaje en una sola instancia del problema.

¿Hay una manera razonable de hacer esto? He leído: http://www.culatools.com/blog/2011/12/09/batched-operations/ pero, por lo que puedo decir, siempre es algo en lo que se está "trabajando" sin una solución a la vista. Tres años después, espero que haya una buena solución.

Hasta ahora, he visto:

Usando Eigen en núcleos CUDA: http://eigen.tuxfamily.org/dox-devel/TopicCUDA.html . Pero esto está en su infancia: por lo tanto, no parece funcionar bien y algunas cosas no se implementan. Además, no estoy seguro si está optimizado para CUDA en absoluto. Casi no hay documentación y el único ejemplo de código es un archivo de prueba (eigen / test / cuda_basic.cu). Cuando probé a usar Eigen en núcleos CUDA, cosas simples como declarar un Eigen::MatrixXf en un kernel no sobrevivieron a la compilación con nvcc V7.0.27 y Eigen 3.2.90 (mercurial).
Usar la biblioteca de API del dispositivo cuBLAS para ejecutar rutinas BLAS dentro de un kernel. Parece cuBLAS y su estilo están escritos para ser paralelizados incluso para matrices pequeñas, lo que parece excesivo y probablemente lento para las matrices 3x3 y 4x4 que me interesan. Además, no estoy seguro de si hay algo como cuBLAS que también pueda hacer eigendecomposition o SVD. (Hasta donde yo sé, CULA no admite llamar a sus rutinas desde kernels).
Procesamiento por lotes de kernels usando flujos CUDA. En la Sección 2.1.7 "Núcleos de procesamiento por lotes" de la documentación cuBLAS para CUDA Toolkit v7.0, se sugiere esto. Pero "" "en la práctica no es posible tener más de 16 kernels concurrentes ejecutándose al mismo tiempo" "" y, en consecuencia, sería terrible procesar 4000 matrices pequeñas. En un enlace mencionado anteriormente a la publicación de blog de CULA, cito: "" Se podría, en teoría, usar una secuencia CUDA por problema y lanzar un problema a la vez. Esto tendría un mal rendimiento por dos razones. Primero, es que el el número de subprocesos por bloque sería demasiado bajo; [...] Segundo, la sobrecarga incurrida al lanzar miles de operaciones de esta manera sería inaceptable, porque el código de lanzamiento es tan caro (si no más costoso) que simplemente realizar la matriz en la CPU "" "
Implementando mi propia multiplicación de matriz y composición propia en núcleos. Es probable que sea muy lento y, además, puede llevar mucho tiempo implementarlo.

En este punto, estoy tentado de renunciar a hacer esto en la GPU en absoluto. Es una pena, ya que esperaba rendimiento en tiempo real para un algoritmo que requiere invertir 4000 matrices de 3x3 aproximadamente 100 veces cada 0.1 segundos.

Las funciones de cublas getrfBatched y getriBatched están diseñadas para la inversión por lotes de matrices pequeñas. Esto debería ser más rápido que cualquiera de los paralelismos o flujos dinámicos (sus enfoques segundo y tercero). También hay un solucionador de lotes disponible en forma de código fuente que puede hacer inversiones de matriz. Deberá iniciar sesión como desarrollador registrado en developer.nvidia.com para acceder a este enlace.

Además, no estoy seguro de si hay algo como cuBLAS que también pueda hacer una descomposición propia o SVD. (Hasta donde yo sé, CULA no admite llamar a sus rutinas desde kernels).

Cusolver proporciona algunas funciones de solucionador eigen . Sin embargo, no están agrupados ni se pueden llamar desde el código del dispositivo, por lo que te enfrentas a las transmisiones como la única opción más allá de eso.