GPGPU

Обчислення загального призначення на графічних процесорах (GPGPU, рідко GPGP або GP²U) це використання графічного процесора (GPU), який зазвичай обробляє обчислення тільки для комп'ютерної графіки, для того щоб виконанати обчислення в додатках, традиційно виконуваних центральним процесором (CPU).[1][2][3][4] Використання декількох відеокарт в одному комп'ютері, або великої кількості графічних чипів, паралелізує вже паралельну природу обробки графіки.[5] Більше того, навіть одна GPU-CPU платформа процесора забезпечує переваги, які не пропонують декілька центральних процесорів (CPU) самі по собі за рахунок спеціалізації в кожному чипі.[6]

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

Конвеєри GPGPU розроблені з наукових обчислень, багато GPGPU проектів залучені в біоінформатиці та молекулярній біології.

Історія

Обчислення загального призначення на графічних процесорах стало практичним і популярним після 2001, з появою програмованих шейдерів і підтримки обчислень з рухомою комою на графічних процесорах. Зокрема, проблеми з участю матриць і/або векторів — особливо двох-, трьох- або чотирьох-вимірних векторів — було легко перевести на GPU, який діє з рідною[уточнити] швидкістю і підтримує ці типи. Експерименти наукових обчислень з новим обладнанням почалося зі звичайного множення матриць (2001); одна з перших спільних наукових програм, що працювала швидше на GPU, ніж на центральних процесорах була реалізація LU факторизації (2005).[7]

Ці ранні спроби використовувати графічні процесори як процесори загального призначення вимагали переформулювання обчислювальних завдань з точки зору графічних примітивів, що підтримуються двома основними програмними інтерфейсами (API) для графічних процесорів: OpenGL і DirectX. Це громіздке перетворення було усунене з появою мов програмування загального призначення та інтерфейсів, таких як Sh/RapidMind, Brook та Accelerator.[8][9]

Вони супроводжувалися технологією CUDA від Nvidia, яка дозволила програмістам ігнорувати основні графічні концепції на користь більш звичних високопродуктивних обчислювальних концепцій.[7] Нові апаратні пропозиції від незалежних постачальників включали DirectCompute від Microsoft та Apple/Khronos OpenCL групи.[7] Це означає, що сучасні конвеєри GPGPU можуть виконувати дії над будь-якими операціями з великими даними(«big data») і використовувати швидкість GPU, не вимагаючи повного і явного перетворення даних в графічну форму.

Реалізація
  • OpenCL — відкритий стандарт по розробці програм котрі можуть виконуватися на графічних процесорах та центральних процесорах. Мова програмування C.
  • DirectCompute — прикладний програмний інтерфейс котрий дозволяє робити обчислення на відеоадаптері, даний інтерфейс є частиною DirectX, підтримується починаючи з 10 версії DirectX.
  • C++ AMP — бібліотека розроблена компанією Microsoft для обчислень за допомогою графічних процесорів, для роботи необхідний DirectX 11. Мова програмування C++
  • CUDA — архітектура для програмно-апаратних обчислень за допомогою графічних процесорів від компанії NVIDIA. Мова програмування C.
  • AMD FireStream — архітектура для програмно апаратних обчислень за допомогою графічних процесорів від компанії AMD.

Настільні комп'ютери

Будь-яка мова, яка дозволяє коду працюючому на центральному процесорі звернутись до шейдерів GPU для повернення значень, може створити GPGPU фреймворк.

OpenCL в даний час є домінуючою мовою з відкритим вихідним кодом для обличслень загального призначення на GPU та є відкритим стандартом, визначеним Khronos Group.[10] OpenCL забезпечує крос-платформлену GPGPU платформу, яка додатково підтримує паралельні обчисллення даних на центральних процесорах(CPU). OpenCL активно підтримується на платформах Intel, AMD, Nvidia і ARM.

Поширеним фреймворком є NVIDIA CUDA.[11] Вона випущена в 2006 році, це SDK і API який дозволяє використовувати мову програмування C для кодування алгоритмів для виконання на GPU серії GeForce 8. Стандарти програмування для паралельних обчислень включають OpenCL (незалежних постачальників), OpenACC і OpenHMPP. Марк Харріс є засновником GPGPU.org і терміну «GPGPU».

