Pull to refresh

Comments 26

Нет чтобы производительность в OpenCL улучшить, они свою CUDA пилить начали. Ну удачи в догонялках.

Как написала vikky13, CM действительно долгое время разрабатывался в Intel, но не был публично анонсирован и задокументирован. Например, давайте возьмем официальный GPU драйвер от 2015 года, найдем там библиотеку igfxcmrt32.dll и если посмотрим список экспортируемых ей функций, то найдем упоминавшуюся в статье CreateCmDevice. Да, эта библиотека CM runtime от 2015 года. Т.е. CM ведет свою историю, как минимум, со времен Sandy Bridge / Ivy Bridge процессоров, для встроенной графики которых, этот драйвер и предназначен. Сейчас Intel вывела эту технологию в свет, предоставив кроссплатформенное решение, документацию и даже код, что не может не радовать.

Если же проводить аналогии, то CM очень похож на CUDA от Intel и похоже, что позиционируется точно также. Он не вместо OpenCL, который Intel тоже развивает, а вместе. Если необходима универсальность и переносимость, используется OpenCL, если необходимо выжать из железки максимум, тогда CM.
Со стороны Intel таких планов пока нет, но всё же открыто — может, кто-то и напишет.
Импортировать библиотеку и сделать managed оболочку для хоста должно быть не так уж сложно, даже не творческая задача. Но будет иметь свою цену, хотя и небольшую. Интереснее было бы расковырять, что внутри хостовых классов и реализовать напрямую. Конечно, это будет unsafe код.
Как считаете, если завтра AMD, Imagination Technologies, ARM и другие производители собственных GPU скажут «OpenCL не очень, мы выкатываем свой API», разумно ли это будет?
Откуда отличия в производительности c OpenCL версией в 8 раз?
Если это фундаментальные ограничения OpenCL (в чём я крайне сомневаюсь), не лучше ли участвовать в развитии открытого стандарта и сделать так, чтобы в следующей версии отличий в производительности не было?
Что касается NVidia — они очень любят пилить своё собственное, но при этом исправно реализуют уже принятые стандарты. Да, CUDA лично мне кажется удобнее OpenCL. Но я не встречал, чтобы отличия в производительности с OpenCL выходили за 15-20%. Как же у Intel получилось 700% разницы?
Выкатывают, потому что он уже есть, и стоит им $0.
Вероятно, дальше посмотрят чего хорошего придумает сообщество и портируют к себе в закрытую часть.
Вы задаете отличный вопрос… для тех, кто не читал этот пост. Для тех, кто читал, увы — ответ в посте есть. Честное интеловское :) К нему можно добавить, что да — производительность OpenCL постоянно улучшается, да и oneAPI виден на горизонте. C for Metal нисколько этим усилиям не противоречит.
Вопросов было несколько, а ответа не получил ни одного.
Вместо ответов — только поучение в стиле «Сам дурак, читай пока не поймёшь». Так себе техническое обсуждение.
Что же касается «C for Metal нисколько этим усилиям не противоречит» — если инженеры занимаются этим бесплатно в свободное от работы время, то я согласен.
Если это их основная оплачиваемая работа, то всё-таки сначала хорошо бы разобраться с Intel'овской реализацией OpenCL, а затем уже предлагать свой велосипед, который быстрее/выше/сильнее.
Я вам открою секрет. В Intel — достаточно инженеров для разных задач. Ну и еще один секрет не открою, а повторю — скопирую из текста поста — «Много лет ICM использовался внутри Intel в разработке продуктов для обработки медиа на Intel GPU»
Откуда отличия в производительности c OpenCL версией в 8 раз?
транспонирующего матрицу битовых значений 16х16, преимущество в производительности «прямого программирования» Intel GPU в сравнении c OpenCL версией будет 8 раз!
почти наверняка в opencl (а скорее всего в компиляторе) нет оптимально реализованных битовых операндов

