Незважаючи на досягнення, сучасні графічні процесори все ще мають фіксовані растризатори. Високо налаштовується, з програмованими шейдерами, але, проте, не повністю програмований.

Чому так?

Чому GPU не можуть бути просто масово паралельними пристроями з універсальними обчислювальними одиницями, де rasterizer - це лише програмне забезпечення для цього пристрою, яке надає користувач?

Чи настільки вигідне виконання апаратних засобів з фіксованою функцією, що такий підхід неможливий?

Коротше кажучи, причини продуктивності - це те, що вони не програмовані.

Історія та ринок

Раніше існували окремі ядра для вершинних та фрагментальних процесорів, щоб уникнути роздутих конструкцій ПЗУ. Були деякі математичні операції, які ви могли виконувати, наприклад, у фрагменті шейдерного коду (наприклад, вони здебільшого стосувалися лише фрагментів шейдерів). Це призвело б до серйозних технічних вузьких місць для програм, які не збільшували потенціал кожного типу ядра.

По мірі того, як програмовані шейдери стали більш популярними, були введені універсальні блоки. Все більше і більше етапів графічного конвеєра реалізовувались апаратно, щоб допомогти в масштабуванні. За цей час GPGPU також став більш популярним, тому постачальникам довелося включити частину цієї функціональності. Але все ж важливо зазначити, що більшість доходів від графічних процесорів все ще були відеоіграми, тому це не може заважати продуктивності.

Зрештою великий гравець, Intel вирішив інвестувати в програмованих растризаторів зі своєю архітектурою Larrabee . Цей проект повинен був бути новаторським, але ефективність була, очевидно, меншою, ніж бажано . Його було вимкнено, а його частини були виправлені для процесорів Xeon Phi. Варто зазначити, що інші постачальники цього не реалізували.

Спроби програмного розпорошувача

Були кілька спроб растеризації за допомогою програмного забезпечення, але, схоже, всі вони мають проблеми з продуктивністю.

Одне помітне зусилля - спроба Nvidia у 2011 році у цій статті . Це було випущено близько до припинення Ларрабі, тому дуже можливо, що це було відповіддю на це. Незалежно від цього є деякі показники продуктивності, і більшість з них показують продуктивність у багато разів повільніше, ніж апаратні растризатори.

Технічні проблеми програмного забезпечення

У статті Nvidia зіткнулися багато питань. Ось декілька найважливіших проблем із програмними растризаторами:

Основні питання

• Інтерполяція: Апаратна реалізація генерує рівняння інтерполяції у спеціалізованому обладнання. Для рендерінга програмного забезпечення це повільно, оскільки це потрібно було зробити в шейдері фрагментів.

• Антизбудження: Існували також проблеми з функцією згладжування (зокрема з пам'яттю). Інформація щодо зразків субпікселів повинна зберігатися в пам'яті мікросхеми, що недостатньо для її зберігання. Жюльєн Герто зазначив, що кеш / кеш текстури може бути повільнішим для програмного забезпечення. MSAA, безумовно, має тут проблеми, тому що він переповнює кеш (нетекстурні кеші) і йде в пам'ять від чіпа. Растеризатори стискають дані, які зберігаються в цій пам'яті, що також допомагає тут.

• Споживання енергії: Саймон Ф зазначив, що споживання електроенергії буде нижчим. У статті згадувалося, що користувацькі АЛУ є у растризаторах (що зменшило б споживання електроенергії), і це мало б сенс, оскільки в одиницях обробки фрагментів та вершин раніше використовувались спеціальні набори інструкцій (так, швидше за все, і власні ALU). Це, безумовно, було б вузьким місцем у багатьох системах (наприклад, мобільних), хоча це має наслідки поза продуктивністю.

Підсумок

TL; DR: Занадто багато неефективності, через яку візуалізація програмного забезпечення не може пройти, і ці речі складаються. Існує також багато великих обмежень, особливо коли ви маєте справу з пропускною здатністю VRAM, проблемами синхронізації та додатковими обчисленнями.