Intel® Graphics Technology: майже Gran Turismo


пості про «нововведення» Parallel Studio XE 2015 я обіцяв написати про цікаву технологію від Intel Graphics Technology. Власне, це я і збираюся зробити зараз. Суть Intel® Graphics Technology полягає у використанні інтегрованого в процесор графічного ядра для виконання обчислень на ньому. Це оффлоад (offload) на графіку, що, природно, дає приріст продуктивності. Невже інтегрована графіка настільки потужна, що цей приріст буде дійсно великий?
Давайте подивимося на сімейство нових графічних ядер GT1, GT2 і GT3/GT3e, інтегрованих в процесори 4-го покоління Intel® Core™.

Так, графіка була і в 3-му поколінні, але це вже «справи минулих днів». Ядро GT1 має мінімальну продуктивність, а GT3 — максимальну:
HD (GT) HD 4200,
HD 4400,
HD 4600 (GT2)
HD 5000,
Iris 5100 (GT3),
Iris Pro 5200 (GT3e)
API DirectX 11.1, DirectX Shader Model 5.0, OpenGL 4.2, OpenCL 1.2
Число
виконавчих
блоків (Execution Unit)
10 20 40
Число FP операцій
за такт
160 320 640
Число потоків на
виконавче
пристрої / всього
7 / 70 7 / 140 7 / 280
GPU складається з шарів (slice). Така структура спрощує дизайн і виробництво, а можливі конфігурації містять½, 1 і 2 шари (GT1, GT2 і GT3 відповідно):

Тобто для випадку з GT1 все буде майже так само, тільки «шар» потрібно розрізати навпіл по горизонталі. Ми не будемо розмінюватися на дрібниці, і зупинимося на можливостях графіки GT3e, як найбільш просунутого прикладу. Отже, маємо 40 виконавчих блоків по 7 потоків на кожен блок. Разом у нас є до 280 потоків! Непогана прибавка потужності для «мотора» нашої системи!
При цьому кожному потоку доступно з 4 KB регистровом файлі (GRF — General Register File) — найбільш швидкої доступною для графіки пам'яті для зберігання локальних даних. Загальний розмір файлу складає 1120 KB.
Взагалі, модель пам'яті становить великий інтерес і схематично може бути представлена так:

Крім регістрів, графіку доступний свій кеш L3 (256 KB на кожен «шар»), а також LLC (Last Level Cache), який є L3 процесорним кешем і, таким чином, загальним для CPU і GPU. З точки зору обчислень на GPU, кешу L1 і L2 немає. Тільки у самої потужної конфігурації GT3e доступний ще 128 МБ кеша eDRAM. Він знаходиться в одному корпусі з процесорним компонентом, але не є частиною кристала Haswell, і відіграє важливу роль у збільшенні продуктивності вбудованої графіки, майже ліквідуючи залежність від оперативної пам'яті (DRAM), частина якої так само може бути використана в якості відеопам'яті.

Далеко не всі версії процесорів мають ту саму інтегровану графіку. Серверні моделі воліють мати значно більше обчислювальних ядер замість графіки, тому випадки, в яких можливо застосування Graphics Technology, істотно звужуються. Я нарешті дочекався лептопа з Haswell'ом і вбудованої в процесор графікою Intel® HD Graphics 4400, а, значить, можна погратися з Intel® Graphics Technology, яка підтримується на 64 бітних системах Linux, а так само на 32 і 64 бітних Windows системах.

Власне, на вимогу до «заліза» все зрозуміло — без нього про обчислення на графічному ядрі говорити безглуздо. В документації (так, так… мені навіть довелося її почитати, бо відразу все не запрацювало) сказано, що все має працювати з цими моделями:
  • Intel® Xeon® Processor E3-1285 v3 and E3-1285L v3 (Intel® C226 Chipset) з Intel® HD Graphics P4700
  • 4е покоління Intel® Core™ процесорів Intel® Iris™ Pro Graphics, Intel® Iris™ Graphics або Intel® HD Graphics 4200+ Series
  • 3е покоління Intel® Core™ процесорів Intel® HD Graphics 4000/2500
