т.е. на тех устройствах, что поддерживают double, а я в своем первом комментарии я явно написал про одинарную точность. Я не говорю что double плох, но его поддерживают не все устройства и его обработка требует больше тактов…
На счёт ссылок не знаю, я в свое время сам писал, и не счёл сложность темы достойной публикации и обсуждения, уж больно просто вопрос решался на OpenCL+Qt. Но если очень интересно могу поискать и выложить свои наработки.
Про ошибку смотрите ниже.
На самом деле, про скорость я не спорю, это вполне логично что Nvidia нарочно урезает производительность конкурирующего стандарта по сравнению со своей проприетарной технологией, просто Вы не привели пруфа. Куда важнее, что OpenCL работает и на картах AMD и на любых CPU, а CUDA этим похвастаться не может.
Речь шла не только о Fermi. Посмотрите Table C-1, там есть оговорка:
0 for compute capability ≥ 2 when compiled with -prec-div=true
2 (full range), otherwise
и подробнее в C.2.1. Если коротко, то смысл в том, что округление с точностью 0 ulp можно получить только на устройствах с нативной поддержкой double и только при указании опции компилятора -prec-div=true. В остальных случаях будет 2 ulp. Я в подробности не вникал, т.к. больше не увлекаюсь Nvidia но, очевидно, в этом случае компилятор просто приводит float к double для достижения необходимой точности.
Про OpenCL хорошо сказано, главное без пруфа, я сразу поверил! А еще не указан главный (на мой взгляд) недостаток GPU — низкая точность деления чисел с плавающей запятой одинарной точности, т.е. вы не получите один результат запустив алгоритм, использующий операции деления, на CPU и GPU. Решается использованием double.
Global work-offset which enable kernels to operate on different portions of the NDRange — самое ожидаемое нововведение 1.1, по крайней мере для меня. Я сам очень удивился когда не обнаружил такой возможности в 1.0. А столкнулся я с этим при реализации метода Гаусса (собственно, то же самое справедливо почти для любого прямого метода решения СЛАУ). Идея в том, что на каждом шаге обрабатываемая часть матрицы становится всё меньше (на одну строку сверху и один столбец слева). Вот здесь как раз глобальный офсет и нужен.
Порылся в спеках, обнаружил что оно уже есть в 1.1, и что у Nvidia вроде бы уже есть pre-release drivers. Недолго думая, запросил эти драйвера, но Nvidia захотела чтобы я что-то там доказал… Решил, что оно того не стоит (я думал что готовые драйвера выйдут как минимум на полгода раньше), в итоге ядра дополнились конструкциями вида:
if(x < i || y < i) return; // где i — номер шага, а x,y — глобальные id
Про ошибку смотрите ниже.
На самом деле, про скорость я не спорю, это вполне логично что Nvidia нарочно урезает производительность конкурирующего стандарта по сравнению со своей проприетарной технологией, просто Вы не привели пруфа. Куда важнее, что OpenCL работает и на картах AMD и на любых CPU, а CUDA этим похвастаться не может.
0 for compute capability ≥ 2 when compiled with -prec-div=true
2 (full range), otherwise
и подробнее в C.2.1. Если коротко, то смысл в том, что округление с точностью 0 ulp можно получить только на устройствах с нативной поддержкой double и только при указании опции компилятора -prec-div=true. В остальных случаях будет 2 ulp. Я в подробности не вникал, т.к. больше не увлекаюсь Nvidia но, очевидно, в этом случае компилятор просто приводит float к double для достижения необходимой точности.
Продолжить — WebGL.
Закончить — WebCL.
Порылся в спеках, обнаружил что оно уже есть в 1.1, и что у Nvidia вроде бы уже есть pre-release drivers. Недолго думая, запросил эти драйвера, но Nvidia захотела чтобы я что-то там доказал… Решил, что оно того не стоит (я думал что готовые драйвера выйдут как минимум на полгода раньше), в итоге ядра дополнились конструкциями вида:
if(x < i || y < i) return; // где i — номер шага, а x,y — глобальные id