2011-01-14 16 views
7

Estoy tratando de averiguar si un cierto problema es un buen candidato para usar CUDA para poner el problema en una GPU.¿Las GPU son buenas para el filtrado de imágenes basado en casos?

Básicamente estoy haciendo un filtro de caja que cambia en función de la detección de algunos bordes. Así que hay básicamente 8 casos que se prueban para cada píxel, y luego ocurre el resto de las operaciones: cálculos medios típicos y demás. ¿La presencia de estas instrucciones de conmutación en mi ciclo hará que este problema sea un mal candidato para ir a la GPU?

No estoy seguro de cómo evitar las instrucciones de cambio, porque esta detección de borde tiene que ocurrir en cada píxel. Supongo que toda la imagen podría tener la parte de detección de bordes separada del algoritmo de procesamiento, y podría almacenar un búfer correspondiente a cada filtro para cada píxel, pero parece que agregaría mucho preprocesamiento al algoritmo .

Editar: Para dar un poco de contexto, este algoritmo ya está escrito, y OpenMP se ha utilizado con bastante buen efecto para acelerarlo. Sin embargo, los 8 núcleos en mi caja de desarrollo palidecen en comparación con los 512 en la GPU.

+0

si te refieres a "palitos" en números brutos, esto no es necesariamente cierto, ya que muchos de los comentaristas en este hilo han explicado que la programación para la GPU requiere un tipo diferente de pensamiento. esto se debe a que, aunque es un caballo de batalla, solo es apto para ciertas tareas. :) –

+0

si tiene acceso a una tarjeta basada en Fermi de nVidia, pruébela y transmita la parte del código donde tiene hotspots. Es posible que también desee analizar el perfil de su código si aún no lo ha hecho, para ver cuál es el verdadero cuello de botella. de lo contrario, la mejor opción es volver a escribirlo para que no se bifurque. –

Respuesta

0

El uso de una GPU para el procesamiento a menudo puede ser contradictorio; cosas que obviamente son ineficientes si se hacen en código de serie normal, en realidad son la mejor manera de hacerlo en paralelo usando la GPU.

El pseudo-código de abajo parece ineficaz (ya que computa 8 valores filtrados para cada píxel), pero se ejecutará de manera eficiente en una GPU:


# Compute the 8 possible filtered values for each pixel 
for i = 1...8 
    # filter[i] is the box filter that you want to apply 
    # to pixels of the i'th edge-type 
    result[i] = GPU_RunBoxFilter(filter[i], Image) 

# Compute the edge type of each pixel 
# This is the value you would normally use to 'switch' with 
edge_type = GPU_ComputeEdgeType(Image) 

# Setup an empty result image 
final_result = zeros(sizeof(Image)) 
# For each possible switch value, replace all pixels of that edge-type 
# with its corresponding filtered value 
for i = 1..8 
    final_result = GPU_ReplacePixelIfTrue(final_result, result[i], edge_type==i) 

Esperemos que ayuda!

+0

¿Estoy leyendo este derecho? ¿Que está diciendo que básicamente calcula todos esos filtros antes de tiempo para toda la imagen, lo mismo con el tipo de borde? – Derek

+0

sí. Parece un desperdicio de cálculos, ya que normalmente solo tendría que calcular un "valor filtrado" por píxel y aquí calcularía 8 valores, pero evita la bifurcación. – Ciaran

1

La detección de bordes, los cálculos medios y la correlación cruzada se pueden implementar como convoluciones 2D. Las convoluciones se pueden implementar en GPU de manera muy efectiva (speed-up > 10, up to 100 con respecto a la CPU), especialmente para núcleos grandes. Así que sí, puede tener sentido reescribir el filtrado de imágenes en la GPU.

Aunque no utilizaría la GPU como plataforma de desarrollo para dicho método.

+0

he añadido contexto soem - ya tenemos este funcionamiento, y paralelo a algo con OpenMP – Derek

1

normalmente, a menos que esté en la nueva arquitectura CUDA, querrá evitar la bifurcación. debido a que las GPU son básicamente máquinas SIMD, la línea de plexiglás es extremadamente insoportable y sufre tremendamente en los puestos de tuberías debido a errores de predicción de las ramas.

si cree que hay beneficios significativos que se obtienen mediante el uso de una GPU, haga algunos puntos de referencia preliminares para tener una idea aproximada.

si quiere aprender un poco sobre cómo escribir código no ramificado, diríjase a http://cellperformance.beyond3d.com/ y eche un vistazo.

más, investigando en la ejecución de este problema en varios núcleos de CPU también podría valer la pena, en cuyo caso es probable que desee ver en cualquiera de las bibliotecas de rendimiento de Intel (como TBB)

otro go-OpenCL o a la fuente de los problemas de segmentación de la GPU ya sea gráficos, geometría computacional o de otra manera, es IDAV, el Instituto de Análisis de datos y Visualización: http://idav.ucdavis.edu

0

Sí, el flujo de control por lo general tiene penalización en el rendimiento de la GPU, ya sea si de/switch' es/ternary operator's, porque con las operaciones de flujo de control la GPU no puede ejecutar subprocesos de forma óptima.Las tácticas usuales son evitar la bifurcación como sea posible. En algunos casos, los IF pueden reemplazarse por alguna fórmula, donde las condiciones de IF se correlacionan con los coeficientes de la fórmula. Pero la solución/optimización concreta depende del kernel de la GPU concreta ... Tal vez pueda mostrar el código exacto, para que la comunidad stackoverflow lo analice aún más.

EDIT: En caso de que les interesa aquí es convolution pixel shader que escribí.

+0

Voy a investigar eso - mostrando el código. Puede ser demasiado patentado en este punto para lanzar el código interesante – Derek

+0

. :) –

1

La ramificación en realidad no es tan mala, si hay coherencia espacial en la ramificación. En otras palabras, si espera trozos de píxeles uno al lado del otro en la imagen para pasar por la misma bifurcación, el golpe de rendimiento se reduce al mínimo.

+0

esto es cierto para los procesadores Nvidia más nuevos; no estoy seguro acerca de AMD/ATi? –

+0

también, dado que el problema es la detección de bordes, las rutas de ejecución divergentes obviamente ocurrirían alrededor de los bordes, aunque este golpe de rendimiento puede ser insignificante dependiendo de la geometría de la imagen –

Cuestiones relacionadas