Мой вопрос , что, когда у меня 384 ядра каждое, тогда , почему отображаются 2 единицы?
Простые,
вычислительные устройства на графических процессорах отличаются, имея другие кремниевые архитектуры, чем любые универсальные вычислительные устройства CISC / RISC с ЦП.
Причина ПОЧЕМУ очень важназдесь.
Устройства с графическим процессором используют S Treaming M ultiprocessor e X исполнительных единиц ( SMX единиц), которыеупоминается в некоторых инструментах проверки аппаратного обеспечения.
Хотя буква M в аббревиатуре S M X подчеркивает, на SMX-модуль можно загрузить несколько исполнений, новсе такие случаи на самом деле выполняют (конечно, только если дано указание таким образом, которое выходит за рамки этой темы, чтобы охватить / охватить все SM-ядра SMX-присутствия) одними и теми же вычислительными инструкциями -это единственный способ, которым они могут работать - это называется SIMD -типа ограниченной области параллелизма, достижимой (совместно) только по периметру SMX, где s ingle- i nstruction- m ultiple- d ata может выполняться в текущем SIMD- (WARP-wide |Возможности Scheduler в половину WARP.
Перечисленные выше эти 384 ядра означают аппаратное ограничение, сверх которого этот совместно управляемый симметричный параллелизм SIMD-типа не может расти, и всепопытки в этом направлении приведут к чисто [SERIAL] внутреннему планированию заданий GPU (да, то есть один за другим).
Понимание этих основ является кардинальным, так как безЭти особенности архитектуры, можно ожидать поведения, которое на самом деле принципиально невозможно организовать в какой-либо системе GPGPU, имеющей формальную форму [ 1-CPU-host : N-GPU-device(s) ] композиций автономных, асинхронных распределенных-system звезда узлов.
Любое ядро GPU, загруженное с CPU-хоста на GPU, будет отображаться в непустом наборе SMX-блоков, где указанное числоядер (применяется другая, более мелкозернистая геометрия вычислительных ресурсов, снова выходящая далеко за рамки этого поста) загружается потоком SIMD-инструкции, не нарушающие ограничения GPU-устройства:
...
+----------------------------------------------------------------------------------------
Max work items dimensions: 3 // 3D-geometry grids possible
Max work items[0]: 1024 // 1st dimension max.
Max work items[1]: 1024
Max work items[2]: 64 // theoretical max. 1024 x 1024 x 64 BUT...
+----------------------------------------------------------------------------------------
Max work group size: 1024 // actual max. "geometry"-size
+----------------------------------------------------------------------------------------
...
Итак,
, если 1-SM-core внутренне было дано указание выполнить некоторый модуль задачи GPU (задание GPU), только это одно ядро SM будет извлекать одну инструкцию GPU-RISC за другой (игнорируя любую возможную ILP для простоты здесь) и выполнять ее по одной за раз, проходя через поток SIMD-инструкций упомянутого GPU-задания.Все остальные ядра SM, присутствующие на одном и том же модуле SMX, обычно ничего не делают в течение этого времени, пока это задание GPU не будет завершено и внутренняя система управления процессами GPU не решит сопоставить какую-либо другую работу для этого SMX.
, если 2-SM-ядрам было поручено выполнить какое-либо задание GPU, только эта пара SM-ядер получит один (и тот же тот же ) графический процессор. -RISC-инструкция за другой (игнорируя любую возможную ILP для простоты здесь) и оба выполняют ее по одной, шагая по потоку SIMD-инструкций упомянутого задания GPU. В этом случае, если одно SM-ядро попадает в состояние, когда поток if или аналогично разветвленный, поток выполнения заставляет одно SM-ядро переходить в другой путь потока выполнения кода. чем другой, SIMD -параллелизм попадает в расходящийся сценарий, когда одно SM-ядро получает следующую SIMD-инструкцию, принадлежащую его пути выполнения кода, тогда как другое ничего не делает (получает GPU_NOP ( s)) до тех пор, пока первый не завершил всю работу (или не был вынужден остановиться на каком-то барьере синхронизации, попавшем в состояние ожидания немаскируемой задержки, при ожидании получения части данных из «далекого» (медленного) не - локальная ячейка памяти, опять же, детали выходят далеко за рамки этого поста) - только после того, как что-то из этого случается, расходящийся путь, так что только SMU-ядро под GPU_NOP может получить любую следующую SIMD-инструкцию, принадлежащую его (расходящийся) путь выполнения кода для перемещения вперед. Все остальные ядра SM, присутствующие на одном и том же модуле SMX, обычно ничего не делают в течение этого времени, пока это задание GPU не будет завершено и внутренняя система управления процессами GPU не решит сопоставить какую-либо другую работу для этого SMX.
если 16-SM-ядрам было дано указание выполнить какое-либо задание на GPU с помощью "геометрии" конкретной задачи, то только это "стадо" SM-ядер получит одно (и очень то же самое ) GPU-RISC-инструкция за другой (игнорируя любую возможную ILP для простоты здесь) и все выполняют ее по одному, шагая через поток SIMD-инструкций упомянутая работа графического процессора. Любое расхождение внутри «стада» уменьшает SIMD-эффект, и ядра, блокированные GPU_NOP, продолжают ждать, пока основная часть «стада» завершит работу (так же, как это было нарисовано прямо над этой точкой).
В любом случае, все остальные SM-ядра, не отображаемые «геометрией» конкретной задачи на SMX-модуле соответствующих GPU-устройств, как правило, вообще не будут делать ничего полезного - поэтому важность знания аппаратных деталей для правильная «геометрия» конкретной задачи действительно важна, и профилирование может помочь определить пиковую производительность для любого такого созвездия задачи GPU (различия могут варьироваться в несколько порядков - от лучшего к общему и худшему - среди всех возможных специфических для задачи » геометрия "настройки".
Во-вторых, когда у меня много ядер, как openCL распределяет задачу , это на каждом ядре один и тот же процесс и одни и те же данные или это разные ядра с разными данные?
Как объяснено вкратце выше, кремниевая архитектура устройства типа SIMD не позволяет ни одному из SMX-ядер выполнять что-либо, кроме той же самой SIMD-инструкции в целом " стадо SM-ядер, которое было отображено задачей «геометрия» на SMX-блок (не считая GPU_NOP (s) как выполняющих « что-то еще », поскольку это просто потеря процессора: время системного графического процессора).
Итак, да, ".. на каждом ядре один и тот же процесс .." (лучше, если никогда не расходится во внутренних путях выполнения кода после if или while или любой другой вид ветвления пути выполнения кода), поэтому, если алгоритм, основанный на управляемых данными значениях, приводит к различному внутреннему состоянию, каждое ядро может иметьразличное локальное состояние потока, в зависимости от которого обработка может отличаться (как проиллюстрировано приведенными выше путями исполнения кода с использованием if).Дополнительные сведения о локальных SM-регистрах, локальном SM-кэшировании, ограниченном использовании общей памяти (и затратах на задержку), использовании глобальной памяти на устройствах с графическим процессором (а также затратах на задержку, длине строк кэширования и ассоциативности для лучшего объединения шаблонов доступа для задержкиопции маскировки - многие сведения об аппаратной части + программирование экосистемы входят в небольшие тысячи страниц документации по аппаратному обеспечению + программному обеспечению и выходят далеко за рамки этого упрощенного для ясности * поста 1136 *
те же данные или это другое ядро с разными данными?
Это последнее, но не менее важное,Дилемма - любая хорошо параметризованная активация ядра GPU может также передавать некоторое количество данных внешнего мира в ядро GPU, что может отличать локальные данные потока SMX от ядра SM к ядру SM.Методы сопоставления и лучшая производительность для этого в основном зависят от устройства ({SMX | SM-регистры | GPU_GDDR gloMEM: shaMEM: constMEM | GPU SMX-локальная иерархия кэша} -детали и возможности
...
+---------------------------------------------------------
... 901 MHz
Cache type: Read/Write
Cache line size: 128
Cache size: 32768
Global memory size: 4294967296
Constant buffer size: 65536
Max number of constant args: 9
Local memory size: 49152
+---------------------------------------------------------
... 4000 MHz
Cache type: Read/Write
Cache line size: 64
Cache size: 262144
Global memory size: 536838144
Constant buffer size: 131072
Max number of constant args: 480
Local memory size: 32768
+---------------------------------------------------------
... 1300 MHz
Cache type: Read/Write
Cache line size: 64
Cache size: 262144
Global memory size: 1561123226
Constant buffer size: 65536
Max number of constant args: 8
Local memory size: 65536
+---------------------------------------------------------
... 4000 MHz
Cache type: Read/Write
Cache line size: 64
Cache size: 262144
Global memory size: 2147352576
Constant buffer size: 131072
Max number of constant args: 480
Local memory size: 32768
принципиально настолько отличаются от устройства к устройству, что каждый высокопроизводительный кодовый проект принципиально может, но профилировать свою соответствующую задачу GPU-устройства - «составление карт геометрии и использования ресурсов для фактического устройства развертывания. Что может работать быстрее на одном GPU-устройстве /Стек GPU-накопителей, не обязательно должен работать как умный на другом (или после обновления GPU-драйвера + экзо-программирования экосистемы), просто скажет только реальный тест (как теория может быть легко напечатана, но вряд ликак легко выполняемое, так как многие ограничения, специфичные для устройства и рабочей нагрузки, будут применяться в реальном развертывании).