Javascript.RU

Создать новую тему Ответ
 
Опции темы Искать в теме
  #1 (permalink)  
Старый 11.05.2018, 08:38
Интересующийся
Отправить личное сообщение для ГеннадийС Посмотреть профиль Найти все сообщения от ГеннадийС
 
Регистрация: 27.04.2018
Сообщений: 26

webgl и javascript
А кто нибудь пробовал использовать вычислительные мощности графических ускорителей для параллельных вычислений в javascript?
Ответить с цитированием
  #2 (permalink)  
Старый 11.05.2018, 23:46
Аватар для j0hnik
Профессор
Отправить личное сообщение для j0hnik Посмотреть профиль Найти все сообщения от j0hnik
 
Регистрация: 01.12.2016
Сообщений: 3,650

ГеннадийС,
Все руки никак не дойдут, кроме как для gl это особого смысла не имеет тут процессора с головой как правило хватает.
Если у вас какой то опыт есть пишите.
Ответить с цитированием
  #3 (permalink)  
Старый 12.05.2018, 00:27
Аватар для MallSerg
Профессор
Отправить личное сообщение для MallSerg Посмотреть профиль Найти все сообщения от MallSerg
 
Регистрация: 07.03.2011
Сообщений: 1,126

Графические ускорители так аппаратно устроены что они всегда производят вычисления параллельно любое использование GPU для любых задач это параллельные вычисления иначе их использование теряет смысл.
JavaScript никогда не сможет исполнятся параллельно следовательно он никогда не сможет исполнятся на GPU.
webgl - это API которое предоставляет среда исполнения т.е. это обычные свойства и методы как и все остальное апи браузера.
С использованием webgl можно передавать видеокарте шейдерные программы которые буду компилироватся и исполнятся на GPU также можно передавать данные (uniform переменные) картинки(текстуры) буферы вершин и.т.д. и получать результаты в виде изображения которое строит GPU.
В любом случае все сводится к написанию шейдерных программ.
Использовать для этого апи браузера глупо для таких задач в разы проще и быстрее использовать специальные инструменты (компиляторы в GPU шейдеры)
Например питон -> CUDA или же OpenCL для C/C++

Но если ты крутой чувак то ничего не мешает тебе писать шейдеры самому в блокнотике и исполнять их через webgl API браузера. Принципиальной разницы и ограничений нет.
Ответить с цитированием
  #4 (permalink)  
Старый 12.05.2018, 00:30
Аватар для j0hnik
Профессор
Отправить личное сообщение для j0hnik Посмотреть профиль Найти все сообщения от j0hnik
 
Регистрация: 01.12.2016
Сообщений: 3,650

Сообщение от MallSerg
JavaScript никогда не сможет исполнятся параллельно следовательно он никогда не сможет исполнятся на GPU.
может с помощью web worker
Ответить с цитированием
  #5 (permalink)  
Старый 12.05.2018, 06:57
Интересующийся
Отправить личное сообщение для ГеннадийС Посмотреть профиль Найти все сообщения от ГеннадийС
 
Регистрация: 27.04.2018
Сообщений: 26

MallSerg, я говорил о случаях, когда нужно, к примеру, вычислять много матриц или тригонометрических функций. Такие вычисления затратны. OpenCL для javascript, насколько я знаю, недоступен.

webgl как будто должен быть пригоден, но у меня трудности с операцией извлечения результатов из "webgl".
Ответить с цитированием
  #6 (permalink)  
Старый 12.05.2018, 09:42
Аватар для MallSerg
Профессор
Отправить личное сообщение для MallSerg Посмотреть профиль Найти все сообщения от MallSerg
 
Регистрация: 07.03.2011
Сообщений: 1,126

WebGL работает на стандарте OpenGL ES 3 или OpenGL ES 2 зависит от версии WebGL. Эти версии возвращают только посчитанный кадр.
Если хочешь вернуть данные вставь данные в возвращаемый кадр (RGB это целых три байта на пиксель). А со стороны JS ты можешь получить поток байтов кадра как canvas.imageData.data
Хранить данные в GPU проще всего в сгенерированной текстуре (glGenTextures) а когда данные нужно передать просто отображаешь текстуру на кадр.

