Блог

Известно, что ветвление в шейдере OpenGL ES требует особенно больших вычислительных затрат. В таком шейдере я проверяю, является ли значение null, прежде чем делить на него, например:

 if(value == 0.0)
    other_value = 0.0;
else
    other_value = 1.0 / value;
  

Чтобы ускорить процесс, я хотел бы избежать этого if , выполнив напрямую:

 other_value = 1.0 / value;
  

Интересно, что произойдет, если value значение окажется равным 0, что немного редко в моей обработке, вот почему это нетривиально протестировать. Происходит ли сбой шейдера? Происходит ли сбой приложения?

Действительно, не определено.

В симуляторе iPad деление красного компонента на 0.0 дает 0 (весь красный цвет исчезает с этой картинки).

На аппаратном обеспечении iPad при делении компонента r на 0.0 он насыщается полностью красным цветом (т. е. ограниченная бесконечность).

Итак, вы вообще не можете полагаться на неопределенное поведение для получения согласованного результата, но само по себе деление на 0 не приводит к чему-то плохому.

В моем шейдере я делю значения rgb на альфа. Просто так получилось, что если альфа-значение равно 0, пиксель все равно не отображается, поэтому у меня нет проблем с делением в любом случае (давая 0 или inf).

Подобные ветви обычно не дороги. Обычно они реализуются с использованием предикации. То есть графический процессор вычисляет обе ветви, но фактически сохраняет результаты инструкций только там, где условие предикации истинно. Следовательно, инструкция перехода не используется. Вот как мог бы выглядеть ассемблерный код:

 cmp_eq p0, r0, 0.0   // predicate = (value == 0.0)
(p0) mov r1, 0.0     // other_value = 0.0, if predicate true
(!p0) rcp r1, r0     // other_value = 1.0 / value, if predicate false
  

Обратите внимание, что в этом случае вторая инструкция на самом деле не обязательно должна быть предопределена. В любом случае, как указано другими, результат деления (обратный) не определен, когда знаменатель равен нулю. Но, как вы можете видеть, вы должны быть в состоянии получить четко определенное поведение всего за пару дешевых инструкций (деление обычно происходит медленно). Насколько мне известно, все графические процессоры, которые поддерживают реальные ветви (инструкции перехода), также поддерживают предикацию. Компилятор шейдера оценит, использовать ли предикацию или переход, и обычно поступит правильно.

Конечно, если вас действительно не волнует результат деления на ноль, вы можете сэкономить на любых затратах на предикацию.

Вместо

 float invert_value(in float value)
{
if(value == 0.0)
    return 0.0;
else
    return 1.0 / value;
}
  

вы можете написать

 float invert_value_ifless(in float value)
{
float sign_value = sign(value);
float sign_value_squared = sign_value*sign_value;
return sign_value_squared / ( value   sign_value_squared - 1.0);
}
  

Это возвращает именно то, что вы хотите, и имеет

1. никаких «если»
2. никаких делений на 0

Я не уверен, что это на самом деле быстрее на новейшем оборудовании с предикацией.

Я никогда не видел, чтобы шейдер вылетал из-за чего-то подобного. Скорее всего, это приведет к мусорному значению (например, nan) и испортит любые другие вычисления, которые вы выполняете с результатом. Помимо этого, я бы не стал беспокоиться об этом (и определенно не добавлял код ветвления, чтобы предотвратить это).

Если вы хотите ограничиться iPhone, почему бы вам не попробовать и не посмотреть, что получится? Однако нет никаких гарантий относительно того, что произойдет на будущем оборудовании, на котором будут запущены приложения iPhone. Это может привести к сбою. Это ничего не могло сделать. Это может отображать странные пиксели. Это может вызвать вашу тещу. (Все, поскольку это неопределенное поведение.)

на старом графическом оборудовании деление на ноль привело бы к значению бесконечности с плавающей запятой, что на самом деле является правильным ответом. однако это вряд ли то, чего вы хотите, потому что вы, вероятно, собираетесь просто сохранить бесконечность (или что-то производное от нее) в вашем буфере кадров, который, вероятно, имеет формат, подобный RGBA8, который не способен отличить бесконечность от 0 или 1.

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