OpenVIDIA був розроблений в Університеті Торонто протягом 2003–2005 ,[12] у співпраці з NVIDIA.

Обробка GPGPU також використовується для імітації ньютонівської фізики фізичними рушіями і комерційної реалізації включаючи Havok Physics і PhysX, обидва з яких, як правило, використовуються для відеоігор.

Прискорений масивний паралелізм С++ — бібліотека, яка прискорює виконання C ++ коду, скориставшись перевагою графічного процесора.

Мобільні комп'ютери

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

Google Android 4.2 підтримує виконання Renderscript коду на графічному процесорі мобільних пристроїв. [13]

Apple представила власний програмний інтерфейс Metal для iOS додатків, здатний виконати довільний код через обчислювальні шейдери GPU.

Апаратна підтримка

Комп'ютерні відеокарти виробляються різними постачальниками, такими як NVIDIA і AMD / ATI. Карти від таких постачальників відрізняються за реалізацією підтримки формату даних, наприклад, цілочисельні і формати з рухомою комою (32-біт і 64-біт). Microsoft представила стандарт «Shader Model», щоб допомогти ранжувати різні особливості графічних карт в простому номері версій шейдерної моделі (1.0, 2.0, 3.0 і т. д.).

Цілочисельний формат даних

Графічні карти до DirectX 9 підтримували тільки палітрені або цілочисельні типи кольору. Доступні різні формати, кожен з яких містить червоний, зелений і синій елементи. Іноді додають додаткові значення альфа, які будуть використовуватися для прозорості. Загальні формати: +8 Біт на піксель — Іноді режим палітри, де кожне значення індексу в таблиці з реальним значенням вказане в одному з інших форматів. Іноді три біта для червоного, три біта для зеленого і два біти для синього. 16 біт на піксель — Звичайно виділяється у вигляді п'яти біт для червоного, шість біт для зеленого і п'ять біт для синього. 24 біт на піксель — вісім бітів для кожного з червоного, зеленого і синього 32 біт на піксель — вісім біт для кожного з червоного, зеленого, синього та альфа.

Формат даних з рухомою комою

Для початкових фіксованих функцій або обмежених можливостей програмування графіки (тобто включно до DirectX 8.1-сумісних GPU) цього було достатньо, тому що таке ж представлення використовувалось у моніторах. Таке представлення має певні обмеження. Враховуючи достатню потужність обробки графіки, навіть програмісти графіки хотіли б використовувати кращі формати, такі як формати даних з рухомою комою, щоб отримати ефекти, такі як високий динамічний діапазон зображень. Багато GPGPU додатків вимагають точності формату з рухомою комою, яка прийшла з відеокартами, відповідно до специфікації DirectX 9.

DirectX 9 Shader Model 2.x запропонувала підтримку двох типів точності: повної і часткової. Повна точність може бути FP32 або FP24 (floating point 32 — або 24-біт на компоненту) або більше, в той час як часткова точність була FP16. Серія графічних процесорів ATI R300 підтримувала точність FP24 тільки в трубопроводі програмованого фрагмента (хоча FP32 підтримувалась в вертексних процесорах), а серія Nvidia NV30 підтримує як FP16, так і FP32. Інші виробники, такі як S3 Graphics і XGI підтримують суміш форматів до FP24.

Shader Model 3.0 змінила специфікацію, збільшуючи вимоги до повної точності як мінімум до підтримки FP32 в трубопроводі фрагмента. Shader Model 3.0 в сумісності з поколінням R5xx (Radeon X1000 серії) підтримує тільки FP32 через трубопровід, а серії Nvidia NV4x і G7X раніше підтримували і повну точність FP32, і часткову FP16. Хоча це і не передбачено Shader Model 3.0, як графічні процесори ATI, так і Nvidia Shader Model 3.0 представили підтримку для змішування цілей візуалізації FP16, сприяючи підтримці високо динамічного відображення діапазону.

Векторизація

Більшість операцій на GPU працюють таким векторизованим чином: одна операція може бути виконана на чотирьох значеннях одночасно. Наприклад, якщо один колір <R1, G1, B1> буде необхідно модулювати за допомогою іншого кольору <R2, G2, B2>, то графічний процесор може виробляти результуючий колір <R1 * R2, G1 * G2, В1 * B2> в одній операції. Ця функція корисна в графіці, тому що майже кожен основний тип даних являє собою вектор (2-, 3- або 4-вимірний). Приклади включають в себе вершини, кольори, нормальні вектори, і текстурні координати. Багато інших програм можуть корисно це використати, а також через їх більш високу продуктивність, векторні команди (SIMD) вже давно доступні на процесорах.

