Поки мені вдалося з’ясувати, що відбувся перехід від дуже спеціалізованої схеми, яка реалізує різні етапи графічного конвеєра, до більш загального підходу. Це перетворення було частково відображено на 3D API у вигляді програмованих шейдерів. Більшість транзисторів, здається, присвячені масово паралельним SIMD-одиницям, які виконують фактичні вказівки щодо шейдера.
Правильно. В основному, завдяки відносно великому розміру функцій на старих графічних процесорах, єдиним способом ефективної реалізації таких речей, як основне освітлення, антиаліазія, відображення текстури, геометрія тощо, було використання конвеєра "фіксованої функції". Вони пожертвували гнучкістю заради продуктивності, оскільки не мали достатньої щільності чіпа, щоб можна було реалізувати її, використовуючи загальну масово паралельну архітектуру SIMD, як поточні GPU.
Це сучасний графічний процесор (думаю Nvidia Fermi) - це в основному набір "дурних" масивів SIMD, які подаються з інструкціями та даними з процесора та різних кеш-пам'яток, а вся фактична логіка, яка відображає графічний конвеєр до цих інструкцій, відбувається в графічному драйвері ?
Деякі речі все ще робляться апаратними засобами; інші - ні. Наприклад, ROP все ще використовуються на самому завершальному етапі для введення піксельних даних у чіпсет VGA. Примітка. Я тут використовую "VGA чіпсет" як загальний термін для позначення механізму, який передає відеосигнал на ваш монітор, незалежно від того, чи справді це "VGA" в будь-якому відношенні.
Правда, загалом, що сучасні архітектури GPU, такі як Nvidia Fermi та AMD Southern Islands, здебільшого є масово паралельними процесорами, де у них встановлений набір інструкцій, і кожне окреме "ядро" надзвичайно слабке, але є цілому багато ядер (іноді кілька тисяч). Але все ж є обладнання для графіки:
Апаратне декодування відео часто робиться, в значній мірі, за допомогою фішок з фіксованою функцією. Особливо це стосується DRM (управління цифровими обмеженнями). Іноді "апаратне" декодування відео дійсно означає керований програмним набором інструкцій, які просто виконуються як звичайні старі завдання для ядер SIMD. Це дійсно залежить.
За винятком дуже небагато комп'ютерних плат Nvidia (Tesla), майже всі відеокарти "generic SIMD" мають повний набір апаратних засобів, призначених для виведення відео. Вихід відео не є таким же, як візуалізація; Вихідні елементи з фіксованою функцією включають кодеки LVDS / TMDS / HDMI / DisplayPort, HDCP і навіть обробку аудіо (в основному трохи DSP), оскільки HDMI підтримує звук.
"Графічна пам'ять" все ще зберігається на борту з графічними процесорами, так що їм не доведеться обходити балаканину і відносно високу затримку шини PCIe для потрапляння на оперативну пам'ять, яка сама повільніше і займає більше часу, ніж реагувати на більш дорогі, більш висока якість, швидша графічна пам'ять (наприклад, GDDR5), яка має меншу ємність, але більша швидкість, ніж системна пам'ять. Процес зберігання матеріалів у графічній пам’яті та відновлення їх звідти в GPU або до процесора все ще є значною мірою фіксованою функцією. Деякі графічні процесори мають свій власний тип "IOMMU", але цей блок управління пам'яттю відрізняється від ЦП. Однак це неправда для останніх процесорних процесорів Intel, інтегрованих у їхні процесори (Sandy та Ivy Bridge), де архітектура пам'яті майже повністю "узгоджена" системна пам'ять) і зчитування з графічної пам’яті так само дешево для процесора, як і для GPU.
Чи є де-небудь контрольні блоки десь у графічному процесорі, які переводять вхідні потоки інструкцій та даних високого рівня (компільовані шейдерні програми, вершинні дані та атрибути та текстури) у фактичні інструкції SIMD та дбають про синхронізацію, розподіл пам'яті тощо?
"Рідна" мова SIMD майже завжди генерується драйвером у програмному забезпеченні, а не власним програмним забезпеченням GPU. Особливо це стосується функцій рівня DirectX 9 / OpenGL 2.x. Шейдери, написані мовами високого рівня, такими як асемблер шейдерів HLSL, GLSL або OpenGL ARB, врешті-решт водієм переводяться в інструкції GPU, натискаючи на певні регістри та виконуючи необхідні обручі PCIe для того, щоб пересилати пакетні буфери обчислення та / або візуалізувати команди.
Декілька речей, як-от апаратна tessellation (DirectX 11 / OpenGL 4.0), знову заносяться в апаратне забезпечення фіксованою функцією, подібно до того, як раніше вони робили майже все. Це тому, що, знову ж таки, обмеження продуктивності вимагають, щоб найефективніший спосіб зробити ці обчислення - це виділити схему для цього, а не мати прошивку або драйвер, "програмуючи" SIMD, щоб це зробити.
Я підозрюю, що реальність знаходиться десь між цими двома крайнощами, і відповідь була б досить тривалою та ґрунтувалася на безлічі спекуляцій (певні виробники GPU повинні бути причиною відмовитись від публікації будь-якої документації на свою продукцію, не кажучи вже про водія вихідний код ...), але будь-які натяки в правильному напрямку та корисні ресурси були б дуже вдячні.
AMD та Intel мають дуже надійну документацію щодо своїх останніх графічних процесорів, а також повноцінних графічних драйверів з відкритим кодом для Linux (див. Проекти Mesa та Direct Rendering Manager). Якщо ви подивитесь на якийсь код у цих драйверах, ви посмієтесь, адже авторам графічних драйверів насправді доводиться реалізовувати геометрію речей, таких як малювання різних фігур або візерунків, у "програмному забезпеченні" (але за допомогою апаратних команд для подання реальних робота над апаратним забезпеченням для обробки), тому що ні прошивка графічного процесора, ні фіксований функціонал більше не доступні для повного опрацювання апаратними засобами :) Смішно, що вони повинні робити для підтримки OpenGL 1.x / 2.x на новому обладнання.
Еволюція пройшла так:
- Дуже давно (до того, як 3D-рендерінг в реальному часі вважався можливим): відстеження променів на процесорі було нормальним для візуалізації в режимі реального часу. Для такої простої графіки, як ви бачите в ранніх версіях Windows, процесор був достатньо швидким для малювання простих фігур (прямокутників, символів шрифту, затінення візерунків тощо) без апаратних засобів з фіксованою функцією, але він не міг намалювати занадто складні речі.
- Давно (OpenGL 1.x): майже все реалізовано твердотільним обладнанням; "електричні" фіксовані функції були нормою навіть для основних операцій
- Нещодавно назад (OpenGL 2.x): почався перехід до того, щоб зробити GPU більш програмованими. "Фрагментні шейдери" (також піксельні шейдери) на 5-річному апаратному забезпеченні можуть майже виконувати довільні обчислення, як процесор, але це обмежено архітектурою, яка все ще дуже орієнтована на графіку. Отже, OpenCL / DirectCompute недоступні для цього обладнання.
- Останнім часом (OpenGL 3.x): Перехід до графічних процесорів загального призначення здебільшого завершений, але вони, звичайно, оптимізовані для робочих навантажень, що містять великі матриці даних (думаю, лінійна алгебра), що надсилаються партіями, а не процесори, які можуть ефективно працювати на довгі послідовності дуже малих даних (1 + 1, 2 * 4, 5 * 6 в послідовності тощо). Обчислення загального призначення доступні через OpenCL, CUDA тощо. Але обладнання все ще не є повноцінним "SIMD-копроцесором" тому що (а) вам все одно доведеться забивати конкретні апаратні регістри, щоб дістатися до функціональності GPU; (b) зчитування з VRU GPU відбувається дуже повільно через накладні витрати шини PCIe (зчитування з GPU не дуже оптимізовано для поточної архітектури); (c) архітектура пам'яті та кешу не є когерентною процесором; багато застарілого обладнання для фіксованих функцій все ще залишається навколо.
- Present (OpenGL 4.x): позбувся багато застарілого обладнання для фіксованих функцій. Дещо покращена затримка читання GPU. IOMMU дозволяють проводити (перекладене) апаратне забезпечення картування між VRAM і системною пам'яттю. Також запроваджена апаратна tessellation, повертаючи елементи фіксованої функції.
- Майбутнє ( HSA): GPU в основному є спільним процесором. Він майже повністю інтегрований з процесором з дуже невеликим опором (для читання / запису) між графічним процесором і процесором, навіть для виділених графічних процесорів на шині PCIe. Повністю когерентна архітектура пам'яті - "mi memoria es su memoria" (моя пам'ять - це ваша пам'ять). Програми простору користувачів можуть читати з "VRAM" так само, як вони читають із системної пам'яті, не маючи драйву драйвера, і апаратне забезпечення дбає про це. У вас є процесор для "серійної" обробки (зробіть це, потім зробіть це, потім зробіть це, потім зробіть це) для скромних кількостей даних, і GPU для "паралельної" обробки (виконайте цю операцію на цьому величезному наборі даних і розділіть його вгору, як вважаєте за потрібне). На платі, на якій сидить GPU, все ще можуть бути ROP, кодек HDMI та ін., Але цей матеріал необхідний для виводу дисплея,