2010-10-21 9 views
5

Parece que 2 millones de flotadores no deberían ser un gran problema, solo 8 MB de 1 GB de RAM GPU. Puedo asignar eso a veces y algunas veces más sin problemas. Obtengo CL_OUT_OF_RESOURCES cuando hago un clEnqueueReadBuffer, que parece extraño. ¿Puedo oler dónde comenzó realmente el problema? OpenCL no debería estar fallando así en clEnqueueReadBuffer ¿verdad? Debería ser cuando asigné los datos ¿verdad? ¿Hay alguna manera de obtener más detalles que solo el código de error? Sería fantástico si pudiera ver cuánto VRAM se asignó cuando OpenCL declaró CL_OUT_OF_RESOURCES.CL_OUT_OF_RESOURCES para 2 millones de flotadores con 1GB de VRAM?

Respuesta

3

No se puede suministrar necesariamente toda la memoria disponible a una sola solicitud de adquisición. Lea sobre la fragmentación del montón 1, 2, 3 para obtener más información sobre por qué la asignación más grande que puede tener éxito es para el bloque contiguo de memoria más grande y cómo los bloques se dividen en partes más pequeñas como resultado del uso de la memoria.

No es que el recurso se agota ... Simplemente no puede encontrar una sola pieza lo suficientemente grande como para satisfacer su solicitud ...

+0

Esto tiene sentido, gracias por señalarlo. ¿Hay alguna manera de analizar cómo se ve la fragmentación de la memoria del montón en la GPU cuando ocurrió la falla? – smuggledPancakes

+0

¿Tal vez gDEBbugger? http://www.gremedy.com/ Nunca lo he usado. –

+0

De alguna manera dudo que ese sea realmente el problema, ya que la memoria gpu generalmente no debería estar lo suficientemente fragmentada para eso. Después de todo 8 MB no es realmente mucho en una tarjeta de 1 GB (especialmente porque el controlador debería ser capaz de extraer la memoria no utilizada actualmente a la memoria principal) y las asignaciones de memoria gpu suelen ser relativamente gruesas. Por lo tanto, parece probable que deba acercarse al límite de memoria si observa tales problemas debido a la fragmentación de todos modos y si se trata de un sistema basado en una tarjeta grapic normal (opuesto a, por ejemplo, tesla) dudo que el conductor no intervenga en ese punto (matando algunos contextos). – Grizzly

5

De another source:

- pidiendo clFinish() se obtiene el error estado para el cálculo (en lugar de obtenerlo cuando intenta leer datos).
- el error de "falta de recursos" también puede ser causado por un tiempo de espera de 5 segundos si la tarjeta (NVidia) también se está utilizando como pantalla
- también puede aparecer cuando tiene errores de puntero en su kernel.

Un seguimiento sugiere que ejecuta el kernel por primera vez en la CPU para asegurarse de que no está haciendo fuera de los límites accesos a memoria.

7

Acabo de tener el mismo problema que tenía (me tomó todo un día arreglarlo). Estoy seguro de que las personas con el mismo problema tropezarán con esto, es por eso que estoy publicando esta vieja pregunta.

Probablemente no verificó el tamaño máximo de grupo de trabajo del núcleo .

Así es como se hace:

size_t kernel_work_group_size; 
clGetKernelWorkGroupInfo(kernel, device, CL_KERNEL_WORK_GROUP_SIZE, sizeof(size_t), &kernel_work_group_size, NULL); 

Mis dispositivos (2x NVIDIA GTX 460 & Intel i7 CPU) admiten un tamaño máximo del grupo de trabajo de 1024, pero el código anterior devuelve algo alrededor de 500 cuando paso mi núcleo de Trazado de ruta. Cuando utilicé un tamaño de grupo de trabajo de 1024 obviamente falló y me dio el error CL_OUT_OF_RESOURCES.

Cuanto más complejo se vuelve el kernel, menor será el tamaño máximo del grupo de trabajo para él (o al menos lo que experimenté).

Editar:
me he dado cuenta de que has dicho "clEnqueueReadBuffer" en lugar de "clEnqueueNDRangeKernel" ...
Mi respuesta estaba relacionada con clEnqueueNDRangeKernel.
Disculpa por el error.
Espero que esto todavía sea útil para otras personas.

+0

Hola gracias. ¡Tienes razón! Estaba usando el tamaño máximo del grupo de trabajo del dispositivo en lugar del tamaño del grupo de trabajo máximo del kernel. Cambiado que lo arregló :). – Gamer

+0

No hay problema. Me alegro de poder ayudar. : D – Tara

+1

Tenía el mismo problema, ¡gracias! –

1

Los accesos fuera de límites en un kernel son generalmente silenciosos (ya que todavía no hay ningún error en la llamada de cola del kernel).

Sin embargo, si intenta leer el resultado del kernel más tarde con un clEnqueueReadBuffer(). Este error aparecerá. Indica que algo salió mal durante la ejecución del kernel.

Compruebe el código del kernel para leer/escribir fuera de límites.