GPU проти CPU

Спочатку, дані просто передавалися в одному напрямку з центрального процесора до GPU, а потім до пристрою відображення. Однак, з плином часу, для графічних процесорів стало цінним зберігати спершу прості, потім складні структури даних, які передаються назад в процесор, що аналізує зображення, або набір науково представлених даних у форматі 2D або 3D, що відеокарта може зрозуміти. Позаяк GPU має доступ до кожної операції малювання, він може аналізувати дані в цих формах дуже швидко; в той час як процесор повинен опитати кожен піксель або елемент даних набагато повільніше, оскільки швидкість доступу між центральним процесором і його більшим простором оперативної пам'яті (або ще у гіршому випадку, жорсткого диску) є повільніша, ніж на графічних процесорах і відеокартах, які, як правило, містять менші кількості більш дорогої пам'яті, до якої доступ можна отримати набагато швидше.

Передача частини набору даних, які будуть проаналізовані на цю GPU пам'ять у вигляді текстур або інших легко зрозумілих GPU форм призводить до збільшення швидкості. Відмінною особливістю конструкції GPGPU є здатність передавати інформацію в обох напрямках назад від GPU до CPU; як правило, швидкість передачі даних в обох напрямках є ідеально висока, в результаті чого ефект множення впливає на швидкість конкретного алгоритму високого використання. GPGPU конвеєри можуть підвищити ефективність на особливо великих наборах даних та / або даних, що містять 2D або 3D зображення. Він використовується в складних графічних конвеєрах, а також наукових обчисленнях; зокрема, в областях з великими наборами даних, таких як відображення геному, або там, де дво- або тривимірній аналіз корисний — зокрема, аналіз біомолекул, дослідження білків, і в інших складних галузях органічної хімії. Такі конвеєри можуть також значно поліпшити ефективність обробки зображень та комп'ютерного зору, поміж інших областей.

GPGPU це концепт програмного забезпечення, а не апаратного. Тим не менш, спеціалізовані конструкції устаткування можуть ще більше підвищити ефективність GPGPU трубопроводів[Що?], які традиційно виконують відносно мало алгоритмів на дуже великих обсягах даних. Масово розпаралелені завдання гігантських рівнів даних, таким чином, можуть бути розпаралелені ще більше за допомогою спеціалізованих установок, таких як обчислювальні стійки (багато подібних, вузькоспеціалізованих машин, побудованих в «стійці»), який додає третій шар — багато обчислювальних блоків кожен з яких використовує багато центральних процесорів щоб відповідати багатьом графічним.

Порівняння розробки програм під CPU та GPU
Відмінності розробки програм під CPU та GPU.
Тип відмінності CPU GPU
Створення потоку (нитки) Займає дуже багато часу Займає мало часу
Робота у потоці (нитці) Може виконуватися усе що завгодно Краще виконувати легкі математичні обчислення
Кількість потоків (ниток) Мало Дуже багато (чим більше тим краще)

Кеш

Історично, процесори використовували апаратні кеші, а ранішні графічні процесори забезпечували лише програмну локальну пам'ять. Проте, оскільки графічні процесори починали використовуватись все більше і більше для обличслень загального призначення, їх почали створювати з апаратними багаторівневими кешами,[14] що допомогло GPU просунутись у напрямку головного апаратного забезпечення для обчислень.

Регістровий файл

GPU мають дуже великі регістрові файли, що дозволяє скоротити затримки при перемиканні контексту. Розмір регістрового файлу також збільшується покоління від покоління, наприклад, загальних розмір регістрового файлу на GPU поколінь Maxwell (GM200) та Pascal відповідно 6 MiB та 14 MiB.[15][16] Якщо подивитись на розмір файлу регістрів для ЦП, то він є маленьким, зазвичай, це сотні кілобайт.[15]

Енергоефективність

Ряд науково-дослідних проектів порівняли енергоефективність GPU з CPU і FPGA.[17]

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

Обробка потоків