p.s. полагаю такой пример выбран не зря как наихудший, но впечатление у читателя остается именно как основной недостаток opencl, классических подход рекламщиков
Спасибо, что нашли опечатку. Я не заметила :( Конечно же, значения не битовые, а байтовые. Поправила… И я честно пишу, что это максимальный эффект — когда происходит изменение порядка данных.
у меня была мысль что транспонировать битовую матрицу — странно но не стал писать что это ошибка

говорите разница реализаций нативно и на opencl по перестановке значений в восемь раз хуже? можно посмотреть исходники?

Исходников OpenCL у меня нет, но их легко найти. Исходники ICM для матрицы 8х8 — можно посмотреть в примере gaussian_blur_test из ICM пакета. Там нет абсолютно никаких хитростей — все очень просто и наивно.


  matrix<uint, 8, 8> out;
  for( int i = 0; i < height; i += 8 ) {
    read( INBUF, id * 32, i, in );
    out.row(0) = in.column(0);
    out.row(1) = in.column(1);
    out.row(2) = in.column(2);
    out.row(3) = in.column(3);
    out.row(4) = in.column(4);
    out.row(5) = in.column(5);
    out.row(6) = in.column(6);
    out.row(7) = in.column(7);
    write( OUTBUF, i * 4, id * 8, out );</source>
А как выглядит код, работающий в 8 раз быстрее?

А это он и есть. То, что приведено выше (если поменять размеры матрицы на 16х16), работает в 8 раз быстрее реализации OpenCL. C 8x8 просто никто не мерил :)

А что будет, если запустить на AMD?
Поясните для особо одаренных, которые не понимают даже после повторного прочтения статьи: зачем нужен «велосипед»? Какая магия позволяют icm быть быстрее ocl на стандартных алгоритмах? Что это за «некоторая функциональность для распространенных алгоритмов», которую ocl не поддерживает?
Или смысл в том, что используется отличная от ocl абстракция при описании данных, которая позволяет проще выполнить оптимизацию для конкретного железа?
Напустили туману так, что остается только гадать.
Тут два момента, явно отмеченных в статье. Первый — OpenCL — не векторный по своей природе. Компилятор пытается его векторизовать внутри, но никакая автовекторизация по эффективности не может сравниться с ручной, которая лежит в основе C for Metal. Но главное — OpenCL работает с элементами поэлементно (хотя там и есть векторы фиксированной длины и рабочие группы, но это не сильно меняет дело), а в основе C for Metal — именно работа с группой элементов, причем, нефиксированного размера). Именно поэтому такой выигрыш именно в транспонировании — любом переупорядочивании этих элементов.
То-есть по сути это си с векторными интринзиками и типами? Типа как __m128/float32x4_t _mm_shuffle_ps/vcombine_f32? Но что мешает тогда использовать их в OpenCL? В nvidia драйвере полно таких вендорных расширений, их только проверить надо перед использованием, более того, можно ptx asm вставку сделать.
Если всё очень сильно упростить (на порядок), то да. Что мешает? Мешает архитектура OpenCL, явно созданная для скалярной работы by design. Хотя появление расширений там неизбежно, скорость нужна всем.
Простите, но в OpenCL есть векторые типы (например, int2/int4/int8/int16) и поддерживаются операции над ними. Чем это отличается от CM?

В CM векторы могут иметь произвольную длину, а также существуют матрицы и поверхности. Это значительно влияет на производительность и возможности для целого ряда алгоритмов. Кроме того, в CM вся обработка — векторная, а в OpenCL это векторные фрагменты — именно о них можно думать как о векторных intinsic вставках в скалярный код.

С каких это пор ocl «не векторный»? Да, во многом «векторизация» задачи лежит на программисте. Но, это даже лучше, чем любая «внутренняя» векторизация компилятора.

Что значит «работает поэлементно»? Когда пишешь ядро, ты программируешь конкретный элемент комп. юнита, да, но следишь и реализовываешь решение так, чтоб суперпозиция доступа к памяти из разных элементов как раз и представляла собою вектор в том или ином виде. Это основнейшая основа разработки эффективных ядер ocl. В этом плане, ocl позволяет «выстрелить себе в ногу», да. Но, это признак определенной гибкости инструмента.

Я как то даже и не припомню задач в своей практике, быстродействие которых, по итогу оптимизации, не уперлась бы в пропускную способность памяти. И дизасм ядра под конкретную архитектуру gpu каждый раз выглядел вполне эффективно. Так что, с моей точки зрения, утверждения вида «ocl не векторный» выглядят ну очень странно, вы уж меня простите.
Задача — транспонирование матрицы :)) Но вообще — в посте описано как потратив около 10 минут времени запустить на вашей системе уже реализованный пример, например, линейного фильтра (или еще десяток варантов), увидеть скорость его работы и сравнить с самой эффективной реализацией OpenCL.
Почему то сразу вспомнился драгоценный камень Intel GMA 3600.
Sign up to leave a comment.