Залізниця підходить, компілятор з підтримкою GT поставлений. Все має полетіти!» — подумав я, і почав збирати семпли, що поставляються з компілятором для Graphics Technology.

З точки зору коду, нічого екстраординарного я не помітив. Так, з'явилися якісь прагми перед циклами cilk_for, на зразок таких:

void vector_add(float *a, float *b, float *c){
#pragma offload target(gfx) pin(a, b, c:length(N))
cilk_for(int i = 0; i < N; i++)
c[i] = a[i] + b[i];
return;
}

Про це ми поговоримо докладно в наступному пості, а поки спробуємо зібрати семпл з опцією /Qoffload. Начебто все скомпилировалось, але помилка про те, що лінкер (ld.exe) не може бути знайдений, мене трохи призупинила. Виявилося, я упустив один важливий момент і не все так тривіально. Довелося покопатися в документації.

Виявилося, що програмний стек для виконання програми з оффлоадом на інтегровану графіку виглядає так:

Компілятор не вміє генерувати код, який відразу може виконуватися на графіку. Він створює IR (Intermediate Representation) код під vISA (Virtual Instruction Set Architecture) архітектуру. А той у свою чергу може виконуватися (конвертуватися в рантайме) на графіку за допомогою JIT'тера, що поставляється в інсталяційному пакеті з драйверами для Intel® HD Graphics.

При компіляції нашого коду з використання оффлоада для Graphics Technology, генерується объектник, який «вшита» частина, виконувана на графічному ядрі. Цей загальний файл називається fat. При лінкування таких от «товстунів» (fat объектников), — код, що виконується на графіку, буде в секції, вбудованої в бінарники на хості, званої .gfxobj (для випадку Windows).
Ось тут то стає зрозуміло, чому не перебував лінкер. У компілятор Intel немає і не було свого лінкера, причому що на Linux, що на Windows. А тут в один файл «зашити» объектники в різних форматах. Простий лінкер від Microsoft робити цього не вміє, тому потрібно поставити спеціальну версію binutils (2.24.51.20131210), доступну тут, а потім і прописати нехай до того самого ld.exe (в моєму випадку C:\Program Files (x86)\Binutils for MinGW (64 bit)\bin) в PATH.
Після установки всього необхідного, я в підсумку зібрав тестовий проект на Windows і отримав наступне:
dumpbin matmult.obj
Microsoft ® COFF/PE Dumper Version 12.00.30723.0
Copyright © Microsoft Corporation. All rights reserved.
Dump of file matmult.obj
File Type: OBJECT COFF
Summary
48 .CRT$XCU
2C .bss
5D0 .data
111C .data1
148F4 .debug$S
68 .debug$T
32F .drectve
33CF8 .gfxobj
6B5 .itt_notify_tab
8D0 .pdata
5A8 .rdata
AD10 .text
D50 .xdata

Потрібний объектник для виконання на графіку можна витягти з fat объектника за допомогою спеціального інструменту (offload_extract). Якщо в нашій консолі виставлено оточення для запуску компілятора Intel, зробити це досить просто:
offload_extract matmult.obj

В результаті в течці можна знайти окремий объектник з приставкою GFX в кінці, в моєму випадку — matmultGFX.o. Він, до речі, вже ні разу не PE формат, а в ELF'е.

До речі, якщо оффлоад неможливий і графічне ядро недоступна під час запуску програми, виконання відбувається на хості (CPU). Це досягається з допомогою засобів компілятора і оффлоад рантайма.
З тим, як все повинно працювати ми розібралися. Далі будемо говорити про те, що доступно розробнику і як написати код, який у підсумку буде працювати на графіку.
Інформації виявилося так багато, що в рамках одного поста все ніяк не поміщається, тому, як кажуть, «далі буде...».

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.