Графічні процесори можуть обробляти тільки незалежні вершини і фрагменти, але можуть обробляти багато з них паралельно. Це особливо ефективно, коли програміст бажає обробляти безліч вершин або фрагментів таким же чином. У цьому сенсі графічні процесори є потоковими процесорами- процесорами, які можуть працювати паралельно, запустивши одне ядро на безліч записів в потоці відразу.

Потік це є просто набір записів, які вимагають подібне обчислення. Потоки забезпечують паралелізм даних. Ядра є функцією, яка застосовується до кожного елементу в потоці. У GPU вершини і фрагменти є елементами в потоках і вершинах, і фрагменти шейдерів є ядрами які будуть працювати на них. Так як графічні процесори обробляють елементи самостійно, немає ніякого способу, щоб мати спільні або статичні дані. Для кожного елемента можна читати тільки від входу, виконувати операції на ньому, і записати на вихід. Допустимо мати кілька входів і кілька виходів, але не шматок пам'яті для читання і запису.

Арифметична інтенсивність визначається як кількість операцій, що виконуються через слово переданої пам'яті. Це важливо для GPGPU додатків мати високу інтенсивність, інакше затримка доступу до пам'яті буде обмежувати обчислювальне прискорення.[18]

Обчислювальні ресурси

Є безліч обчислювальних ресурсів, доступних на GPU:

  • Програмовані процесори — вершина, примітив, фрагмент і, головним чином, обчислювальні конвеєри дозволяють програмісту виконувати ядро на потоках даних
  • Растеризатор — створює фрагменти і інтерполяцію за вертексні константи, такі як текстурні координати і колір
  • Текстурна одиниця — інтефрейс для читання пам'яті
  • Кадровий буфер — інтефрейс для запису пам'яті

Насправді, програміст може замінити текстуру-для-запису для виведення замість буфера кадрів. Це досягається або через Рендер в текстуру ((Render to Texture)(RTT)), Render-To-Backbuffer-Copy-To-Texture (RTBCTT) (RTBCTT).

Textures as stream

Найбільш поширеною формою потоку в GPGPU є 2D сітки, тому що це відповідає природі рендеринга моделі, вбудованої в GPU. Багато обчислень мають природну карту в сітках: матричної алгебри, обробки зображень, фізичній основі моделювання, і так далі.

Kernels

Ядра можна розглядати як тіло циклу. Наприклад, програміст працює з сіткою на процесорі, і має такий код:

// Input and output grids have 10000 x 10000 or 100 million elements.

void transform_10k_by_10k_grid(float in[10000][10000], float out[10000][10000])
{
    for (int x = 0; x < 10000; x++) {
        for (int y = 0; y < 10000; y++) {
            // The next line is executed 100 million times
            out[x][y] = do_some_hard_work(in[x][y]);
        }
    }
}

На графічному процесорі, програміст визначає тільки тіло циклу як ядро та дані які потрібно зациклити (викликаючи геометричну обробку).

Керування потоком

У послідовному коді можливо контролювати потік програми використовуючи конструкцію if-then-else та різні форми циклів. Такі структури контролю потоку були недавно додані до графічних процесорів.[19]

Останні графічні процесори дозволяють розгалуження, але зазвичай із штрафом до продуктивності. Розгалужування в загальному повинно бути уникнуте у внутрішніх циклах CPU або GPU коду.

GPU методи

Операція map застосовує задану функцію (ядро) до кожного елементу в потоці. Простим прикладом є множення кожного значення в потоці на константу (збільшення яскравості зображення). Операція map проста у застосуванні на GPU: програміст генерує фрагмент для кожного пікселя на екрані і застосовує до кожного з них фрагмент програми. Результуючий потік того ж розміру збережений у вихідному буфері.[джерело?]

Редукція

Деякі обчислення вимагають обрахунок меншого потоку (потік з одного елементу) з більшого потоку. Це називається редукцією (зменшенням) потоку. Загалом, редукцію можна досягнути в декілька кроків. Результати з попереднього кроку використовуються як вхідні для наступного і до діапазону для якого операція застосовується.

Фільтрація потоку

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

Scan (сканування)

