CUDA: ¿y si elijo demasiados bloques?

Question

Todavía me estoy enojando con estas matrices de tamaño desconocido que pueden variar de 10 a 20.000 para cada dimensión.

Estoy viendo el sdk de CUDA y me pregunto: ¿y si elijo un número de bloques demasiado alto?

Algo así como una cuadrícula de 9999 x 9999 bloques en las dimensiones X e Y, si mi hardware tiene SM que no pueden contener todos estos bloques, ¿el kernel tendrá problemas o simplemente colapsará?

No sé cómo dimensionar en bloques/hilos algo que puede variar tanto ... Estoy pensando en usar la cantidad MÁXIMA de bloques que mi hardware soporta y luego hacer que los hilos dentro de ellos funcionen en toda la matriz , ¿Es este el camino correcto?

Answer 1

Los bloques de hilos no tienen un mapeo uno a uno con los núcleos. Los bloques se programan en núcleos a medida que estén disponibles, lo que significa que puede solicitar tantos como desee (hasta un límite, probablemente). Solicitar una gran cantidad de bloques simplemente ralentizaría el sistema a medida que carga y descarga bloques de hilos que no hacen nada en los núcleos.

Puede especificar las dimensiones de la cuadrícula y los bloques en tiempo de ejecución.

Editar: Aquí están los límites en las dimensiones de la cuadrícula y los bloques, de la documentación.

Answer 2

Si usted elige un tamaño de bloque excesivamente grande, que los residuos de algunos ciclos, mientras que los bloques "muertas" Get retirados (por lo general sólo del orden de unas pocas decenas de microsegundos incluso para el tamaño máximo de cuadrícula en un tarjeta Fermi o GT200 de "tamaño completo"). No es una gran pena.

Pero la dimensión de la cuadrícula siempre debe ser computable a priori. Por lo general, existe una relación conocida entre una unidad cuantificable de trabajo paralelo de datos, algo así como un subproceso por punto de datos o un bloque por columna de matriz o lo que sea, que permite calcular las dimensiones de cuadrícula requeridas en tiempo de ejecución.

Una estrategia alternativa sería usar un número fijo de bloques (normalmente solo debe ser algo así como 4-8 por MP en la GPU) y hacer que cada bloque/hilo procese varias unidades de trabajo paralelo, por lo que cada bloque se convierte "persistente". Si hay una gran cantidad de costos indirectos fijos en la configuración por subproceso, puede ser una buena forma de amortizar esos gastos generales fijos en más trabajo por subproceso.