Я использую графический процессор для ускорения молекулярной динамики, где я сохраняю силовое поле дальнего действия (например, электростатику) в 3D-текстуре.
Я обнаружил, что существует довольно большой числовая погрешность ~ 1.0E-3 по сравнению с моей трехлинейной интерполяцией, реализованной в C++ / CPU. В то время как кривая процессора полностью плавная, кривая графического процессора имеет относительный уровень шума ~ 1.0E-3. Да, графический процессор использует только одинарную точность (float32), но все же ~ 1.0E-3 намного хуже, чем точность float32 (~ 1.0E-8).
Это нормально? Есть ли способ повысить точность при использовании аппаратной интерполяции текстур?
ДЕТАЛИ:
OpenCL:
__constant sampler_t sampler_1 = CLK_NORMALIZED_COORDS_TRUE | CLK_ADDRESS_REPEAT | CLK_FILTER_LINEAR;
float4 fe = read_imagef( imgCoulomb, sampler_1, coord );
Обертка C++:
p_gpu = clCreateImage3D(context, flags, {CL_RGBA, CL_FLOAT}, nImg[0],nImg[1],nImg[2], 0, 0, p_cpu, &err);
Настройка системы:
GPU: Quadro K2200/PCIe/SSE2
Ubuntu 16.04 LTS
ПОЛУЧЕННЫЕ РЕЗУЛЬТАТЫ:
Да, графические процессоры часто используют ярлыки для интерполяции текстур. Например, они могут иметь только 256 шагов между значениями, поэтому, если эти значения довольно далеко друг от друга, вы не получите большой точности. Имейте в виду, что они оптимизированы для игр и графики (где такие ярлыки невидимы), а не для научных вычислений. Если ваше приложение требует точности, считайте значения, используя координаты int2 (и NEAREST sampling), и выполните интерполяцию в float. По моему опыту, это не намного медленнее, чем при использовании интерполяции текстур, поскольку выполняются те же операции чтения, а пропускная способность памяти обычно является узким местом (а не вычислением).
Он по-прежнему выполняет все эти чтения внутренне, даже с аппаратной фильтрацией, но обычно они кэшируются кешем текстур, что также помогает с явной фильтрацией.
Точно (чтения все равно происходят, и кеш текстур помогает). Мы реализовали программную билинейность (из-за старой ошибки, которая с тех пор была исправлена), и она была ненамного медленнее, чем аппаратная билинейность. Мы также реализовали программный бикубический режим, а для трехмерных текстур - программный четырехгранный (подходит для кубов управления цветом).
Да, я предполагаю, что проблема в пропускной способности памяти. Чтобы выполнить трилинейную работу вручную, мне нужно вызвать read_imagef 8x, а CL_FILTER_LINEAR - только 1x. Но, возможно, под капотом он все еще выполняет эти 8 чтений (?) ... или, может быть, есть какой-то трюк с ножом, как сделать чтение более связным?