webgl и javascript
А кто нибудь пробовал использовать вычислительные мощности графических ускорителей для параллельных вычислений в javascript?
|
ГеннадийС,
Все руки никак не дойдут, кроме как для gl это особого смысла не имеет тут процессора с головой как правило хватает. Если у вас какой то опыт есть пишите. |
Графические ускорители так аппаратно устроены что они всегда производят вычисления параллельно любое использование GPU для любых задач это параллельные вычисления иначе их использование теряет смысл.
JavaScript никогда не сможет исполнятся параллельно следовательно он никогда не сможет исполнятся на GPU. webgl - это API которое предоставляет среда исполнения т.е. это обычные свойства и методы как и все остальное апи браузера. С использованием webgl можно передавать видеокарте шейдерные программы которые буду компилироватся и исполнятся на GPU также можно передавать данные (uniform переменные) картинки(текстуры) буферы вершин и.т.д. и получать результаты в виде изображения которое строит GPU. В любом случае все сводится к написанию шейдерных программ. Использовать для этого апи браузера глупо для таких задач в разы проще и быстрее использовать специальные инструменты (компиляторы в GPU шейдеры) Например питон -> CUDA или же OpenCL для C/C++ Но если ты крутой чувак то ничего не мешает тебе писать шейдеры самому в блокнотике и исполнять их через webgl API браузера. Принципиальной разницы и ограничений нет. |
Цитата:
|
MallSerg, я говорил о случаях, когда нужно, к примеру, вычислять много матриц или тригонометрических функций. Такие вычисления затратны. OpenCL для javascript, насколько я знаю, недоступен.
webgl как будто должен быть пригоден, но у меня трудности с операцией извлечения результатов из "webgl". |
WebGL работает на стандарте OpenGL ES 3 или OpenGL ES 2 зависит от версии WebGL. Эти версии возвращают только посчитанный кадр.
Если хочешь вернуть данные вставь данные в возвращаемый кадр (RGB это целых три байта на пиксель). А со стороны JS ты можешь получить поток байтов кадра как canvas.imageData.data Хранить данные в GPU проще всего в сгенерированной текстуре (glGenTextures) а когда данные нужно передать просто отображаешь текстуру на кадр. Цитата:
Конечно паралельность исполнения это довольно абстрактное понятие но JS никогда не сможет работать с одними и теми же данными из разных потоков исполнения как в компилируемых языках. |
MallSerg,
https://www.w3.org/TR/workers/ тут как раз написано что параллельное есть отдельный поток есть синхронизация через postMessage Что для вас параллельное выполнение? :-? |
MallSerg, спасибо.
|
Цитата:
К примеру есть 20 человек с кисточками и есть задача покрасить слона. (процессы и решаемая задача) В JavaScript нельзя одновременно разным людям красить одного слона. Либо все красят строго по очереди либо каждый красит своего отдельного слона. В языках со строгой типизацией можно одновременно работать с одним объектом из разных потоков. (слон всегда слон) JS очень динамичен и с утиной типизацией никто не сможет гарантировать что один из потоков не превратит слона в ежика когда другой поток заберется по лестнице с ведром краски покрасить спинку. workers это просто отдельные потоки и взаимодействие между ними возможно только через асинхронные вызовы с передачей только примитивных типов. т.е. если снова переходить на образы один процесс покрасил свою часть слона после этого запаковывает его в контейнер и отправляет следующему потоку что бы он покрасил свою часть и так далее. такое разделение делает попытки ускорения практически бесполезными. Можно решать только отдельные не связанные задачи. |
Цитата:
дело не в компилируемости языков. Даже на c++ легко облажаться, работая с общим объектом из нескольких потоков. Чтобы всё было правильно, применяются "объекты синхронизации" - мютексы, семафоры, и т.д. Они могут заставить тот или иной поток подождать при необходимости. В js есть сообщения postMessage, с помощью которых можно было бы координировать потоки при работе с общими данными |
| Часовой пояс GMT +3, время: 00:06. |