Что касается потока управления OpenCL, где if (false) читается, а не пропускается, и отладка OpenCL в целом

Question

Прежде всего, я впервые почувствовал необходимость задать вопрос по StackOverflow, но я решил свою проблему, пытаясь установить и взломать свой собственный код OpenCL.Однако, учитывая, как мало полезной и доступной информации по отладке для OpenCL я нашел за пару месяцев, в течение которых я ее изучал, я подумал, что попытка записать это может помочь кому-то еще на моем месте, поскольку решение моей проблемыне было очевидно для новичка.

Контекст: я пишу raytracer с ограничениями на моем C, но разрешением использовать OpenCL для школы.Я уже собрал и отладил RNG-библиотеку OpenCL, которую я могу вызывать из простых ядер, портировал некоторые алгоритмы на подфункции, но все еще изучаю управление памятью и разложение больших алгоритмов на организованную последовательность ядер для постановки в очередь.

ОС: Xubuntu 18.04 Платформа: NVIDIA CUDA |Устройство: GeForce GTX 950M |Версия: OpenCL 1.2 CUDA

Я получил несогласованность в моих данных: printf () сказал мне, что мои данные были для моего второго ядра (того, где возникала проблема) и связного;но он никогда не встречал проверки в соответствующих операторах «если».Хуже того, мне показалось, что все утверждения, которые были «ложными» и были странными из-за потока управления графическим процессором, были в замешательстве.

Две страницы в Интернете, посвященные темам, наиболее похожим на то, что яполучал, но оба не были моей проблемой (может быть, именно поэтому я и добавляю их):

https://community.amd.com/thread/225707

https://computergraphics.stackexchange.com/questions/4115/gpu-branching-if-without-else

Для отладки,Я использовал следующий фрагмент в подфункции, которая возвращает цвет пикселя в основное ядро ​​(которое его вызывает).

    if (isequal((float)scene->camera.c_to_w.sF, (float)0.))
    {
        return ((float3)(0., 255., 0.));
    }
    else if (isequal((float)scene->camera.c_to_w.sF, (float)0.5))
    {
        return ((float3)(255., 0., 255.));
    }
    else //if (some other condition)
        return ((float3)(255., 255., 0.));

Функция без этого фрагмента вернула черный экран.В противном случае он вернул экран цвета одного из операторов if в соответствии со следующим поведением.Комментируя, соответственно, «else» операторы и играя со значениями, я понял, что: пока существует этот фрагмент, один из этих «return (R, G, B)» обязательно будет прочитан;если хотя бы один из них был истинным, он был бы прочитан, иначе поведение было бы последовательно первым условием последовательности if-else этой переменной длины.

Answer 1

Моей ошибкой было простое отсутствие строки "return (result_pixel_color)";в конце моей подфункции get_pixel_color ().Да, я тупой.

Похоже, что компилятор OpenCL не предупреждает вас об ошибках типа «поток управления достиг конца не-void функции до возврата», как это делает большинство компиляторов Си.Неопределенное поведение отсутствующего возврата в моем случае использовало ЛЮБОЙ возврат в функции в качестве общего возврата для потока управления.Возможно, есть и другие классические ошибки, о которых не предупреждает компилятор OpenCL: может ли эта ошибка скользить: будьте более критичны по отношению к своему коду!

Это более общее утверждение, но я думаю, что оно может быть кому-то полезнонатолкнулся на какую-то неясную ошибку при изучении OpenCL.Моя проблема заключалась в том, что я переоценил полезность компилятора OpenCL, особенно учитывая размер моего кода.Мы пытаемся создать множество подфункций в разных файлах .cl с заголовком .cl.h, чтобы сделать его разборчивым и модульным в своей архитектуре и комментариях: это командный проект, но я уже лучше знаю OpenCL ... Кажется, ядров большинстве случаев кодирование сводится к созданию функций длиной в сто строк, что действительно является проблемой для удобства и модульности IMO.Более 1 ядра на файл и более 1 файла на программу, и вы начинаете сталкиваться с проблемами, особенно с компиляцией.Для сложного алгоритма, такого как (двунаправленная / быстрая / и т. Д.) Трассировка пути, которая требует для моделирования множества различных типов больших данных, структур ускорения и сортировки лучей для выполнения пересечений в последовательности, согласованной с рабочей группой, вам следует опасаться компилятора, никогдазнаю, насколько глупа / обыденна ваша ошибка на самом деле.