Операція сканування, також відома як паралельний префікс суми, відбувається у векторі (потоці) елементів даних і асоціативній бінарній функції '+' з одиницею 'i'. Якщо вхід [а0, а1, а2, а3, …], виключаюче сканування виробляє вихід [I, а0, а0 + а1, а0 + A1 + A2, …], у той час коли включаюче сканування виробляє вихід [а0, а0 + а1, а0 + а1 + а2, а0 + а1 + а2 + а3, …]. Хоча на перший погляд може здатися, що операція по своїй суті послідовна, ефективні алгоритми паралельного сканування можливі й були реалізовані на графічних процесорах. Операція сканування має застосування у, наприклад, швидкому сортуванні та розсіяному множенні матриці на вектор.[20][21][22][23]

Scatter (розкид)

Операція scatter є найбільш природно визначеною у вертексних (вершинних) процесорах. Такий процесор має здатність визначити позицію вершини, який дозволяє програмісту контролювати де зберігається інформація у сітці. Також можливі інші розширення, такі як контроль того, наскільки велика територія яку охоплює вершина.

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

Gather (збір)

Цей метод є зворотнім до операції розкиду. Після того як розкид впорядковує елементи щодо карти, збірка може відновити порядок елементів відповідно до карти яку використала операція розкиду.

Sort (сортування)

Операція сортування перетворює невпорядковиний набір елементів у впорядкований. Найбільш звичною імплементацією на графічному процесорі є використання порозрядного сортування для цілочисельних даних та даних з рухомою комою, крупнозернистого Сортування злиттям, та дрібнозернистих мереж сортування для загальних порівняльних даних.[24][25]

Search (пошук)

Операція пошуку дозволяє програмісту знайти конкретний елемент в потоці, або, можливо, знайти сусідів заданого елемента. GPU не використовується для прискорення пошуку для окремого елемента, але замість цього використовується для запуску декількох пошуків одночасно. В основному методика пошуку використовуєє бінарний пошук на відсортованих елементах.

Структури даних