Цитата:
может с помощью web worker
Это не паральное исполнение а раздельное. Именно потому что JS не пригоден для параллельных вычислений и придумали специально АПИ которое запускает отдельные и независимые скрипты не создавая отдельные страницы (раньше для этого использовали iframe).
Конечно паралельность исполнения это довольно абстрактное понятие но JS никогда не сможет работать с одними и теми же данными из разных потоков исполнения как в компилируемых языках.
Ответить с цитированием
  #7 (permalink)  
Старый 12.05.2018, 11:44
Аватар для j0hnik
Профессор
Отправить личное сообщение для j0hnik Посмотреть профиль Найти все сообщения от j0hnik
 
Регистрация: 01.12.2016
Сообщений: 3,650

MallSerg,
https://www.w3.org/TR/workers/
тут как раз написано что параллельное
есть отдельный поток
есть синхронизация через postMessage

Что для вас параллельное выполнение?
Ответить с цитированием
  #8 (permalink)  
Старый 12.05.2018, 11:47
Интересующийся
Отправить личное сообщение для ГеннадийС Посмотреть профиль Найти все сообщения от ГеннадийС
 
Регистрация: 27.04.2018
Сообщений: 26

MallSerg, спасибо.
Ответить с цитированием
  #9 (permalink)  
Старый 04.07.2018, 00:54
Аватар для MallSerg
Профессор
Отправить личное сообщение для MallSerg Посмотреть профиль Найти все сообщения от MallSerg
 
Регистрация: 07.03.2011
Сообщений: 1,126

Сообщение от j0hnik Посмотреть сообщение
MallSerg,
https://www.w3.org/TR/workers/
тут как раз написано что параллельное
есть отдельный поток
есть синхронизация через postMessage

Что для вас параллельное выполнение?
Ну если совсем образно ....
К примеру есть 20 человек с кисточками и есть задача покрасить слона. (процессы и решаемая задача)
В JavaScript нельзя одновременно разным людям красить одного слона. Либо все красят строго по очереди либо каждый красит своего отдельного слона.
В языках со строгой типизацией можно одновременно работать с одним объектом из разных потоков. (слон всегда слон)

JS очень динамичен и с утиной типизацией никто не сможет гарантировать что один из потоков не превратит слона в ежика когда другой поток заберется по лестнице с ведром краски покрасить спинку.

workers это просто отдельные потоки и взаимодействие между ними возможно только через асинхронные вызовы с передачей только примитивных типов.
т.е. если снова переходить на образы один процесс покрасил свою часть слона после этого запаковывает его в контейнер и отправляет следующему потоку что бы он покрасил свою часть и так далее.
такое разделение делает попытки ускорения практически бесполезными.
Можно решать только отдельные не связанные задачи.
Ответить с цитированием
  #10 (permalink)  
Старый 06.07.2018, 11:12
Аватар для Alexandroppolus
Профессор
Отправить личное сообщение для Alexandroppolus Посмотреть профиль Найти все сообщения от Alexandroppolus
 
Регистрация: 25.10.2016
Сообщений: 1,004

Сообщение от MallSerg
Конечно паралельность исполнения это довольно абстрактное понятие но JS никогда не сможет работать с одними и теми же данными из разных потоков исполнения как в компилируемых языках.
ну вообще-то тенденция уже наметилась - https://developer.mozilla.org/ru/doc...redArrayBuffer

дело не в компилируемости языков. Даже на c++ легко облажаться, работая с общим объектом из нескольких потоков. Чтобы всё было правильно, применяются "объекты синхронизации" - мютексы, семафоры, и т.д. Они могут заставить тот или иной поток подождать при необходимости.
В js есть сообщения postMessage, с помощью которых можно было бы координировать потоки при работе с общими данными
Ответить с цитированием
Ответ



Опции темы Искать в теме
Искать в теме:

Расширенный поиск


Похожие темы
Тема Автор Раздел Ответов Последнее сообщение
Книга: JavaScript. Сильные стороны Magneto Учебные материалы 16 21.04.2013 15:28
Интерпретатор Java на JS kobezzza Оффтопик 24 11.10.2012 18:32
Первый Moscow JavaScript Meetup korenyushkin Общие вопросы Javascript 0 26.07.2011 15:23
Последние книги по JavaScript! monolithed Учебные материалы 7 26.10.2010 19:40
Выдвет ошибку JavaScript Ромио Opera, Safari и др. 4 21.10.2010 20:34