Можно. В контексте чистого API в WebGL1 есть два способа:
1) Срендерить текстуру на экран. И сохранить текстуру с канваса.
2) Сразу после рендеринга не переключая фреймбуффер, вызвать https://developer.mozilla.org/en-US/docs/Web/API/WebGLRenderingContext/readPixels
Как это делается в three.js — увы подсказать не могу
Водород находится в главной подгруппе первой группы. По этой характеристике он — металл.
При этом насколько я помню, водород в скобках пишут еще и в 7-й группе. По этой характеристике он — неметалл
Это зависит от криворукости написанного приложения.
Если прочитать доку, то там будет сказано, что ватчер проверяется минимум два раза. Вторая проверка делается для того, чтобы обыграть случай, когда после первого прохода один из ватчеров изменяет переменную, находящуюся под этим или другим ватчем.
Вот и я того же мнения по поводу «Turn on Microphone». Сейчас куча мобильных телефонов из Китая. Они тоже реализовывают эту мифическую «Turn on Microphone»? Сомневаюсь.
Кроме того есть старенький телефон Motorolla, где прошивку разобрали на потроха и его используют во всех подобных демонстрациях на конференциях. И я не слышал крика, чтобы в той прошивке нашли такую функциональность для микрофона. А если бы её там нашли — крик бы точно был.
OpenGL — это такое болото, в котором нужно долго разбираться, чтобы понять всю глубину наших глубин :)
По порядку.
1) Есть GPU, что есть железо. GPU бывают разные. OpenGL\DirectX — это некоторая API прослойка, которая ненапрямую дергает фукнции, реализованные в железе. За трансляцию вызовов OpenGL\DirectX в вызовы функций железа отвечает драйвер GPU, который поставляется вендором GPU.
2) Начиная с 1.0, OpenGL строился на основе расширений. Расширения предлагались в Khronos group. Последовательность повышения ранга: вендерские -> arb -> core. Вендерские реализуются только определенным вендером, например ATI или Nvidia. Когда в очередной версии расширение объявляется core, то это значит, что все GPU, у которых заявлено о поддержки данной версии OpenGL — обязаны реализовать этот фукнционал у себя (и желательно в железе, а не на уровне драйверов). Также расширение может стать EXT. Тогда оно остается опциональным и необязательно для реализации.
3) Основная особенность OpenGL 3.0 от 2.0 — это устаревание части функций API. До 3.0 ни одна функция не объявлялась устаревшей. Как, пример устаревших фукнций: стеки матриц. В 2.0 были функции glPushMatrix\glPopMatrix. В 3.0 они уже считаются устаревшими и их поведение нужно реализовывать самому(не вдаваясь в тонкости — самому более красиво получается с точки зрения архитектуры графич. движка). И если в 2.0. можно было рисовать без использования шейдеров, то в 3.0 шейдер обязательно должен быть. Нету шейдера — не тру 3.0( обратную совместимость все таки оставили). И попутно в 3.0 конечно добавили новых расширений.
4) Далее по WebGL. WebGL 1.0. делался на основе спецификации OpenGL ES 2.0, которая в свою очередь делалась на основе OpenGL 2.0. Таким образом те расширения, которые введены в core в OpenGL 3.0, в WebGL изначально отсутствуют. Но при этом есть и свои отличия.
В WebGL 1.0 изначально заложено требование о существовании шейдера. Без шейдера ты ничего не отрисуешь. И те фукнции, которые были объявлены устаревшими в OpenGL 3.0 — тут отсутствуют на корню. Поэтому это такой некий симбиоз функциональности OpenGL 2.0 и изменений, внесенных в OpenGL 3.0.
5) Для чего нужен WebGL 2.0? Нужен он чтобы сделать доступными для браузера те расширения\плюшки, которые есть в OpenGL ES 3.0\OpenGL 3.2&4.2 и без которых некоторые графические эффекты невозможно воспроизвести. Но так же это означает, что не все мобильные GPU смогут исполнить такую программу.
6) По форматам текстур. Есть такое расширение в WebGL 1.0: WEBGL_compressed_texture_s3tc. Если оно доступно — то видеокарта может использовать сжатые текстуры в форматах DXT1, DXT3 и DXT5. А это именно тот поток данных, который будет передаваться на GPU. Но это расширение не поддерживается почти всеми мобильными GPU.
Для мобильных же существует WEBGL_compressed_texture_pvrtc. Эти форматы сжатия поддерживаются многими мобильными GPU, но при этом _не поддерживаются_ настольными.
То, что в WebGL 2.0 вводят новые форматы сжатия для текстур — это хорошо, но координальных проблем не решает. Для того, чтобы получить от этого выигрыш, производителям игрушек\3D конента нужно будет предварительно сжимать свои текстуры в этот формат.
И чисто мое имхо: главная проблема производительности WEBGL сейчас — это медленная виртуальная машина js(большая зависимость от производительности CPU)
WebGL… Есть у меня задачка на WebGL. Возможно скоро выложу в публичный доступ.
Так вот, тесты показали, что WebGL очень сильно зависит от производительности CPU. То, что хорошо работает на десктопе — на WebGL будет тормозить на одном и том же железе.
При этом под виндой есть еще такая приблуда ANGLE. Если её отключить — я получал 2 мс на отрисовку кадра, что нормально при том железе, на котором я тестировал. Но включенным ANGLE — у меня получалось порядка 60-70 мс на отрисовку.
Я не использовал никаких движков, все на чистых WebGL командах. Поэтому я пока делаю такой вывод: задумка — хорошая, но для игр ААА класса — реализация слишком медленная. Не будешь ведь ты заставлять всех пользователей насильно отключать какую-то опцию в браузере, вияющую на безопасность только для того, чтобы поиграть в твою игру\посмотреть демо
После того, как скайп попал в руки MS особого смысла в нем тоже нету. Потому что сейчас весь тораффик швыряется через MSовские суперноды. И мы все под колпаком(надел шапочку из фольги)
А вы посмотрите на модель программирования, которая используется в Web Workers. Эти самые воркеры не способны использовать переменные из основного потока. Вся коммуникация основного потока строится по типу — отдали объект-параметры, получили объект результат в callback`е. Причем callback исполняется в основном потоке.
Благодаря такой модели, парадигма программирования на js не меняется. Не нужно вводить никаких примитивов синхронизации и прочих радостей, присущих многопоточным языкам.
Потому смело можно говорить, что js так и остался языком с одним потоком
Ярки представитель такого вида игр сегодня — EvE Online. Огромный мир, 50к игроков онлайн, захваты территорий, войны корпораций. Это на бумаге. А на деле 40% прыгания от планеты к планете и из системы в систему, 30% авто стрельбы по крестикам, 20% общения с другими игроками, 5% пвп и 5% фана.
Другой бы была лишь подложка из железа и некоторые алгоритмические трюки из битовой арифметики. Но эти вещи почти не влияют сейчас на компутерный мир, потому что основная доля программирования сейчас сосредаточена на манипулировании абстрактными данными в виде классов и манипулировании элементами графических интерфесов.
Поэтому мое мнение, что компутеры к этому времени были бы абсолютно такими же, как и сейчас.
Зависит от задач конечно. DSP-шки применяют обычно для того, чтобы выполнить алгоритм достаточно быстро и за малое энергопотребление. В тех же телефонах аппаратные кодеки — это и есть эти самые DSP-шки с прошивкой из оптимизированного бинарного кода.
Обычно оптимизация звукового какого-то кодека занимает от 2 до 6-х человеко-месяцев. При этом подрузамевается, что человек или группа людей уже имеет опыт такой деятельности. Но это мы выжимали из DSP все соки. Абсолютно все соки.
Основная часть оптимизаций идет за счет VLIW архитектуры. Компиляторы конечно умные, но не настолько, чтобы распараллелить алгоритм на несколько одновременных частей. Для большего понимания, на отладочной платы из статьи стоит DSP C674x. Открываем доку на эту DSP: www.ti.com/lit/ug/sprufe8b/sprufe8b.pdf
В разделе «1.2. DSP Features and Options» видим основные характеристики:
— 64 general-purpose 32-bit registers
— Eight functional units:
— — Two multipliers
— — Six ALUs
— Executes up to eight instructions per cycle
Т.е. за такт можно исполнить 2 умножения и по одной какой-то инструкции из каждого ALU. Всего — 8 инструкций за такт. Но не все комбинации процессорных команд возможны. В той же доке такие ограничения описаны например в «3.8 Resource Constraints».
И так у каждого DSP проца: своя дока, свои инструкции, свое количество регистров, свои ограничения на набор инструкций в одном пакете. Я к тому, что один раз заоптимизированный алгоритм, при переходе на другой DSP проц, приходится оптимизировать почти заново.
По итогу, жесткие оптимизации + куча человеко-времени и алгоритм начинает работать за приемлемое количество тактов процессора и становится пригоден для использования в realtime.
1) Срендерить текстуру на экран. И сохранить текстуру с канваса.
2) Сразу после рендеринга не переключая фреймбуффер, вызвать https://developer.mozilla.org/en-US/docs/Web/API/WebGLRenderingContext/readPixels
Как это делается в three.js — увы подсказать не могу
https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript
ЗЫ: к этим ребятам я никакого отношения не имею
Мне кажется у него пинг с лагом в полтора года
При этом насколько я помню, водород в скобках пишут еще и в 7-й группе. По этой характеристике он — неметалл
Если прочитать доку, то там будет сказано, что ватчер проверяется минимум два раза. Вторая проверка делается для того, чтобы обыграть случай, когда после первого прохода один из ватчеров изменяет переменную, находящуюся под этим или другим ватчем.
Кроме того есть старенький телефон Motorolla, где прошивку разобрали на потроха и его используют во всех подобных демонстрациях на конференциях. И я не слышал крика, чтобы в той прошивке нашли такую функциональность для микрофона. А если бы её там нашли — крик бы точно был.
По порядку.
1) Есть GPU, что есть железо. GPU бывают разные. OpenGL\DirectX — это некоторая API прослойка, которая ненапрямую дергает фукнции, реализованные в железе. За трансляцию вызовов OpenGL\DirectX в вызовы функций железа отвечает драйвер GPU, который поставляется вендором GPU.
2) Начиная с 1.0, OpenGL строился на основе расширений. Расширения предлагались в Khronos group. Последовательность повышения ранга: вендерские -> arb -> core. Вендерские реализуются только определенным вендером, например ATI или Nvidia. Когда в очередной версии расширение объявляется core, то это значит, что все GPU, у которых заявлено о поддержки данной версии OpenGL — обязаны реализовать этот фукнционал у себя (и желательно в железе, а не на уровне драйверов). Также расширение может стать EXT. Тогда оно остается опциональным и необязательно для реализации.
3) Основная особенность OpenGL 3.0 от 2.0 — это устаревание части функций API. До 3.0 ни одна функция не объявлялась устаревшей. Как, пример устаревших фукнций: стеки матриц. В 2.0 были функции glPushMatrix\glPopMatrix. В 3.0 они уже считаются устаревшими и их поведение нужно реализовывать самому(не вдаваясь в тонкости — самому более красиво получается с точки зрения архитектуры графич. движка). И если в 2.0. можно было рисовать без использования шейдеров, то в 3.0 шейдер обязательно должен быть. Нету шейдера — не тру 3.0( обратную совместимость все таки оставили). И попутно в 3.0 конечно добавили новых расширений.
4) Далее по WebGL. WebGL 1.0. делался на основе спецификации OpenGL ES 2.0, которая в свою очередь делалась на основе OpenGL 2.0. Таким образом те расширения, которые введены в core в OpenGL 3.0, в WebGL изначально отсутствуют. Но при этом есть и свои отличия.
В WebGL 1.0 изначально заложено требование о существовании шейдера. Без шейдера ты ничего не отрисуешь. И те фукнции, которые были объявлены устаревшими в OpenGL 3.0 — тут отсутствуют на корню. Поэтому это такой некий симбиоз функциональности OpenGL 2.0 и изменений, внесенных в OpenGL 3.0.
5) Для чего нужен WebGL 2.0? Нужен он чтобы сделать доступными для браузера те расширения\плюшки, которые есть в OpenGL ES 3.0\OpenGL 3.2&4.2 и без которых некоторые графические эффекты невозможно воспроизвести. Но так же это означает, что не все мобильные GPU смогут исполнить такую программу.
6) По форматам текстур. Есть такое расширение в WebGL 1.0: WEBGL_compressed_texture_s3tc. Если оно доступно — то видеокарта может использовать сжатые текстуры в форматах DXT1, DXT3 и DXT5. А это именно тот поток данных, который будет передаваться на GPU. Но это расширение не поддерживается почти всеми мобильными GPU.
Для мобильных же существует WEBGL_compressed_texture_pvrtc. Эти форматы сжатия поддерживаются многими мобильными GPU, но при этом _не поддерживаются_ настольными.
То, что в WebGL 2.0 вводят новые форматы сжатия для текстур — это хорошо, но координальных проблем не решает. Для того, чтобы получить от этого выигрыш, производителям игрушек\3D конента нужно будет предварительно сжимать свои текстуры в этот формат.
И чисто мое имхо: главная проблема производительности WEBGL сейчас — это медленная виртуальная машина js(большая зависимость от производительности CPU)
Так вот, тесты показали, что WebGL очень сильно зависит от производительности CPU. То, что хорошо работает на десктопе — на WebGL будет тормозить на одном и том же железе.
При этом под виндой есть еще такая приблуда ANGLE. Если её отключить — я получал 2 мс на отрисовку кадра, что нормально при том железе, на котором я тестировал. Но включенным ANGLE — у меня получалось порядка 60-70 мс на отрисовку.
Я не использовал никаких движков, все на чистых WebGL командах. Поэтому я пока делаю такой вывод: задумка — хорошая, но для игр ААА класса — реализация слишком медленная. Не будешь ведь ты заставлять всех пользователей насильно отключать какую-то опцию в браузере, вияющую на безопасность только для того, чтобы поиграть в твою игру\посмотреть демо
Благодаря такой модели, парадигма программирования на js не меняется. Не нужно вводить никаких примитивов синхронизации и прочих радостей, присущих многопоточным языкам.
Потому смело можно говорить, что js так и остался языком с одним потоком
Ярки представитель такого вида игр сегодня — EvE Online. Огромный мир, 50к игроков онлайн, захваты территорий, войны корпораций. Это на бумаге. А на деле 40% прыгания от планеты к планете и из системы в систему, 30% авто стрельбы по крестикам, 20% общения с другими игроками, 5% пвп и 5% фана.
Другой бы была лишь подложка из железа и некоторые алгоритмические трюки из битовой арифметики. Но эти вещи почти не влияют сейчас на компутерный мир, потому что основная доля программирования сейчас сосредаточена на манипулировании абстрактными данными в виде классов и манипулировании элементами графических интерфесов.
Поэтому мое мнение, что компутеры к этому времени были бы абсолютно такими же, как и сейчас.
Человеку, который не привык паять не сразу понятна вся боль этой фотографиии…
Как доказательство, вот вам картинко с английской вики:
Обычно оптимизация звукового какого-то кодека занимает от 2 до 6-х человеко-месяцев. При этом подрузамевается, что человек или группа людей уже имеет опыт такой деятельности. Но это мы выжимали из DSP все соки. Абсолютно все соки.
Основная часть оптимизаций идет за счет VLIW архитектуры. Компиляторы конечно умные, но не настолько, чтобы распараллелить алгоритм на несколько одновременных частей. Для большего понимания, на отладочной платы из статьи стоит DSP C674x. Открываем доку на эту DSP: www.ti.com/lit/ug/sprufe8b/sprufe8b.pdf
В разделе «1.2. DSP Features and Options» видим основные характеристики:
— 64 general-purpose 32-bit registers
— Eight functional units:
— — Two multipliers
— — Six ALUs
— Executes up to eight instructions per cycle
Т.е. за такт можно исполнить 2 умножения и по одной какой-то инструкции из каждого ALU. Всего — 8 инструкций за такт. Но не все комбинации процессорных команд возможны. В той же доке такие ограничения описаны например в «3.8 Resource Constraints».
И так у каждого DSP проца: своя дока, свои инструкции, свое количество регистров, свои ограничения на набор инструкций в одном пакете. Я к тому, что один раз заоптимизированный алгоритм, при переходе на другой DSP проц, приходится оптимизировать почти заново.
По итогу, жесткие оптимизации + куча человеко-времени и алгоритм начинает работать за приемлемое количество тактов процессора и становится пригоден для использования в realtime.