Comments 18
Она не умеет считать double и, как правило, очень плохо работает с int
С чего бы вдрг GPU плохо работать с целочисленными данными вообще?
Меня заинтересовал ваш комментарий, поэтому я немного поискал в сети. Всё, что я нашёл из интересного, лишь это: Throughput of Native Arithmetic Instructions. (Number of Results per Clock Cycle per Multiprocessor).
Возможно да, вы правы, операции с целыми числами не медленные. Я нашёл других примеров. Возможно всякие там корни/синусы, но не знаю. Может быть потеря производительности будет на преобразовании типов.
Буду признателен, если вы разовьёте эту тему.
Возможно да, вы правы, операции с целыми числами не медленные. Я нашёл других примеров. Возможно всякие там корни/синусы, но не знаю. Может быть потеря производительности будет на преобразовании типов.
Буду признателен, если вы разовьёте эту тему.
Я тоже бегло гуглил, вместо однозначных ответов нашлись в основном реплики на форумах, но все эти реплики были в духе «integer performance seems to still lag behind float32 performance significantly» (отсюда)
Опровергнуть изначальное утверждение о том, что GPU работает c int медленно, не представляет труда. Так, GPU производит рендер в RGBA32 surface (как правило). Т. е. 32 бита на один пиксел, 4 целочисленные беззнаковые компоненты. Следовательно, целочисленный беззнаковый формат данных является «родным» для GPU, и они отлично с ним работают.
Дальше всё становится несколько сложнее. В своё время очень плотно работал с GPGPU вычислениями на мобильных платформах (ARM Mali серий 600 и 700). Этот GPU построен на основе 128 битных ALU, нативным форматом данных для них является как раз int. Возможна была векторизация от 8 x uint8_t до 2 x uit64_t.
Если заглянуть на 7-8 лет назад, то во времена архитектуры Terascale (VLIW5 и VLIW4) от АМД, то в состав потоковых процессоров входили 4 целочисленных ALU и один блок для тригонометрии. Их железо неплохо описано в статьях Аnandtech за 2010 год. Там с целочисленными операциями тоже не было проблем.
Что происходит с архитектурой GPU на данный момент, сказать затрудняюсь (отошёл несколько от GPGPU-дел), но не думаю, что за 4-5 лет произошли какие-то фундаментальные изменения. Вкратце — нет никаких предпосылок для того, чтобы GPU плохо работали с целочисленными данными.
Далее. Потребительские GPU не слишком хорошо работают с double, потому что такой тип данных даёт избыточную точность для графических вычислений. Однако, потребительские карточки Radeon первых поколений архитектуры GCN, например, поддерживали такую фичу, причём на половинной скорости от float32, если мне не изменяет память. Когда покупал дешёвый ноутбук с Radeon 8570M был очень удивлён нативной поддержкой double. Ну а GPU для дата-центров работают с double безо всяких проблем, потому что для научных вычислений двойная точность необходима.
Дальше всё становится несколько сложнее. В своё время очень плотно работал с GPGPU вычислениями на мобильных платформах (ARM Mali серий 600 и 700). Этот GPU построен на основе 128 битных ALU, нативным форматом данных для них является как раз int. Возможна была векторизация от 8 x uint8_t до 2 x uit64_t.
Если заглянуть на 7-8 лет назад, то во времена архитектуры Terascale (VLIW5 и VLIW4) от АМД, то в состав потоковых процессоров входили 4 целочисленных ALU и один блок для тригонометрии. Их железо неплохо описано в статьях Аnandtech за 2010 год. Там с целочисленными операциями тоже не было проблем.
Что происходит с архитектурой GPU на данный момент, сказать затрудняюсь (отошёл несколько от GPGPU-дел), но не думаю, что за 4-5 лет произошли какие-то фундаментальные изменения. Вкратце — нет никаких предпосылок для того, чтобы GPU плохо работали с целочисленными данными.
Далее. Потребительские GPU не слишком хорошо работают с double, потому что такой тип данных даёт избыточную точность для графических вычислений. Однако, потребительские карточки Radeon первых поколений архитектуры GCN, например, поддерживали такую фичу, причём на половинной скорости от float32, если мне не изменяет память. Когда покупал дешёвый ноутбук с Radeon 8570M был очень удивлён нативной поддержкой double. Ну а GPU для дата-центров работают с double безо всяких проблем, потому что для научных вычислений двойная точность необходима.
Что-то забыли упомянуть 3dfx перед nVidia и их Diamond monster 3D за несколько лет до GeForce 256.
Почему Metal Compute Shaders — крутая технология, изменившая всё.
Почему? Я плохо читал наверно, но я не увидил отличий от OpenCL.
У Metal достаточно тонкий API, и это единственный графический API, который объектно-ориентирован.
DirectX смотрит на вас с недоумением.
Metal, как бы намекающий своим названием «очень близко к железу».
Настолько «близко», что аж кэширует все запросы к GPU.
Поэтому, в отличие от OpenGL, здесь работа устроена так, что CPU и GPU работают параллельно друг с другом. Пока CPU читает кадр номер N, в это время GPU рендерит предыдущий кадр N-1, и так далее
ТО есть у нас есть «низкоуровневый» Mental, в котором встроена синхронизация и кэширование, и «высокоуровневый» OpenGL, в котором синхронизация и кэширование делается на уровень выше…
Где-то здесь противоречие… Нет?
Кстати, это в целом не то чтобы прям очень крутая штука. Тот же UE вполне справляется с реализацией аналогичного подхода на стандартном OpenGL.
По факту, этот подход хуже чем одновременный рендер и расчет. Проблема только в том, что сделать одновременный расчет и рендер очень сложно так, чтобы никто никого не блокировал. Поэтому и делают отдельный поток на рендер и отдельный на расчет. Это МЕДЛЕННЕЙ. В первую очередь из-за того, что много данных вместо того, чтобы просто уехать на GPU — сначала кэшируются. Но в общем случае это БЫСТРЕЕ, потому что программисты не умеют или не могут делать правильно.
Да автор свою альтернативную/сектантскую историю продвигает, специально не касаясь DirectCompute, AZDO и прочего.
Двоякое впечатление от статьи/презентации.
С одной стороны интересный материал, полезный для ознакомления начинающим программистам. С другой — ощущение, что от фаната Apple фанатам Apple.
Ну и факт что «доклад стал одним из фаворитов конференции, получив высокие оценки зрителей» говорит либо о том, что зрители не понимали о чём им втирают, либо готовы простить грубые неточности раз речь о любимой платформе.
С одной стороны интересный материал, полезный для ознакомления начинающим программистам. С другой — ощущение, что от фаната Apple фанатам Apple.
Ну и факт что «доклад стал одним из фаворитов конференции, получив высокие оценки зрителей» говорит либо о том, что зрители не понимали о чём им втирают, либо готовы простить грубые неточности раз речь о любимой платформе.
Так и не понял, что в технологии от apple прорывного, хоть бы сравнили с тем же вулканом.
Очевидным ответом на попытку изобрести «пишите только под меня» является использование библиотек, которые скрывают любые выкрутасы вендоров и дают единообразный API для приложения на устройствах любого вендора. Очередная версия libncurses, но для 3d-графики.
Рекомендую вообще не смотреть в сторону Metal, а использовать Vulkan, с недавних пор его можно запустить и на OS X — github.com/KhronosGroup/MoltenVK
У нас будет массив с миллионом элементов, в каждый из которых записана единица, и константа, на которую будем умножать. Сравнивать мы будем вот с тем, как эту же задачу решали бы на CPU. Будем надеяться, что стало быстрее. И действительно это так: Metal выполняет в среднем за 0.006 секунды, а CPU за 0.1. То есть на CPU примерно в 17 раз медленнее, что должно нас порадовать.
Подождите, 10М операций в секунду это же крайне мало для CPU. Вы что, хотите сказать, что Swift компилируется в код, который работает медленне Питона?
In [7]: arr = [1.0] * 1000000
...: def run():
...: for i in xrange(len(arr)):
...: arr[i] = arr[i] * 2.0
...:
In [8]: %time run()
Wall time: 79.2 ms
Забавно что сказали про CUDA, а вот про OpenCL ни слово, хотя он может делать все тоже самое что и Metal Compute Shaders, все те же ядра, очереди, буферы и т.п., но при этом его можно запускать и на iOS и на Mac, и на Android и на Windows, причем как на GPU, так и на CPU, а если очень захотеть то и на FPGA. Так что преимуществ использования именно Metal'a перед OpenCL не видно.
Sign up to leave a comment.
Как стать GPU-инженером за час