Як я можу контролювати, які обчислення виконуються на процесорі, а які - на GPU?

Моє сучасне розуміння: все, що робиться у файлі шейдера, робиться на графічному процесорі, а все, що робиться в моєму (Java, в моєму випадку) коді, робиться на процесорі.

Це точний опис?

shaders gpu

— Басинатор
джерело

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

— Мило

Відповіді:

У цьому суть.

В принципі, платформа може, можливо, робити все, що завгодно. Можна уявити просунуту операційну систему, яка проводить своєчасний переклад зібраного коду з, скажімо, x86 в код GPU. Аналогічно, драйвери OpenGL можуть виконувати все, що завгодно, на хост-процесорі.

Але справді те, що ви тільки що описали, - це те, що відбувається.

— Девід ван Брінк
джерело

IIRC, шейдери складаються в ЦП перед тим, як надсилатись до GPU. І це робиться драйвером GPU без ОС.

— MSalters

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

— Басинатор

Теоретичне: Скажімо, у мене була програма, яка дуже інтенсивна в процесорі, але була просто інтерфейсом командного рядка (графічної роботи немає). Чи можу я завантажити частину роботи в GPU? Я насправді не планую робити це, мене цікавить просто концептуальна річ.

— Басинатор

Так! Посилання, яке розмістив @return true, призначене для бібліотеки Java, яка це робить. Більш загально, ви можете написати "обчислювальний шейдер" у OpenGL або використовувати OpenCL. У всіх випадках вам потрібно ізолювати частину коду, яка є паралельною, і передавати інформацію в неї та виходити з неї. (Графічні процесори, як правило, чудово підходять для «бентежно паралельних» завдань.)

— Девід Ван 18

Однією зірочкою, яку слід додати до цієї відповіді, є те, що деякі реалізації підтримують ідею «preshader» - тобто коду, який є частиною шейдера, але результат якого буде постійним для всіх викликів у заданому розіграші (наприклад, множення рівномірного перегляду) & проекційні матриці). Нахилений таким чином компілятор шейдерів може ідентифікувати такі біти коду та підняти їх до виконання після сторони процесора, включаючи отриманий постійний вихід у роботі, поданій до GPU. Це один поширений випадок, коли припущення "шейдер = GPU" може бути зігнутим, хоча лише в деталях.

— DMGregory

Взагалі, так. Java використовується для запису програм, які працюють на процесорі. Шейдерні мови (cg, hlsl та ін.) Використовуються для запису програм, які працюють на gpu.

Винятком із правила буде використання сторонніх apis, які можуть усунути прогалину.

— повернути правду
джерело

Дуже цікава порада, ваше посилання на "aparapi". Запустіть якийсь код JVM на GPU ... інтригуючий!

— Девід ван Брінк

Девід ван Брінк взагалі відповів на ваше запитання.

Але, як він каже, драйвер OpenGL міг би запускати матеріали на процесорі, а насправді трапляється багато. Особливо з контекстами сумісності, де деякі дивні застарілі функції не можуть бути реалізовані на графічних картах. Вони потребують емуляції програмного забезпечення. Наприклад, я чув, як забиття виконується на процесорі. Також ви можете очікувати сюрпризів зі збором.
Ці сюрпризи можуть траплятися ще більше на MacOS, використовуючи 2.1 контексти, тому що Apple досить добре уніфікувала уявлення про OpenGL у межах своїх апаратних комплексів, а деяким меншим апаратним обладнанням бракує деяких речей, які потрібно наслідувати. Це настільки далеко, що фактично можливо повністю виконати специфіку ENTIRE OpenGL 2.1 на процесорі, якщо код створення контексту чітко визначає програмний пристрій.

І навпаки, код, який виконується за допомогою обчислювальних бібліотек, таких як vexcl або boost compute, або Microsoft AMP, або nVidia thrust, МОЖЕ бути виконаний на графічному процесорі або процесорі залежно від прапорів установки API.

І для завершення, всередині процесора у вас також є DSP-архітектура, з частиною її, яку ми називаємо SIMD. Компілятор ispc від Intel надає допомогу в створенні коду, який "забезпечений" для запуску на смугах SIMD з великою кількістю діагностики продуктивності під час компіляції, щоб допомогти вам максимально використовувати його. Додайте OpenMP до цього, і ви можете отримати багатопотокове SIMD, яке наближається до концепцій графічних процесорів. Якщо у вас процесор високого рівня та графічний процесор низького рівня, це насправді може бути ефективнішим.
http://ispc.github.io/

— v.oddou
джерело