Использование шейдеров HTML5 WebGL для вычислений
Мне кажется, что теоретически можно использовать WebGL для вычисления - например, вычисления простых чисел или π или что-то в этом направлении. Однако из того, что я видел, сам шейдер не написан в Javascript, поэтому у меня есть несколько вопросов:
-
На каком языке написаны шейдеры?
- Было бы даже стоило попытаться сделать такое, учитывая, как работают шейдеры?
- Как передавать переменные взад и вперед во время выполнения? Или, если это невозможно, как передать информацию после завершения шейдера?
- Поскольку это не Javascript, как бы обрабатывать очень большие целые числа (BigInteger в Java или портированную версию в Javascript)?
- Я бы предположил, что это автоматически компилирует script, чтобы он работал по всем ядрам на графической карте, могу ли я получить подтверждение?
Если это уместно, в этом конкретном случае я пытаюсь определить довольно большие числа как часть расширенного проекта compsci. [/p >
EDIT:
- Шрифты WebGL записываются в GLSL.
Ответы
Ответ 1
Там в настоящее время разрабатывается проект, чтобы сделать практически то, что вы делаете - WebCL. Тем не менее, я не верю, что он живет в каких-либо браузерах.
Чтобы ответить на ваши вопросы:
- Уже ответил, я думаю!
- Возможно, не стоит делать в WebGL. Если вы хотите поиграть с вычислениями на GPU, вам, вероятно, повезло бы сделать это за пределами браузера, так как инструментальные цепочки гораздо более зрелые.
- Если вы застряли в WebGL, один из подходов может заключаться в том, чтобы записать ваши результаты в текстуру и прочитать их обратно.
- С трудом. Подобно процессорам, графические процессоры могут работать только с определенными значениями размера изначально, а все остальное нужно эмулировать.
- Да.
Ответ 2
Я использовал вычислительные шейдеры из JavaScript в Chrome с помощью WebGL, чтобы решить проблему коммивояжера как распределенный набор меньших задач оптимизации, решаемых в шейдере фрагментов, и в нескольких других проблемах с генетической оптимизацией.
Проблемы:
-
Вы можете поместить float в (r: 1.00, g: 234.24234, b: -22.0), но вы можете получить только целые числа (r: 255, g: 255, b: 0). Это может быть преодолено путем кодирования одного поплавка на 4 целых числа в виде вывода на фрагмент. Это на самом деле такая тяжелая операция, что она почти побеждает цель для 99% проблем. Лучше решать проблемы с помощью простых целочисленных или булевых подрешений.
-
Отладка - это кошмар эпических масштабов, и сообщество на момент написания этого активно.
-
Ввод данных в шейдер в качестве пиксельных данных ОЧЕНЬ медленный, чтение его еще медленнее. Чтобы привести пример, чтение и запись данных для решения проблемы TSP занимает соответственно 200 и 400 мс, фактическое время "рисования" или "вычисления" этих данных составляет 14 мс. Для того, чтобы быть полезным, ваш набор данных должен быть достаточно большим в правильном направлении.
-
JavaScript слабо типизирован (на поверхности...), тогда как OpenGL ES строго типизирован. Чтобы взаимодействовать, мы должны использовать в JavaScript такие вещи, как Int32Array или Float32Array, что неудобно и сдерживает язык, обычно рекламируемый для него.
-
Поддержка большого числа сводится к использованию 5 или 6 текстур входных данных, объединяя все эти пиксельные данные в единую структуру чисел (как-то...), а затем действуя на этом большом количестве значимым образом. Очень хаки, совсем не рекомендуется.
Ответ 3
я однажды обрушился на этот материал. В ответ на ваш третий вопрос я передал vars назад вперед с "униформами"
* edit - оглядываясь назад, также используются векторные "атрибуты" для передачи данных извне.
вам нужно запустить mamp или что-то для этого, чтобы работать локально...
https://github.com/byteface/GTP/tree/master/play/simplified
Я использовал пиксели для представления букв алфавита и выполнял поиск строк с помощью шейдеров. Это было удивительно быстро. быстрее, чем программы поиска на основе процессора. т.е. поиск всей книги для экземпляров одного слова быстрее в браузере на GPU, чем в облегченной программе, такой как textedit. и я использовал только одну текстуру.