2010-06-05 5 views
2

Я проверяю ночные сборки Firefox и Chromium с поддержкой WebGL с несколькими демонстрациями и учебниками, и я не могу не задаться вопросом о чрезвычайно высокой загрузке процессора, которую они вызывают.Высокая загрузка процессора с помощью WebGL?

Простая демонстрация like this one работает на устойчивом 60% моего двойного ядра. Большая версия this one выводит CPU на 100% и имеет видимую потерю кадров.
Хром, кажется, немного лучше, чем firefox, но не сильно. Я уверен, что если бы это были настольные приложения, загрузка процессора была бы незначительной.

Так что же здесь происходит? что он делает? Выполнение простых сценариев из них не может быть столь требовательным. Это дополнительный уровень безопасности или что-то еще?


Edit: я нашел оригинальную демонстрацию, которая была porded к WebGL здесь: http://rrrola.wz.cz/files/puls_win.zip

Запуск этого (на весь экран) получает процессор с замедленным 48%, так что, возможно, я был неправ ...

+0

Я предполагаю, что переключатели контекста по-прежнему дороги. От JS до Native до GPU. –

+0

контекстный переключатель на GPU? да? Вы имеете в виду синхронизацию между CPU и GPU? Там не должно быть много, если таковые имеются, OpenGL удаляет команды рендеринга в буфер и передает их на GPU, GPU синхронизирует результаты с экраном, используя своп-буфер в определенных точках рендеринга, но CPU не участвует в этом вообще. –

+0

@Ben, однако контекст переключается на ядро ​​при каждом вызове opengl ... – shoosh

ответ

4

Действительно, webgl работает медленно. Безусловно, это новый, он использует программный композитор. Итак, в основном это GPU - CPU - GPU вызывает только один кадр. И firefox, и webkit работают над этим

+2

Вторым я расскажу об этом в EWGL. Спецификация WebGL требует, чтобы отображаемый 3D-холст мог быть скомпонован с другими элементами HTML на странице (например, чтобы текст мог отображаться поверх него).Это означает, что графический процессор отображает сцену, затем процессор получает копию и объединяет ее с визуализированным HTML, который затем отправляется обратно на графическую карту для отображения. Итак, GPU-CPU-GPU на каждом кадре; это дорого. Автор браузера фиксирует проблему - IIUC в будущем, GPU выполнит композицию. –

-1

Графический рендеринг чрезвычайно насыщен CPU, поэтому есть видеокарты с графическим процессором, поэтому вместо них можно загружать работу. Я попробую свои демонстрации и посмотрю, как они идут на моем компьютере, на котором установлена ​​достойная видеокарта.

+0

Этот компьютер имеет nVidia 8600, который более чем способен обрабатывать их. – shoosh

+0

ok не собираюсь делать это снова LOL. Графический процессор моей плохой видеокарты направлялся на расплавление. Итак, WebGL по-прежнему работает, и позволяет просто сказать, что требуется больше оптимизации. Кстати, мой процессор не был сильно забит. Я использую nVidia 7900GS, поэтому я думаю, что пришло время для обновления :( – Khorkrak

1

Невозможно воспроизвести проблему с производительностью. Первый работает на скорости 98-100 кадров в секунду, используя только одно ядро ​​моего Core i5. Второй использует около 50% одного ядра.

Это с каналом Chrome dev, Windows 7 64-bit, Radeon HD 5770, другими словами, умеренно мощная современная машина.

Также обратите внимание, что небольшой размер кода не соответствует быстрому, когда есть много итераций (и эти демоверсии имеют много полигонов).

+0

Неужели вам не кажется странным, что он использует полное ядро, чтобы сделать в основном целую кучу ничего? – shoosh

Смежные вопросы