Який взаємозв’язок між ядром CUDA, потоковим мультипроцесором та моделлю блоків і потоків CUDA?
Що наноситься на що і що паралелізується і як? а що ефективніше, максимізувати кількість блоків або кількість потоків?
На сьогоднішній день я розумію, що на мультипроцесор припадає 8 ядер Cuda. і що кожне ядро cuda зможе виконувати по одному блоку cuda за раз. і всі потоки в цьому блоці виконуються послідовно в цьому конкретному ядрі.
Це правильно?
Відповіді:
Схема потоку / блоку докладно описана в посібнику програмування CUDA . Зокрема, у главі 4 зазначено:
Архітектура CUDA побудована на масштабованому масиві багатопотокових потокових мультипроцесорів (SM). Коли програма CUDA на центральному процесорі викликає сітку ядра, блоки сітки перераховуються та розподіляються між мультипроцесорами з доступною робочою потужністю. Потоки потокового блоку виконуються одночасно на одному мультипроцесорі, а багатопотокові блоки можуть виконуватися одночасно на одному мультипроцесорі. Коли блоки потоків закінчуються, нові блоки запускаються на звільнених мультипроцесорах.
Кожен SM містить 8 ядер CUDA, і в будь-який час вони виконують одну деформацію з 32 потоків - тому для видачі однієї інструкції для всієї основи потрібні 4 тактові цикли. Ви можете припустити, що потоки в будь-якій заданій деформації виконуються в кроці блокування, але для синхронізації між деформаціями вам потрібно використовувати __syncthreads().
Для GTX 970 існує 13 потокових мультипроцесорів (SM) з 128 ядрами Cuda кожен. Ядра Cuda також називають потоковими процесорами (SP).
Ви можете визначити сітки, які відображають блоки на графічному процесорі.
Ви можете визначити блоки, які пов'язують потоки з потоковими процесорами (128 ядер Cuda на SM).
Одну основу завжди утворюють 32 нитки, і всі нитки основи виконуються одночасно.
Щоб використовувати всю можливу потужність графічного процесора, потрібно набагато більше потоків на SM, ніж SM має SP. Для кожної обчислювальної можливості існує певна кількість потоків, які можуть одночасно знаходитись в одній SM. Всі визначені вами блоки ставляться в чергу і чекають, поки SM отримає ресурси (кількість SP безкоштовно), після чого вона завантажується. SM починає виконувати деформації. Оскільки одна деформація має лише 32 нитки, а SM має, наприклад, 128 SP, SM може виконати 4 деформації за певний час. Річ у тому, що потоки отримують доступ до пам'яті, потік буде блокуватися, доки не буде задоволено запит на пам’ять. У цифрах: Арифметичне обчислення на SP має латентність 18-22 циклів, тоді як доступ до некешованої глобальної пам'яті може зайняти до 300-400 циклів. Це означає, що якщо потоки однієї основи чекають даних, працюватиме лише підмножина 128 SP. Для цього планувальник перемикається, щоб виконати ще одну деформацію, якщо така є. І якщо ця деформація блокує, вона виконує наступну тощо. Ця концепція називається приховуванням латентності. Кількість перекосів та розмір блоку визначають заповнюваність (від того, скільки перекосів СМ може вибрати для виконання). Якщо заповнюваність велика, малоймовірно, що для СП не буде роботи.
Твоє твердження про те, що кожне ядро cuda виконуватиме по одному блоку за раз, є помилковим. Якщо ви говорите про потокові мультипроцесори, вони можуть виконувати деформації з усіх потоків, що знаходяться в SM. Якщо один блок має розмір 256 потоків, і ваш графічний процесор дозволяє розміщувати 2048 потоків на кожну SM, то кожна SM матиме 8 блоків, з яких SM може обирати основи для виконання. Всі потоки виконуваних перекосів виконуються паралельно.
Ви знайдете номери для різних обчислювальних можливостей та архітектур графічного процесора тут: https://en.wikipedia.org/wiki/CUDA#Limitations
Ви можете завантажити аркуш розрахунку заповнюваності з аркуша розрахунку заповнюваності Nvidia (автор Nvidia) .
Дистриб'ютор обчислювальної роботи запланує блок потоків (CTA) на SM, лише якщо SM має достатньо ресурсів для потокового блоку (спільна пам'ять, перекоси, регістри, бар'єри, ...). Виділяються ресурси рівня блоку, такі як спільна пам'ять. Розподіл створює достатню кількість перекосів для всіх потоків у потоковому блоці. Менеджер ресурсів розподіляє деформації з використанням кругової програми для підрозділів SM. Кожен підрозділ SM містить планувальник деформацій, файл реєстру та блоки виконання. Після того, як деформація призначена підрозділу, вона залишатиметься в підрозділі до завершення або попереднього вибору за допомогою перемикача контексту (архітектура Паскаля). У контекстному перемикачі відновлення деформація буде відновлена до того ж SM-ідентичного деформації.
Коли всі потоки в деформації завершені, планувальник деформацій чекає завершення всіх видатних інструкцій, виданих деформацією, і тоді менеджер ресурсів випускає ресурси рівня деформації, які включають ідентифікатор деформації та файл реєстрації.
Коли всі деформації в потоковому блоці завершені, тоді звільняються ресурси рівня блоку, і SM повідомляє Compute Work Distributor про те, що блок завершено.
Після того, як деформація виділена підрозділу, і всі ресурси виділено, деформація вважається активною, що означає, що планувальник деформацій активно відстежує стан деформації. На кожному циклі планувальник деформацій визначає, які активні деформації зупиняються, а які можуть видавати інструкції. Планувальник деформацій вибирає деформацію з найвищим пріоритетом та видає 1-2 послідовних інструкції з основи. Правила подвійного випуску специфічні для кожної архітектури. Якщо деформація видає навантаження на пам'ять, вона може продовжувати виконувати незалежні інструкції, поки не дійде до залежної інструкції. Потім деформація буде повідомляти про зупинку, поки завантаження не завершиться. Те саме стосується і залежних математичних інструкцій. Архітектура SM призначена для приховування як ALU, так і затримки пам'яті, перемикаючись за цикл між перекосами.
У цій відповіді не використовується термін CUDA core, оскільки це вводить неправильну розумову модель. Ядра CUDA є конвеєрними одиницями виконання одиничної точності з плаваючою комою / цілим числом. Частота видачі та затримка залежності характерні для кожної архітектури. Кожен підрозділ SM та SM мають інші одиниці виконання, включаючи одиниці завантаження / зберігання, одиниці з плаваючою комою з подвійною точністю, одиниці з плаваючою комою з половиною точності, одиниці філій тощо
Для того, щоб максимізувати продуктивність, розробник повинен розуміти компроміс між блоками та перекосами проти регістрів / потоків.
Термін заповнення - це відношення активних деформацій до максимальних деформацій на SM. Кеплер - архітектура Паскаля (крім GP100) має 4 планувальника деформацій на кожну SM. Мінімальна кількість деформацій на одну СМ повинна бути принаймні рівною кількості планувальників деформацій. Якщо архітектура має залежну затримку виконання 6 циклів (Максвелл та Паскаль), то для покриття затримки вам знадобиться принаймні 6 перекосів на планувальник, що становить 24 на СМ (24/64 = 37,5% зайнятості). Якщо потоки мають паралельність рівня інструкцій, це може бути зменшено. Майже всі ядра видають інструкції із змінною затримкою, такі як завантаження пам'яті, що може зайняти 80-1000 циклів. Це вимагає більш активних деформацій на кожен планувальник деформацій, щоб приховати затримку. Для кожного ядра існує компромісна точка між кількістю деформацій та іншими ресурсами, такими як спільна пам'ять або регістри, тому оптимізація для 100% заповнення не рекомендується, оскільки, ймовірно, буде зроблена інша жертва. Профілізатор CUDA може допомогти визначити швидкість видачі інструкцій, заповнення та причини зупинки, щоб допомогти розробнику визначити цей баланс.
Розмір блоку нитки може вплинути на продуктивність. Якщо ядро має великі блоки і використовує бар'єри синхронізації, то бар'єрний зрив може бути причиною зриву. Це можна полегшити, зменшивши викривлення на блок ниток.
На одному пристрої є кілька потокових мультипроцесорів.
SM може містити кілька блоків. Кожен блок може містити кілька потоків.
SM має декілька ядер CUDA (як розробнику, вам не слід про це піклуватися, оскільки він абстрагований деформацією), який буде працювати на потоці. SM завжди працює над деформацією ниток (завжди 32). Деформація буде працювати лише на потоці з того самого блоку.
SM і блок мають обмеження на кількість потоків, кількість регістрів та спільну пам'ять.