2014-09-18 Blender, Radeon, Mesa, OpenCL
Пытался тут на новом ноуте заюзать OpenCL в блендере — потерпел неудачу… ещё конечно подебажить попробую… но хз, получится ли.
Теоретически там радеон 8770M, а это значит, что в Mesa есть OpenCL, реализованный посредством LLVM.
Практически:
Сначала блендер просто не видел OpenCL в системе… это решилось просто — он хотел библиотеку libOpenCL.so, а это симлинк на libOpenCL.so.1.0.0, который почему-то оказался не в том пакете (оказался в -dev).
Потом что blender, что clinfo не могли заюзать радеон из-за permission denied по какому-то ioctl — это я не решил, но обошёл тупо путём запуска из-под рута.
Потом оказалось, что blender’у нужно передать переменную окружения CYCLES_OPENCL_TEST, передал… С этого момента OpenCL он у меня увидел.
Следующая проблема была в том, что ядро (OpenCL kernel, программа, которую на GPU грузят) не компилилось мезой. Я было подумал что всё, пиши пропало — например, пишут, что вроде на закрытом AMD’шном драйвере там вообще всё совсем печально, типа не компилится потому что тупо ядро большое, и их компилятор давится.
Но тут-то вроде LLVM, не должно такого быть! И таки да — я нашёл просто ошибку в этом самом ядре. Она мелкая, там они просто . вместо -> в одном месте юзали (код по сути C-шный). Правда, чтобы это найти, я сначала нашёл ещё одну переменную окружения — CYCLES_OPENCL_DEBUG, чтобы готовый исходник ядра, собранный из кучи файлов, увидеть.
Итак, после исправления этой очипятки ядро собралось… но после этого, увы, блендер просто стал падать с segmentation fault’ом где-то в недрах LLVM уже при попытке трансляции видимо IR’а в radeon’овый шейдерный код. И тут я пока хз, получится ли это поправить. Есть ещё маленькая вероятность, что это баг oibaf’ской сборки, так как mesa у меня именно оттуда… В общем, буду искать баг дальше. Очень уж хочется Cycles на GPU запустить.
UPD: Залез в недра LLVM, попробовал поискать баг; обнаружил, что в SIAnnotateControlFlow.cpp в handleLoopCondition() в какой-то момент попадает PHINode, у которого первый аргумент равен ему самому. Теперь вся интрига в том, как это всё-таки происходит?
UPD2: Видимо, в LLVM PHINode, содержащий себя — это вполне нормальный продукт оптимизатора. Причём мало того, что он может содержать себя напрямую, в качестве одного из IncomingValue, так оказывается, что может и через другой PHINode (то есть phi->getIncomingValue(0)->getIncomingValue(0) == phi)… Поэтому просто пропускать значения, равные самому PHINode, не помогает, нужно проверять во всю глубину… И главное, не очень понятно, ЧТО вообще по логике означают такие PHINode. Написал по этому поводу в список рассылки LLVMdev — пока в ответ тишина…
[ Хронологический вид ]Комментарии
Войдите, чтобы комментировать.