Gpu accelerated прискорення в chrome.

Відео: Enable GPU Acceleration and canvas 2d in Google Chrome (hardware acceleration)

Ця стаття містить довідкову та детальну інформацію про реалізації апаратного прискорення композиції в Chrome .Традиційно, веб-браузери покладаються цілком на процесор для відображення вмісту веб-сторінок. Cпособность графічних процесорів стає невід`ємною частиною навіть найменшого з пристроїв і з багатими медіа, таких як відео і 3D-графіка і грає все більш важливу роль для роботи в Мережі, розробники Crome звернули свою увагу на пошук шляхів більш ефективного використання базового обладнання для досягнення більш високої продуктивності і енергозбереження.

Явна ознака того, що GPU бере безпосередню участиев композиції змісту веб-сторінки може призвести до дуже значних прискорень. Найзначніші успіхи мали прийти від усунення непотрібних (і дуже повільних) копій великих обсягів даних, особливо копії з видео пам`яттю в системну пам`ять. Найбільш очевидні кандидати для такої оптимізації

З поточним ООН-ускореніме здійснюються композиції з RenderLayer і посідають місце в коді WebKit (через Skia або CG). В архітектурі H / W прискорення, композиції з H / W прискорених шарів змішуються з рештою вмісту сторінки відбувається звернення до GPU на платформі 3D API (GL / D3D). Код в кінцевому рахунку, відповідає за прийняття цих викликів ув`язнених в бібліотеці і працює всередині процесу Renderer. Бібліотека істотно підвищує використання GPU для композитних прямокутних областей сторінки в одній растрових зображень.
Процес GPU.
Обмежений у sandbox, процес Renderer (де знаходяться WebKit і композитор) не може бути вимогою до 3D API, що надаються ОС (GL / D3D). З цієї причини ми використовуємо окремий процес, щоб зробити рендеринг. Ми називаємо цей процес GPU процесом. GPU процес спеціально призначений для забезпечення доступу до 3D API-інтерфейсу системи зсередини sandbox Renderer.Он працює за допомогою моделі клієнт-сервер з клієнтом під час виконання програми, що працює в обмеженому середовищі та серверним кодом, який фактично робить звернення до графіку API, яка працює наступним чином:
• клієнт (програми, що працюють в Renderer або всередині модуля NaCl), замість видачі звернень до системи API, серіалізуются їх і поміщає в кільцевої буфер (Ctrl буфера), що знаходяться в пам`яті, спільно використовуваними між собою і процесом сервера.
• Сервер (GPU процес, запущений з меншим обмеженням sandbox, що дозволяє отримати доступ до платформи 3D API,) піднімає серіалізовані команди із загальної пам`яті, аналізує їх і виконує відповідні виклики графіки, виводячи їх безпосередньо у вікні.

Відео: How to enable and disable GPU Hardware acceleration in google chrome - Fix for fraps

команди прийняті GPU процесом тісно пов`язані з GL ES 2.0 API (Наприклад, чи є команда відповідна glClear, від одного до іншого glDrawArrays і т.д.). Оскільки більшість GL звернень не повертають значення клієнт і сервер можуть працювати в основному асинхронно, це містить витрати процесу на низькому рівні. Вся необхідна синхронізація між клієнтом і сервером, такі як повідомлення клієнт сервера, є додаткова робота, яку треба зробити, здійснюється через механізм IPC. Варто також відзначити, що на додаток для зберігання загальної пам`яті буфера команд, використовується для передачі великих ресурсів, таких як растрові зображення для текстур, вершини масивів і т.д. між клієнтом і сервером. З точки зору клієнта додаток має можливість або писати команди безпосередньо в команду буфера або використати GL ES 2.0 API за допомогою бібліотеки на стороні клієнта, які ми надаємо і який обробляє серіалізаціі.Для зручності WebGL в даний час використовується клієнтом GL ES бібліотеки. На стороні сервера, команди, отримані за допомогою буфера команд перетворюються в обігу до будь-якого робочого столу GL (на Mac і Linux) або D3D (у вікнах).
В даний час Chrome використовує єдиний процес GPU в браузері, наприклад, запити від всіх процесів візуалізації і будь-який процес виконання плагінів. GPU процес однопотоковий, його можна мультиплексировать між декількома буферами команд, кожна з яких пов`язана з її власним контекстом рендеринга.
архітектура GPU процесу пропонує кілька переваг, включаючи:
• Безпека: частина логіки залишається в ізольованих процесах рендеринга.
• Надійність: аварії GPU процесу (наприклад, через несправні драйверів) не збивають браузер.
• Однорідність Стандартизація на OpenGL ES 2.0 в якості надання API для браузера незалежно від платформи дозволяє бути простіше в обслуговуванні коду по всіх портах ОЗ Chrome.
Наборщик коду
Основна частина коду Chrome для здійснення композиції знаходиться в платформі WebCore`s / Графіка / Chrome каталогу. Логіка композиції в основному в LayerRendererChromium.cpp і реалізація різних типів зібраного шару в Фото файлів LayerChromium.cpp. Набір здійснюється у верхній частині GL ES 2.0 клієнтської бібліотеки, яка використовує проксі графіки виклику GPU процесу.
Всі пікселі сторінки малюються прямо у вікні за допомогою GPU процесу. Наборщик підтримує ієрархію GraphicsLayers яка будується шляхом обходу дерева RenderLayer і оновлюється по мірі зміни сторінки. За винятком WebGL і відео шарів, зміст кожного з шару спочатку звертається в растровому зображенні системної пам`яті, а потім завантажується в текстуру. Наборщик відстежує, які верстви були змінені з моменту останнього часу коли вони були складені і оновлює текстури в міру необхідності. Зміст сторінки робиться після першого обходу ієрархії GraphicsLayer і малювання текстур Quad для кожного шару з відповідним перетворенням.

Як мінімум один графічний контекст, при виконанні H / W прискорення, GPU процес, використовується в складача. Але, в присутності GPU-прискореного змісту сторінки (наприклад, WebGL або Pepper3D плагін), GPU процес повинен бути в змозі маніпулювати mutliple в контекстах графіки, кожен з яких пов`язаний зі своїм власним буфером команд, в загальній пам`яті IPC каналу і контексту GL. Склад GraphicsLayers, вміст яких створюється безпосередньо на GPU працює так, що замість них виявляється прямо в backbuffer, в якому вони перетворюються на текстуру (с використанням Frame Buffer Object), який контекст вистачає і використовує при рендеринге шару. Важливо відзначити, що для того, щоб GL контекст мав доступ до текстурі породженої закадровим контекстом GL, GL всіх контекстів повинен використовувати GPU процес при якому створюються такі ресурси. В результаті архітектура виглядає наступним чином:

Використовуйте - включити прискорення композиції прапора в командному рядку, з тим щоб складач спрацював на будь-який з трьох платформ і у верхній частині сторінки Як згадувалося раніше, прискорення в WebKit (і Chrome) Вмирає тільки тоді, коли є певні типи контенту на сторінці. Легкий трюк, щоб змусити сторінки перейти до композиції є установка WebKit-перетворення: translateZ (0) для елемента на сторінці.

P.P.S. Якщо у Вас є питання, бажання прокоментувати або поділитися досвідом, напишіть, будь ласка, в коментарях нижче.