На можна GPU представити різноманітні структури даних:

  • Щільні масиви
  • Розріджені масиви — статичні або динамічні
  • Адаптивні структури (об'єднання)

Додатки

Нижче наведені деякі області, в яких використовується обчислення загального призначення на графічних процесорах:

Див. також

Примітки
  1. Fung, et al., "Mediated Reality Using Computer Graphics Hardware for Computer Vision" Архівовано 2 квітня 2012 у Wayback Machine., Proceedings of the International Symposium on Wearable Computing 2002 (ISWC2002), Seattle, Washington, USA, 7–10 October 2002, pp. 83–89.
  2. An EyeTap video-based featureless projective motion estimation assisted by gyroscopic tracking for wearable computer mediated reality, ACM Personal and Ubiquitous Computing published by Springer Verlag, Vol.7, Iss. 3, 2003.
  3. "Computer Vision Signal Processing on Graphics Processing Units", Proceedings of the IEEE International Conference on Acoustics, Speech, and Signal Processing (ICASSP 2004) Архівовано 19 серпня 2011 у Wayback Machine.: Montreal, Quebec, Canada, 17–21 May 2004, pp. V-93 – V-96
  4. Chitty, D. M. (2007, July). A data parallel approach to genetic programming using programmable graphics hardware Архівовано 8 серпня 2017 у Wayback Machine.. In Proceedings of the 9th annual conference on Genetic and evolutionary computation (pp. 1566-1573). ACM.
  5. «Using Multiple Graphics Cards as a General Purpose Parallel Computer: Applications to Computer Vision», Proceedings of the 17th International Conference on Pattern Recognition (ICPR2004), Cambridge, United Kingdom, 23-26 August 2004, volume 1, pages 805–808.
  6. Mittal, S.; Vetter, J. (2015). A Survey of CPU-GPU Heterogeneous Computing Techniques. ACM Computing Surveys 47 (4): 1–35. doi:10.1145/2788396.
  7. DOI:10.1016/j.parco.2011.10.002
    Нема шаблону {{Cite doi/10.1016/j.parco.2011.10.002}}.заповнити вручну
  8. Tarditi, David; Puri, Sidd; Oglesby, Jose (2006). Accelerator: using data parallelism to program GPUs for general-purpose uses. ACM SIGARCH Computer Architecture News 34 (5).
  9. Che, Shuai; Boyer, Michael; Meng, Jiayuan; Tarjan, D.; Sheaffer, Jeremy W.; Skadron, Kevin (2008). A performance study of general-purpose applications on graphics processors using CUDA. J. Parallel and Distributed Computing 68 (10): 1370–1380. doi:10.1016/j.jpdc.2008.05.014.
  10. : OpenCL at the Khronos Group
  11. http://www.hpcwire.com/hpcwire/2012-02-28/opencl_gains_ground_on_cuda.html «As the two major programming frameworks for GPU computing, OpenCL and CUDA have been competing for mindshare in the developer community for the past few years.»
  12. James Fung, Steve Mann, Chris Aimone, «OpenVIDIA: Parallel GPU Computer Vision», Proceedings of the ACM Multimedia 2005, Singapore, 6-11 November 2005, pages 849–852
  13. http://developer.android.com/about/versions/android-4.2.html
  14. «A Survey of Techniques for Managing and Leveraging Caches in GPUs», S. Mittal, JCSC, 23(8), 2014.
  15. «A Survey of Techniques for Architecting and Managing GPU Register File Архівовано 26 березня 2016 у Wayback Machine.», IEEE TPDS, 2016
  16. «Inside Pascal: Nvidia's Newest Computing Platform Архівовано 7 травня 2017 у Wayback Machine.»
  17. «A Survey of Methods for Analyzing and Improving GPU Energy Efficiency», Mittal et al., ACM Computing Surveys, 2014.
  18. Asanovic, K., Bodik, R., Demmel, J., Keaveny, T., Keutzer, K., Kubiatowicz, J., Morgan, N., Patterson, D., Sen, K., Wawrzynek, J., Wessel, D., Yelick, K.: A view of the parallel computing landscape. Commun. ACM 52(10) (2009) 56-67
  19. GPU Gems — Chapter 34, GPU Flow-Control Idioms. Архів оригіналу за 26 квітня 2009. Процитовано 28 травня 2015.
  20. D. Göddeke, 2010. Fast and Accurate Finite-Element Multigrid Solvers for PDE Simulations on GPU Clusters. Ph.D. dissertation, Technischen Universität Dortmund.
  21. S. Sengupta, M. Harris, Y. Zhang, J. D. Owens, 2007. Scan primitives for GPU computing. In T. Aila and M. Segal (eds.): Graphics Hardware (2007). Архів оригіналу за 5 червня 2015. Процитовано 28 травня 2015.
  22. G. E. Blelloch, 1989. Scans as primitive parallel operations. IEEE Transactions on Computers, 38(11), pp. 1526—1538.
  23. M. Harris, S. Sengupta, J. D. Owens. Parallel Prefix Sum (Scan) with CUDA. In NVIDIA: GPU Gems 3, Chapter 39. Архів оригіналу за 16 березня 2015. Процитовано 28 травня 2015.
  24. : Merrill, Duane. Allocation-oriented Algorithm Design with Application to GPU Computing. Ph.D. dissertation, Department of Computer Science, University of Virginia. Dec. 2011.
  25. Архівовано 22 травня 2015 у Wayback Machine.: Sean Baxter. Modern gpu. http://nvlabs.github.io/moderngpu/ Архівовано 25 травня 2015 у Wayback Machine., 2013.
  26. Fast k-nearest neighbor search using GPU. In Proceedings of the CVPR Workshop on Computer Vision on GPU, Anchorage, Alaska, USA, June 2008. V. Garcia and E. Debreuve and M. Barlaud.
  27. Hasan Khondker S., Chatterjee Amlan, Radhakrishnan, Sridhar, and Antonio John K., «Performance Prediction Model and Analysis for Compute-Intensive Tasks on GPUs.», The 11th IFIP International Conference on Network and Parallel Computing (NPC-2014), Ilan, Taiwan, Sept. 2014, Lecture Notes in Computer Science (LNCS), pp 612-17, ISBN 978-3-662-44917-2.
  28. M. Cococcioni, R. Grasso, M. Rixen, Rapid prototyping of high performance fuzzy computing applications using high level GPU programming for maritime operations support, in Proceedings of the 2011 IEEE Symposium on Computational Intelligence for Security and Defense Applications (CISDA), Paris, 11-15 April 2011
  29. Wilson, Ron (3 вересня 2009). DSP brings you a high-definition moon walk. EDN. Архів оригіналу за 22 січня 2013. Процитовано 3 вересня 2009. «Lowry is reportedly using Nvidia Tesla GPUs (graphics-processing units) programmed in the company's CUDA (Compute Unified Device Architecture) to implement the algorithms. Nvidia claims that the GPUs are approximately two orders of magnitude faster than CPU computations, reducing the processing time to less than one minute per frame.»
  30. Alerstam, E.; Svensson, T.; Andersson-Engels, S. (2008). Parallel computing with graphics processing units for high speed Monte Carlo simulation of photon migration. J. Biomedical Optics 13: 060504. doi:10.1117/1.3041496.
  31. http://www.astro.lu.se/compugpu2010/
  32. Schatz, M.C., Trapnell, C., Delcher, A.L., Varshney, A. (2007) High-throughput sequence alignment using Graphics Processing Units. BMC Bioinformatics 8:474.
  33. Svetlin A. Manavski; Giorgio Valle (2008). CUDA compatible GPU cards as efficient hardware accelerators for Smith-Waterman sequence alignment url=http://www.biomedcentral.com/1471-2105/9/S2/S10. BMC Bioinformatics 9 (Suppl. 2): S10. doi:10.1186/1471-2105-9-s2-s10.
  34. GPU computing in OR Vincent Boyer, Didier El Baz. «Recent Advances on GPU Computing in Operations Research». Parallel and Distributed Processing Symposium Workshops & PhD Forum (IPDPSW), 2013 IEEE 27th International, On page(s): 1778–1787
  35. RCPSP on GPU Libor Bukata, Premysl Sucha, Zdenek Hanzalek. «Solving the Resource Constrained Project Scheduling Problem using the parallel Tabu Search designed for the CUDA platform». Journal of Parallel and Distributed Computing (2014).
  36. GPU-based Sorting in PostgreSQL Naju Mancheril, School of Computer Science — Carnegie Mellon University
  37. AES on SM3.0 compliant GPUs. Owen Harrison, John Waldron, AES Encryption Implementation and Analysis on Commodity Graphics Processing Units. In proceedings of CHES 2007.
  38. AES and modes of operations on SM4.0 compliant GPUs. Owen Harrison, John Waldron, Practical Symmetric Key Cryptography on Modern Graphics Hardware. In proceedings of USENIX Security 2008.
  39. RSA on SM4.0 compliant GPUs. Owen Harrison, John Waldron, Efficient Acceleration of Asymmetric Cryptography on Graphics Hardware. In proceedings of AfricaCrypt 2009.
  40. Teraflop Troubles: The Power of Graphics Processing Units May Threaten the World's Password Security System. Georgia Tech Research Institute. Процитовано 7 листопада 2010.
  41. Want to deter hackers? Make your password longer. MSNBC. 19 серпня 2010. Процитовано 7 листопада 2010.
  42. Lerner, Larry (9 квітня 2009). Viewpoint: Mass GPUs, not CPUs for EDA simulations. EE Times. Процитовано 3 травня 2009.
  43. W2500 ADS Transient Convolution GT. «accelerates signal integrity simulations on workstations that have NVIDIA Compute Unified Device Architecture (CUDA)-based Graphics Processing Units (GPU)»
  44. GrAVity: A Massively Parallel Antivirus Engine. Giorgos Vasiliadis and Sotiris Ioannidis, GrAVity: A Massively Parallel Antivirus Engine. In proceedings of RAID 2010.
  45. Kaspersky Lab utilizes NVIDIA technologies to enhance protection. Kaspersky Lab. 14 грудня 2009. «During internal testing, the Tesla S1070 demonstrated a 360-fold increase in the speed of the similarity-defining algorithm when compared to the popular Intel Core 2 Duo central processor running at a clock speed of 2.6 GHz.»
  46. Gnort: High Performance Network Intrusion Detection Using Graphics Processors. Giorgos Vasiliadis et al., Gnort: High Performance Network Intrusion Detection Using Graphics Processors. In proceedings of RAID 2008.
  47. Regular Expression Matching on Graphics Hardware for Intrusion Detection. Giorgos Vasiliadis et al., Regular Expression Matching on Graphics Hardware for Intrusion Detection. In proceedings of RAID 2009.
  48. Open HMPP. Архів оригіналу за 16 червня 2013. Процитовано 28 травня 2015.

Посилання
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.