Jun 15, 2015 21:45
Недавно заседал в офисе до часу ночи: выуживал причину дефекта. Не работало на планшете от ASUS - K700. Его изюминка - 64-битный процессор от Intel %) Один из наших вершинных шейдеров на нём не компилировался с ошибкой "Compile error!". На аналогичных 32-битных аппаратах всё было кока-кола.
По ходу там компилятор внутри падал. Так, на тривиальные ошибки, вроде пропущенной точки с запятой, выдавалась нормальная диагностика: номер строки, что пошло не так. А в моём случае неинформативное "нишмогла". Небольшое расследование бинарным поиском через комментирование строк кода показало супостата:
if (0.0 < g_use_secondary_color)
{
g_VSColor = vec4(g_secondary_rgb_color_and_elevation.rgb / 255.0, 1.0);
}
else
{
// g_color_stream - массив uniform'ов (а.к.а. шейдерных констант)
// g_color_index - тоже uniform
g_VSColor = g_color_stream[int(g_color_index)];
}
В кодобазе был шейдер с похожей конструкцией. Единственная лишь разница, что у меня чтение из массива uniform'ов было внутри else. Ну фигли: удалил if - работает =) Вернул в else - не работает. Удалил индексирование юниформом, сделал чтение из массива по compile-time константе - работает. Вернул - не работает.
Уже ради спортивного интереса попробовал сделать минимальный шейдер, содержащий суть проблемы. Не вышло - проблема исчезла. В итоге на хрен выкинул индексирование, так как оно осталось с древних времён и реально нужно было брать всегда нулевой элемент.
Такие дела. Всем бездефектных компиляторов шейдеров и поменьше изотерических устройств, поцоны.
wtf,
2гис,
glsl,
android