Barreras en OpenCL

Question

En OpenCL, tengo entendido que puede usar la función barrier() para sincronizar subprocesos en un grupo de trabajo. Sí (generalmente) entiendo para qué son y cuándo usarlos. También sé que todos los hilos en un grupo de trabajo deben golpear la barrera, de lo contrario hay problemas. Sin embargo, cada vez que he intentado utilizar barreras hasta ahora, parece que mi controlador de video se cuelga o aparece un mensaje de error sobre el acceso a algún tipo de memoria no válida. Hasta ahora he visto esto en 2 tarjetas de video diferentes (1 ATI, 1 NVIDIA).

Por lo tanto, mis preguntas son:

1. Cualquier idea de por qué esto iba a pasar?
2. ¿Cuál es la diferencia entre barrier(CLK_LOCAL_MEM_FENCE) y barrier(CLK_GLOBAL_MEM_FENCE)? Leí la documentación, pero no estaba claro para mí.
3. ¿Existe una regla general sobre cuándo usar barrier(CLK_LOCAL_MEM_FENCE) frente a barrier(CLK_GLOBAL_MEM_FENCE)?
4. ¿Hay alguna vez que llamar a barrier() con el tipo de parámetro incorrecto podría causar un error?

Answer 1

Como ha indicado, las barreras solo pueden sincronizar los hilos en el mismo grupo de trabajo. No hay forma de sincronizar diferentes grupos de trabajo en un kernel.

ahora para responder a su pregunta, la especificación no era claro para mí tampoco, pero me parece que la sección 6.11.9 contiene la respuesta:

CLK_LOCAL_MEM_FENCE - la función de barrera, o bien al ras ningún las variables almacenado en la memoria local o poner en cola una valla de memoria para asegurar ordenar correctamente las operaciones de memoria a la memoria local.

CLK_GLOBAL_MEM_FENCE - La función de barrera pondrá en cola una valla de memoria para asegurar el ordenamiento correcto de las operaciones de memoria en la memoria global. Esto puede ser útil cuando los elementos de trabajo, por ejemplo, escriben en el búfer o en los objetos de memoria de imagen y luego desean leer los datos actualizados.

Por lo tanto, a mi entender, se debe utilizar CLK_LOCAL_MEM_FENCE al escribir y leer al espacio __local memoria y CLK_GLOBAL_MEM_FENCE al escribir y readin al espacio __global memoria.

No he probado si esto es más lento, pero la mayoría de las veces, cuando necesito una barrera y tengo una duda sobre el que impacta el espacio de memoria, simplemente utilizan una combinación de los dos, es decir:

barrier(CLK_LOCAL_MEM_FENCE | CLK_GLOBAL_MEM_FENCE); 

De esta forma no debería tener ningún problema de lectura/escritura de la escritura (siempre y cuando esté seguro de que cada hilo del grupo atraviesa la barrera, pero ya lo sabe).

Espero que ayude.

Answer 2

Reviviendo un hilo antiguo aquí. He tenido un poco de problemas con barrier().

En cuanto a su problema de colisión, una posible causa podría ser si su barrera está dentro de una condición.Leí que cuando usa la barrera, TODOS los elementos de trabajo en el grupo deben poder alcanzar esa instrucción, o colgará su kernel, lo que generalmente da como resultado un bloqueo.

if(someCondition){ 
    //do stuff 
    barrier(CLK_LOCAL_MEM_FENCE); 
    //more stuff 
}else{ 
    //other stuff 
} 

Mi opinión es que si uno o más elementos de trabajo satisface somecondition, todos los elementos de trabajo deben cumplir dicho requisito, o habrá algunos que saltar la barrera. Las barreras esperan hasta que TODOS los elementos de trabajo lleguen a ese punto. Para solucionar el código anterior, necesito reestructurar un poco:

if(someCondition){ 
    //do stuff 
} 
barrier(CLK_LOCAL_MEM_FENCE); 
if(someCondition){ 
    //more stuff 
}else{ 
    //other stuff 
} 

Ahora todos los elementos de trabajo se llega a la barrera.

No sé en qué medida esto se aplica a los bucles; si un elemento de trabajo se rompe de un bucle for, ¿toca barreras? No estoy seguro

ACTUALIZACIÓN: He bloqueado con éxito algunos programas ocl con una barrera en un bucle for. Asegúrese de que todos los elementos de trabajo salgan del bucle for al mismo tiempo, o mejor aún, coloque la barrera fuera del bucle.

(fuente: computación heterogénea con OpenCL Capítulo 5, p90-91)