Новый виток архитектуры CUDA

    Всем привет!
    В начале апреля я увидел анонс новой видеокарты от nVidia, с новым мажорным индексом compute capability – 3.0. Внимательно изучив спеки был удивлён – по всему выходило, что теперь ветвления будут приводить к самым худшим последствиям: большим потерям производительности. Мне нравилось, что от версии к версии ветвления играют всё меньшую роль, а Kepler показался в этом плане шагом назад. Мозгом я понимал, что такое вряд ли возможно и решил немного выждать.
    И вот на этой неделе мне пришёл whitepaper по новой числодробилке на архитектуре Kepler и многое прояснил.

    Начала


    Изначально эта заметка задумывалась только для тех, кто в теме, но на всякий случай поясню что такое compute capability в CUDA.
    Итак, компания nVidia разрабатывает видеокарты для общих вычислений вот уже 5 лет. Не сказать, что до этого нельзя было считать на GPU, но делать это было весьма некомфортно для нормального человека. В 2007 году была предложена универсальная архитектура для вычислительных устройств (CUDA) на базе видеокарт. Это позволило экстенсивно наращивать мощность устройств, сохраняя при этом основные особенности архитектуры. То есть количество процессоров и объём памяти постоянно растут, а вот разделение памяти на shared/global/texture и регистры так и сохраняются ещё с тех давних времён (с СС 2.0 появились также surface и пара кэшей, но это уже другая песня).
    Однако ничто не стоит на месте и архитектура и набор команд со временем изменяются – иногда значительно, иногда не очень. Вот для отображения семейств GPU с идентичной архитектурой и были определены версии Compute сapability (СС). Для примера: устройства с CC 1.0 не умели делать атомарных операций вообще, с СС 1.1 – умели в глобальной памяти а с СС 1.2 – и в глобальной и в shared. Полный список возможностей разных СС традиционно приводится в конце CUDA C Programming Guide.

    Что принесёт нам Kepler?


    Во-первых – новый огромный мультипроцессор. Если раньше мультипроцессоры имели 8 (CC 1.x), 32 (CC 2.0) или 48 (СС 2.1) потоковых процессоров, то в Kepler используется новый чип на 192 процессора. Остальные характеристики тоже впечатляют:
    FERMI GF100 FERMI GF104 KEPLER GK104 KEPLER GK110
    Версия CC 2.0 2.1 3.0 3.5
    Потоков в Warp'e 32 32 32 32
    Число warp'ов на мультипроцессор 48 48 64 64
    Потоков на мультипроцессор 1536 1536 2048 2048
    Блоков на мультипроцессор 8 8 16 16
    32-битные регистры на мультипроцессор 32768 32768 65536 65536
    Максимальное количество регистров/поток 63 63 63 255
    Конфигурации количества shared-памяти 16К
    48К
    16К
    48К
    16К
    32К
    48К
    16К
    32К
    48К
    Максимальный размер grid по оси X 2^16‐1 2^16‐1 2^16‐1 2^32‐1
    Hyper‐Q Нет Нет Нет Есть
    Динамический параллелизм Нет Нет Нет Есть

    Какие выводы можно сделать из этой таблички? Размер warp'а остался тем же, и это – гуд. Главное, чего я опасался – это увеличение размера варпа, что привело бы к лишним простоям при ветвлениях. Но не всё так радужно. С регистрами теперь нужно быть ещё аккуратнее – чтобы максимально загрузить SMX (по количеству одновременно загруженных блоков/потоков) их нужно использовать ещё меньше… С другой стороны, архитектура позволяет хранить до 255 регистров на поток и если раньше железно работал постулат «лучше заново вычислить, чем хранить», то сейчас не всё так однозначно. Таким образом у нас появилась ещё одна вилка в пути оптимизации – можно хранить результаты вычислений в потоке, но тогда на SMX поместится меньше блоков и вполне возможно будут наблюдаться простои на чтения/запись в RAM.
    Можно ещё вскользь заметить, что вычисления двойной точности и спец. функции (sin, cos и тд) теперь будут выполняться быстрее и это радует.
    Второе заметное нововведение – новый Warp Scheduler. На каждый мультипроцессор приходятся 4 скедулера и каждый из них умеет исполнять 2 инструкции варпа за такт. Короче, интересная штучка. Следите, чтобы внутри варпа ветвления шли максимум по 2 путям)
    Дальше непонятные штуки:
    Dynamic Parallelism – вааще не понял как это будет работать, но похоже потоки смогут запускать новые grid'ы… Посмотрим, как оно будет. Похоже скоро на хосте будет только I/O, а всё остальное можно будет и на GPU запускать, раз уж есть возможность управлять kernel'ами.
    GPUDirect – теперь можно взять и перекинуть данные с одной GPU на другую напрямую, без хоста. И даже по сети. Пока не увижу – не поверю. Звучит слишком круто.
    Всякие приятные мелочи:
    • Shuffle Instruction – новый способ обмена данными между потоками в блоке. Если лень выделять отдельную shared mem и управлять доступом к ней, то берём локальную переменную и жонглируем ей от потока к потоку.
    • Атомарные операции с двойной точностью. Ну, добавили парочку. Главное – обещают ускорение до 9 раз!
    • Новый read only кэш данных. В Fermi появились L1 и L2 кэши данных, а в Kepler можно отмечать данные как read only (
      const __restrict
      ), чтобы компилятор запихивал их в этот новый кэш. А раньше я для этого данные в текстурки запихивал. Эх.
    • Улучшили L2 кэш. Во-первых, он стал в 2 раза больше, а во-вторых, доступ к нему в 2 раза быстрее.
    • Hyper‐Q, Grid Management Unit – в Fermi появилась возможность запускать несколько задач одновременно. А вот эти 2 технологии позволяют делать это правильно, но работают они на аппаратном уровне и мы это заметим только из более полной загрузки GPU.

    И наконец, очень классное – nVidia продали души пары инженеров богам энергопотребления и теперь GTX 680 обещает кушать меньше чем аналогичная Fermi из расчёта W/FLOPS. Ну ведь круто, а? Прям хоть выкидывай старые 280 ПЕЧки. А то греются до 130 градусов и про запас на них 1,5 кВт пришлось выделять.

    Вывод


    Короче, не знаю как вы, а я прям с нетерпением буду ждать новых Kepler! Только не знаю, удастся ли добраться до двух компов с GPU СС 3.5 – чтоб GPUDirect пощупать. Если будет у кого – дайте потрогать, ладно?
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 116

      +3
      Скедулер… Как я рад слышать старый добрый английский!
      Сорри за оффтоп, статья очень по существу.
        +4
        schedule
        ['ʃedjuːl], ['skeʤuːl]
          0
          Что произносится либо «шедъюл» (британский вариант), либо «скеджл» (американский), но никак не «скедул».
          • UFO just landed and posted this here
              0
              Извиняюсь, упустил «у». Просто, часто слышал этот звук весьма незаметным и смазанным.

              В любом случае, никак не «скедул» все равно.
                0
                На работе от американцев часто слышу именно «скедул»/«скедьюл», без «ж».
              0
                0
                Спасибо за ссылку. До этого если бы в разговоре услышал британский вариант произношения, скорее всего даже не понял о чём речь.
              0
              А я от своих американских коллег слышу «скеджъул»
            +3
            Есть хоть один топик с этим словом без холивара о его произношении?
            +3
            Мои тесты показали, что один и тот же код (молотилка хешей) на GTX 680 работает в 1,5 раза медленней, чем на GTX 580. По мне так это epic fail. Пусть даже и энергопотребление уменьшилось.
              +3
              Тут явно просится повторная оптимизация. Увеличение FLOPS/Вт произошло не на пустом месте. Кроме перехода на техпроцесс 28 нм, была существенно снижена частота потоковых процессоров. Раньше они работали на удвоенной частоте, а теперь используют обычную частоту ядра. Роста FLOPSов добились увеличением количества процессоров. Если посмотреть, то количество процессоров утроилось, частота ядра выросла ещё в полтора раза по сравнению с Fermi. А вот FLOPSы только удвоились (хотя должны были увеличиться в 4,5 раза).
              Поэтому сами процессоры стали ещё медленней и фокус оптимизации должен быть смещён на максимальную загрузку всех 1536 SP в GPU. Возможно в задаче создаётся слишком мало блоков? Или блоки слишком тяжеловесные (используют много регистров на поток). Тогда их будет помещаться меньше на SMX. Для Kepler во многих задачах регистров нужно использовать меньше, а больше уповать на кэширование и использование read only кэша.
              Короче, при всех новых фишках – для HPC по-прежнему нужно хорошо знать подноготную архитектуры, которая с каждым годом становится всё более развесистой. Без этого использовать CUDA на всю катушку не получится.
                0
                Производительность блоков Double Precision Float Point на GK104 сильно порезали, от того в роли GPGPU он стал слаб. Заточенность под игровой сегмент. Если надо профессиональное применение — надо брать Tesla или карты от AMD.
                  0
                  Насчет Tesla я бы поспорил: Tesla стоит в разы дороже, а производительность в GPGPU вычислениях на уровне обычных GTX.
                    0
                    Вы забыли уточнить в какой точности.
                      0
                      Скорее не точность я не упомянул, а то, что я имел в виду целочисленные вычисления, а не вычисления с плавающей точкой. В целочисленных вычислениях (без использования float или double) Tesla не дает преимущества перед GTX (мягко говоря).
                      Если есть результаты тестов, сравнивающих вычисления с плавающей точкой на Tesla и GTX, то было бы интересно глянуть, оправдывает ли Tesla 5-ти кратную цену.
                        0
                        Ну во-первых: с целочисленными вы правы, так и будет. Правда тут другой момент, если вы укладываетесь в память GTX — то все ок, но правда не сможете заставить работать ваше приложение как сервис Windows, например. Про ECC я тоже умолчу.
                        Во-вторых: В двойной точности только C1060 и GTX260 были одинаковыми, следующие поколения разнятся — на тесле двойной точности больше.

                        Теперь, что касается цены — подумайте, почему профессиональная дрель стоит дороже обычной.
                          0
                          Я не очень понял, как связан размер памяти GPU и возможность запуска как сервиса Windows?
                          ECC — Eliptic Curves? Если да, то я не знаком с вычислениями ECC на GPU, поэтому не могу сказать, можно ли их реализовать на GTX. Одно могу сказать точно: если вычисления требуют больше 1 Gb памяти, то время обработки должно быть намного больше времени копирования, иначе выигрыш от использования GPU будет минимальным. А сколько же в этом случае будет работать ядро на GPU, если OS срубает видеодрайвер после 2-х секунд непрерывной работы GPU?

                          Профессиональная дрель стоит дороже обычной, потому что она объективно лучше. Для моих задач Tesla объективно хуже GTX из-за своей дороговизны.
                            0
                            >Я не очень понял, как связан размер памяти GPU и возможность запуска как сервиса Windows?
                            Где я об этом говорил

                            >ECC — Eliptic Curves?
                            Error-Correction Code

                            > А сколько же в этом случае будет работать ядро на GPU, если OS срубает видеодрайвер после 2-х секунд непрерывной работы GPU?
                            Добро пожаловать в мир consumer products. На Tesla такого поведения нет ;-)

                            >Профессиональная дрель стоит дороже обычной, потому что она объективно лучше.
                            Вы пользовались проф. дрелью?

                            >Для моих задач Tesla объективно хуже GTX из-за своей дороговизны.
                            Все верно, для домашнего использования на «поиграться» GTX будет в самый раз.
                              0
                              > Где я об этом говорил
                              > Правда тут другой момент, если вы укладываетесь в память GTX — то все ок, но правда не сможете заставить работать ваше приложение как сервис Windows, например.

                              Возможно, я не так понял.

                              > Error-Correction Code

                              Как часто ваши вычисления давали неправильный результат из-за ошибок железа во время передачи данных или самих вычислений? У меня ни разу, GPU работают по несколько дней на полную катушку.

                              > Вы пользовались проф. дрелью?
                              Нет. Только советской.

                              > На Tesla такого поведения нет
                              Не возьмусь спорить, но предел тоже вроде есть. То ли 5 секунд, то ли 8. Но оптимальные параметры запуска ядра (количество блоков и потоков) не очень часто приводят к выполнению больше 2-х секунд. А если и приводят, то прирост производительности в пределах 5%. Из моего опыта.
                                0
                                >Возможно, я не так понял.
                                ЭЭэ… ваша правда, неправильное выделение фраз.

                                >Как часто ваши вычисления давали неправильный результат из-за ошибок железа во время передачи данных или самих вычислений? У меня ни разу, GPU работают по несколько дней на полную катушку.
                                Вы этого можете не заметить, ибо коррекция несложных ошибок делается автоматом. Могу сказать по своему опыту — такие ситуации не редкость, именно поэтому всегда сервера покупаются с ECC, в т.ч. на GPU.

                                >Нет. Только советской.
                                Ок, забудем про этот вопрос

                                >Не возьмусь спорить, но предел тоже вроде есть. То ли 5 секунд, то ли 8
                                Я вам утверждаю что нет. Работать на Tesla будет столько времени — сколько надо. Т.к. Tesla != видеоадаптер и Windows не применяет для неё правила, как для карт.
                                  0
                                  Тогда что вы имели в виду, когда говорили про сервис для Windows. Есть какие-то особенности, которые нужно учесть?

                                  > Вы этого можете не заметить, ибо коррекция несложных ошибок делается автоматом.
                                  То есть и на простых карточках есть корреция ошибок? :) В любом случае, у меня есть проверка на правильность подсчета каждого запуска.

                                  > Я вам утверждаю что нет. Работать на Tesla будет столько времени — сколько надо.
                                  Специально для вас провел сейчас тест: Tesla C1060, 30 блоков работало 1.6 секунды. Увеличил количество блоков до 90. В теории, должно было работать 4.8 секунды. Но увы, Windows срубила драйвер, так как посчитала его зависшим.

                                  Да, то что Tesla не является видеоадаптером, я в курсе.
                                    0
                                    >Тогда что вы имели в виду, когда говорили про сервис для Windows.
                                    Я сказал про два момента — это маленький объём памяти(помоему на GF сейчас 4 гига DDR3 потолок) и то, что с GF нельзя работать, когда приложение работает как сервис, т.е. в Session 0 (это ограничения ОС)

                                    >То есть и на простых карточках есть корреция ошибок?
                                    Нет. Я не говорю, что у вас были ошибки, я говорю о том, что когда система работает на обсчёт, то возникающие ошибки не такая уж и редкость.

                                    >В любом случае, у меня есть проверка на правильность подсчета каждого запуска.
                                    Аппаратная часть должна либо сразу по нахождению ошибки выдавать отбой дальнейшему счету, либо исправлять на лету. Иначе время, потраченное на расчет, будет потрачено впустую. Когда данных не так много, проверить их просто, но в другой ситуации проверка даст лишь увеличение времени счета, тогда нет смысла говорить о каком-либо ускорении.

                                    >Да, то что Tesla не является видеоадаптером, я в курсе.
                                    Я не говорю, что вы не в курсе, я говорю про работу оборудования. Вы сейчас пытаетесь уложиться в 10сек, которые отведены ОС для исполнения на видеоадаптере — иначе обвал работы, в Tesla этого ограничения нет и задача может считаться столько, сколько ей надо.
                                      0
                                      > с GF нельзя работать, когда приложение работает как сервис, т.е. в Session 0 (это ограничения ОС)
                                      Спасибо за информацию, буду знать.

                                      Если на простых карточках нет коррекции ошибок, то они возникают не так часто в целочисленных вычислениях. Я не встречался с такими ошибками. Да, накладные расходы в этом случае будут больше, чем коррекция ошибки на лету, но в рамках всей работы приложения это капля в море.

                                      > Вы сейчас пытаетесь уложиться в 10сек, которые отведены ОС для исполнения на видеоадаптере — иначе обвал работы, в Tesla этого ограничения нет и задача может считаться столько, сколько ей надо.

                                      Как показал мой пример выше, это не так. По-крайней мере, для Tesla C1060.
                                        0
                                        >Если на простых карточках нет коррекции ошибок, то они возникают не так часто в целочисленных вычислениях. Я не встречался с такими ошибками.
                                        Мы говорим про разные масштабы. Я об этом вам и твержу, когда речь идёт о consumer использовании, то никто не говорит — Берите Tesla. Когда речь заходит о более тяжёлых вещах — то тут это и говорят.

                                        >Как показал мой пример выше, это не так. По-крайней мере, для Tesla C1060.
                                        Это не так. Как, по-вашему, работают Matlab, CST Microwave, ANSYS Mechanical, Abaqus? Там расчёты довольно долгие и считаются на GPU. Поищите, что такое TCC.
                                          0
                                          Matlab, CST Microwave, ANSYS Mechanical, Abaqus работают на GF? Если нет, вопрос снят. Если да, то также, как и все остальные проги: разбивают задачу на подзадачи так, чтобы каждая из подзадач считалась быстро.

                                          За наводку на Nvidia TCC driver огромное спасибо! Буду тестировать. :)
                                            0
                                            >Matlab, CST Microwave, ANSYS Mechanical, Abaqus работают на GF?
                                            Нет не работают, т.к. им нужно длительное время считать на GPU, а на GF такое сделать нельзя.

                                            >разбивают задачу на подзадачи так, чтобы каждая из подзадач считалась быстро.
                                            Это неправильно. Задача должна считаться максимально быстро, но не в определённых рамках. Основной смысл GPGPU как раз в том, чтобы выносить как можно больше тяжёлых алгоритмов на GPU, а быть может и весь возможный код.
                                              0
                                              Печально, что не работают. Я всегда думал, что любую задачу можно выполнить по частям, если между частями сохранять внутреннее состояние.
                                              В моей практике разбиение на части не давало падения производительности даже на процент. Но у меня узкоспециализированные вычисления…
                                      0
                                      >Да, то что Tesla не является видеоадаптером, я в курсе.

                                      А это, интересно, почему? На С2070 DVI-выход есть, и пока не поставили CentOS, чтобы начать считать производственные задачи, я под виндой пару дней успел поиграться в Crysis, все настройки на полную — никаких тормозов.

                                      image
                                        0
                                        А потому, что там нет аппаратной поддержки DirectX и OpenGL. То, что есть DVI — говорит лишь о том, что поддерживается VGA режим для видеовывода.
                                          0
                                          Тогда как он играл в Crysis на полных настройках, если нет поддержки DirectX? Скорее всего, все зависит от поставленного драйвера.
                                            0
                                            Не могу ответить, могла сработать программная эмуляция. Я уже давно не играю, поэтому сложно сказать.
                                              0
                                              Я тоже не играю, это я видюху так тестировал.

                                              Завтра попробую винду поднять из бэкапа и напишу, что там за драйвера стоят такие, что игра работала без аппаратной поддержки DirectX, но с поддержкой тесселяции.

                                              Для тесселяции специально скачал многогиговый пак Crysis 2, чтобы посмотреть на это чудо в виде шероховатых кирпичных стен и неплоского океана.
                                                0
                                                А такой вопрос — помимо карты была ли ещё какая?
                                                  0
                                                  Там 4 карты, все 4 теслы, других нет.
                                                  Другие просто бы не поместились, там эти уже стоят впритык.

                                                  Отчет написал в комменте ниже:
                                                  habrahabr.ru/post/144202/#comment_4858873
                                +1
                                2-секундный лимит отключается ключом в реестре если что. (ключевые слова для поиска — TDR windows)
                                  0
                                  Пробовали, не помогает. Такого ключа в реестре не было, его добавление с правильным параметром не помогает. Возможно, сейчас ситуация изменилась.
                      0
                      Я вообще смотрю на количество SP в последнюю очередь: ведь на самом деле всем правят мультипроцессоры (MP). Для GTX 680 их количество равно 16. Каждый MP может за один раз запустить на выполнение warp потоков. Так что как связаны SP с MP и размером warp — для меня до сих пор большая загадка.
                        0
                        Связь очень простая. Раньше (в до-Fermi время), действительно на 1 MP запускался 1 warp. Если быть ещё точнее, то сначала выполнялись первый полуварп, а потом второй. Сейчас на одном MP есть несколько планировщиков потоков и они запускают одновременно несколько варпов (до 4), возможно даже из нескольких блоков.
                          0
                          То есть, если SP = 1536, MP = 16, то на один MP приходится 96 SP или 3 warp'a.
                          Я запускал алгоритм с параметрами 16 блоков, 1024 потока. Как видите, перекрытие по количеству потоков очень большое, а значит ресурсы GPU должны быть загружены более-менее оптимально. Но эти параметры запуска давали производительность меньше, чем для GTX 580 (у нее были другие параметры запуска). Отличные от 16 * 1024 параметры запуска давали худшую производительность.
                            0
                            На 1 MP в SMX приходится 192 SP. То есть до 6 варпов. Планировщиков 4 и каждый может запускать по 2 инструкции одновременно. На 1 SMX может быть до 16 блоков (если они не используют много регистров и shared памяти) и до 64 варпов. При заполнении 1 block/SMX загрузка практически никогда не будет полной по одной простой причине: если идёт чтение из памяти, то варп засыпает и ждёт пока не придёт результат. Варпы одного блока бегут «близко» друг к другу и поэтому висят и ждут ответа одновременно. Поэтому нужно загружать SMX сразу несколькими блоками, чтобы эту latency покрыть и пока одни висят, другие дробят числа.
                            Я не знаю точно, какая задача запускалась и возможно она просто имела много операций с double и как в этих задачах поведёт себя 680 я сказать не могу. Всегда считаю только в int и float.
                            И ещё, 16К потоков для CUDA это как-то несерьёзно. Это же fine-grained параллелизм, в идеале каждый thread должен обрабатывать одну единицу информации.
                              0
                              Нет, там нет двойной точности, т.к. GTX580 не сильна в DP.
                              Тут правильнее сделать профиль и посмотреть, что творится — тогда откроются некоторые тайны.
                              BrainHacker — я правильно понимаю, что у вас одинарная точность или целочисленная дробилка?
                                0
                                Да, конечно. Запустить профайлер – это самое правильное. Остальное – гадание с пустым нагревом воздуха)
                                  0
                                  Целочисленная дробилка.
                                  Сделать профиль — средствами NSight? Просто я пишу на Driver API, не знаю, поддерживается ли профайлером *.ptx код.

                                  Но я уверен, что профайлер скажет, что bottle neck'ом являются операции ALU, а не работа с памятью.
                                    0
                                    Да через Nsight.
                                    Он должен уметь обрабатывать PTX.
                                  0
                                  1) Давайте разбираться. Если у GTX 680 запросить атрибут CU_DEVICE_ATTRIBUTE_MULTIPROCESSOR_COUNT, то возвращенное значение будет равно 16. По спецификации GTX 680 имеет 1536 SP. Следовательно, на один MP приходится 96 SP или 3 warp'a.

                                  Откуда информация про «На 1 MP в SMX приходится 192 SP»?

                                  2) Под SMX вы понимаете GPU в целом?

                                  3) Задача — многократное хеширование, поэтому время копирования информации несоизмеримо мало по сравнению со временем обсчета.
                                  И 16K потоков для моей задачи очень даже неплохо, поверьте. Один поток — один выходной хеш.

                                  4) Ваше предложение по изменению параметров запуска? 16*1024 считается 1,6 секунды. Производительность при 16 блоках наивысшая именно при 1024 потоках на блок.
                                    +1
                                    >CU_DEVICE_ATTRIBUTE_MULTIPROCESSOR_COUNT, то возвращенное значение будет равно 16
                                    Нет он вам вернёт 8, а не 16.

                                    >Откуда информация про «На 1 MP в SMX приходится 192 SP»?
                                    Отсюда. Fermi SM(32 core) — Kepler SMX(192 core)

                                    >Под SMX вы понимаете GPU в целом?
                                    Нет, читайте модернизированный SM (Streaming Multiprocessor) — SMX (New Generation Streaming Multiprocessor)

                                    >Задача — многократное хеширование, поэтому время копирования информации несоизмеримо мало по сравнению со временем обсчета.
                                    Нужен профиль. Выравнивание используете?

                                    Так же попробуйте собрать с -arch=sm_30, дайте компилятору возможность оптимизировать только под Kepler.
                                      0
                                      > Нет он вам вернёт 8, а не 16.
                                      Oops, my bad… Тогда все сходится.

                                      > Выравнивание используете?
                                      Эм, выравнивание в памяти? Нет, так как в памяти хранятся только входные данные и записываются выходные данные. Время копирования мало. Все вычисления делаются на регистрах. Один поток использует не более 32-х регистров. Shared memory не используется, так как медленней.

                                      > Так же попробуйте собрать с -arch=sm_30
                                      Это можно задать только для ptxas, насколько я знаю. То есть при создании бинарного ядра. Я же компилирую в *.ptx, что должно по идее делать GPU-независимый код. При его компиляции во время исполнения программы я уже компилирую *.ptx под конкретную архитектуру.

                                      Попробую получить профиль ядра.
                                        0
                                        >Это можно задать только для ptxas, насколько я знаю
                                        Нет PTX — это псевдоассемблер (если так можно назвать). У PTX в заголовке указывается какой SM использовать. Тут надо правильно перевести в PTX, в зависимости от ARCH будет использоваться оптимизация по занятости регистров.
                                        nvcc собственно и берёт -arch=sm_30.

                                        Кстати вопрос, учитывая, что вы используете Driver API вы переводите код в cubin или PTX, а затем через DriverAPI грузите его в GPU?
                                          0
                                          Ну и, надеюсь CUDA 4.2 используете?
                                            0
                                            В PTX перегонял при помощи 3.0. Так как цель — поддержка всех карт на одном ядре.
                                            Возможно, специальное ядро, созданное при помощи CUDA 4.2 исправит ситуацию, надо тестировать.
                                              0
                                              Я пока не говорю о совместимости, ибо мы гадаем на кофейной гуще. Предложил вариант быстрого исследования.
                                              Хотя, в вашем случае надо смотреть не на GTX680, а на Kepler-I.
                                              0
                                              Можно и 5.0 использовать)
                                                0
                                                Можно, а смысл?
                                                Ну хотя, если нужны всякие фишки, вроде раздельной компиляции — то да, можно и 5.0
                                              0
                                              C++ -> PTX при помощи CUDA Toolkit. PTX компилируется непосредственно перед загрузкой ядра на GPU при помощи dll из поставки драйвера.
                                                0
                                                cuModuleLoad или cuModuleLoadDataEx?
                                                  0
                                                  cuModuleLoadDataEx конечно. Иначе как же под конкретную GPU компилировать? :)
                                                    0
                                                    Ок, значит можете использовать JIT.
                            +2
                            Ждем тестов от фармеров биткоинов.
                              +1
                              Их еще кто-то фармит?
                                +2
                                Если и фармит, то на AMD
                                  0
                                  По-моему оно уже давно того не стоит.
                            • UFO just landed and posted this here
                                +2
                                Warp — 32 потока, которые исполняют одну и ту же или пару инструкций.
                                0
                                Следите, чтобы внутри варпа ветвления шли максимум по 2 путям)

                                Насколько я понял, речь про instruction-level parallelism. Т.е. одновременно исполняются две последовательные инструкции. Две инструкции из разных ветвлений скорее всего исполняться не смогут.
                                  0
                                  Я это взял из whitepaper'а GK110:
                                  two independent instructions per warp can be dispatched each cycle.

                                  Впрочем, это не исключает и instruction-level parallelism.
                                    0
                                    На картинке показаны последовательные инструкции и в последние годы говорят только о ILP. Считаю маловероятным, что они реализовали что-то более продвинутое.
                                      0
                                      Да, картинка меня тоже заставила задуматься, но фраза о независимых инструкциях натолкнула именно на такую мысль.
                                      Обидно, если это действительно лишь ILP, хотя это резонно предположить из-за того, что работу по распараллеливанию можно сделать ещё на этапе компиляции.
                                      0
                                      Тут на самом деле еще одна проблема. На Fermi на каждые 48 ядер приходилось 2 планировщика, которые каждые 2 такта выдавали по 2 последовательные инструкции. В результате 48 ядер (+16 st/ld ядер + и.т.д.) за 2 такта исполняли 2x2x32=128 инструкций.
                                      В Kepler же учетверяется число ядер и планировщиков, так что скорее всего схема та же.
                                        0
                                        Если конечно Dispatch Unit на картинке = планировщик для варпа. Если же это инструкция, то я не понимаю как у них работает 48 ядер.
                                        0
                                        В www.anandtech.com/show/5699/nvidia-geforce-gtx-680-review/2 все описывается более подробно. Cхема-таки изменилась по сравнению с fermi, но речь все равно идет о ILP.
                                      +1
                                      Dynamic Parallelism:
                                      Работать это будет так, как вы привыкли на CPU части, только запуск ядер можно осуществлять из GPU.
                                      Пример нижеimage
                                        0
                                        Только вот все это будет доступно лишь на GK110, который будет неизвестно когда и стоить очень и очень дорого:(, а еще я так понял, что в OpenCL такого не появится.
                                          0
                                          И?
                                          А где в стандарте OpenCL описан данный функционал?
                                            0
                                            А вот в том то и дело, что в стандарте не описан, а расширения для него NVidia как-то не особо горит желанием писать последнее время.
                                              0
                                              И что вам это даст? Запуск OpenCL только на GPU NVIDIA?
                                                0
                                                Это даст возможность попробовать новые фичи с существующим кодом и решить, а стоит ли добавлять поддержку этих фич для карт, которые их умеют.
                                                  0
                                                  >Это даст возможность попробовать новые фичи с существующим кодом
                                                  Возможно, если код не сильно перелопачивать потребуется.

                                                  >решить, а стоит ли добавлять поддержку этих фич для карт, которые их умеют.
                                                  Это, простите, как? Новые фичи — это не что-то такое, что одним битиком открывается, это ещё и аппаратная часть.

                                                  А зачем тогда OpenCL, если получается что каждый раз отходим от стандарта за счет экстенженов? Здравствуй OpenGL!
                                                    0
                                                    Перелопачивать в пределах OpenCL придется много меньше, чем попытка переселения части кода на CUDA ради эксперимента.

                                                    Ну так купить железку, немного изменить один из алгоритмов и попробовать — дело не хитрое, а вот перелопатить весь проект гораздо сложнее.

                                                    А если экстеншны не делать, то ни попробовать новое, ни оптимизировать под каждую архитектуру не получится никак. ИМХО лучше иметь OpenCL с экстеншнами и возможностью что-то сделать, чем быть привязанным только к одной платформе. В любом случае, NV c AMD не договорятся о том, чтобы архитектура стала одинаковой, а без этого один стандарт для всех будет либо медленным, либо с расширениями. Я за расширения.
                                                      0
                                                      >Перелопачивать в пределах OpenCL придется много меньше, чем попытка переселения части кода на CUDA ради эксперимента.

                                                      Не факт. Надо учитывать то, что специфика OpenCL сейчас такова, что kernel запускается только с CPU. Как реализовывать этот экстенжен, особенно когда требуется переделка стандарта непонятно, так же как и реализация этого экстенжена. Ну и пока будешь перелопачивать, то поймёшь, что алгоритм можно переделать — и придётся переписать большую часть.

                                                      >А если экстеншны не делать, то ни попробовать новое, ни оптимизировать под каждую архитектуру не получится никак.

                                                      Ещё раз — экстенжены, это не стандарт. Брать… пробывать… С тем же успехом можно написать на CUDA. Ну хорошо, даже пойдём так, вам дали экстенжен и что? Вы пойдёте в AMD со словами «сделайте мне это..» и AMD сразу все сделает?

                                                      Давайте будем реалистами, хотели бы — давно реализовали в OpenCL, ибо ничего нового тут нет и народ уже часто об этом спрашивал.
                                                        0
                                                        Понять, что алгоритм можно переделать всегда можно, как говорится, нет предела совершенству :)

                                                        Раз будем реалистами, значит просто примем факт того, что в OpenCL такого не будет (собственно с этого и начался этот диалог) и лучше не смотреть в сторону новых плюшек, дабы не завидовать.
                                                          0
                                                          У пользователей всегда есть выбор — OpenCL или CUDA. Об этом всегда говорилось. Хотите чтобы работало везде — используйте OpenCL, хотите, чтобы работало быстро и новых фишек — используйте CUDA. Хотя странно, почему в OpenCL до сих пор нет синхронизации потоков.
                                                            0
                                                            Не так уж OpenCL отстает в плане скорости насколько я понимаю (сам тестов не делал, пруф не приложу).

                                                            А в каком смысле в OpenCL нет синхронизации потоков? Есть же barrier или вы о чем-то другом?
                                                              0
                                                              Аналог _syncthreads.
                                                                0
                                                                barrier не предлагать, т.к. она действует только для локальных блоков.
                                                                  0
                                                                  Вы имеете в виду синхронизация всех потоков вообще? Я почему-то всегда думал, что это невозможно, но я пишу на OpenCL. Обычно я в таком случае просто запускаю новое ядро.
                                                                    0
                                                                    __syncthreads действует только для потоков в одном блоке и нужна для синхронизации потоков при доступе к shared mem.
                                                                    С СС 2.0 появилась ещё __threadfence_system, которая действует на все потоки в grid'е. А до этого да, только новое ядро и можно было запускать.
                                                                      +2
                                                                      __threadfence_system это мемори барьер. Аналога __syncthreads для всех потоков в гриде нету и быть и не может. Ресурсы видеокарты конечны, поэтому если весь грид не поместится на устройство (что обычно и бывает), то такой аналог будет ждать вечно — новые блоки не смогут стартовать, пока не закончатся выполняться текущие, а текущие ждут.
                                                                        0
                                                                        Да, согласен. А если реализовывать семафор — проще уж ядра запускать.
                                              0
                                              GK110 обещают ближе к концу года. А что до стоимости, то такие решения никогда не стоили дёшево. Основной упор на то, что ты получаешь мощную железяку, которая работает быстро, надёжно, кушает мало, её можно подоткнуть к какому-нибудь лезвию и использовать 24/7. Из всего этого у GTX есть только скорость. Ну и подключить её тоже можно. Поэтому она и стоит дешевле. Не энтерпрайз и не продакшн уровень.
                                              Что до OpenCL – тут могу только мышек с кактусами вспомнить. Стандарт он на то и стандарт чтобы развиваться медленно. С таким отставанием от текущего развития CUDA я запросто согласен на vendor-lock. Тем более у AMD всё равно нет аналогов Tesla. Возможность программировать на CPU также неудобно как на GPU считаю верхом непрактичности. Слышал ещё про x86-CUDA, которая позволяет использовать CPU как графический расчётный модуль. Но зачем? Другая архитектура, другие принципы оптимизации, всё совсем другое. Люди не используют CUDA, если на то нет большой нужды. Если нет подходящей под эту архитектуру задачи.
                                                0
                                                >Из всего этого у GTX есть только скорость
                                                Я бы не стал так говорить, ибо это будет чип GK110. Но опять же, если речь идёт про одинарную точность, самый правильный вариант — Kepler I. Да, без Nested Parallelism, Hyper-Q… зато два чипа на одной плате, где работает P2P обмен.

                                                >С таким отставанием от текущего развития CUDA я запросто согласен на vendor-lock.
                                                Собственно NVPTX сейчас уже официально в LLVM. Никто не мешает поработать с ним и сделать реализацию для другого оборудования.

                                                >Слышал ещё про x86-CUDA, которая позволяет использовать CPU как графический расчётный модуль
                                                Нет, это не так. x86-CUDA — это некий FAT-bin где есть код для GPU и CPU. При запуске можно определять, что использовать (У PGI это реализовано).

                                                  0
                                                  Стоимость не особо важна когда речь идет о продакшне и 24/7, тут как-бы без вопросов. Только раньше взять да и попробовать технологию(я про DP и H-Q) на обычном десктопе раньше можно было, а теперь нет (без полугодового ожидания и многих тысяч долларов за теслу), вот это мне и не нравится.

                                                  Я понимаю, что стандарт развивается медленно, поэтому и хочется иметь возможность попробовать новое с расширениями, а потом может новые фичи и в стандарт добавят. На тему запуска OpenCL кода на CPU, вопрос не такой уж простой, оптимизировать конечно надо совсем по-разному, но если можно будет просто держать немного разные версии кернелов и конфигов для запуска, а не несколько инфраструктур в одном приложении, то может быть не все плохо. Я как-то стянул себе Intel OpenCL SDK и был приятно удивлен тем, что мой GPU код вполне неплохо завелся на CPU без каких-либо плясок с бубном. Получилось конечно медленнее, чем на видеокарте (а иначе зачем морочить голову с GPGPU), но не так уж плохо как я ожидал.

                                                  Вообще, как-то все GPGPU уходит в сторону серверов и науки, а хотелось бы видеть его использование активное на обычных пользовательских компьютерах.
                                                    0
                                                    >а теперь нет (без полугодового ожидания и многих тысяч долларов за теслу), вот это мне и не нравится.

                                                    Это неправильно. Мне вот тоже хочется, чтобы Core i7 работал с 2-4 сокетами, ан нет — аппаратный блок. Ещё раз, давайте будем реалистами — помимо ваших запусков есть ещё и другие расходы, например нужна же поддержка, нужны люди, которые будут фиксить баги — они тоже недёшевы. Более того GF не выпускается NVIDIA, а выпускается Palit, ASUS, MSI которые в погоне за покупателями играют с частотами, а потом читаешь на форумах, что на карте вендора А все крашится, а на карте вендора Б нет.
                                                      0
                                                      Все это хорошо при одном условии: GPGPU = наука и серверное применение. Тогда да, все ок. А если GPGPU = что-то применяющееся везде на каждом десктопе и ноутбуке, то там то как раз и появляются все эти непонятные Palit, Asus, MSI, etc.

                                                      Я просто работаю над более менее пользовательской технологией, поэтому мне и хочется видеть новые возможности на пользовательском железе.
                                                        0
                                                        GPGPU не только наука. Например MAXIMUS не требует серверов, а достаточно раб. станции. Но вы правы в том, что это проф. рынок.
                                                      0
                                                      Только раньше взять да и попробовать технологию(я про DP и H-Q) на обычном десктопе раньше можно было, а теперь нет

                                                      Увы, так было только до Fermi. В СС 2 появилось прямое копирование DeviceToDevice внутри машины без задействования CPU. Такой вот DMA по утверждению nVidia требует ECC, который только на Tesla присутствует. Вот и получилось — на Tesla фича есть, а на GTX — нет.
                                                        0
                                                        А так и должно быть. Те, кому требуется данный функционал, должны использовать проф. решения. Это же гарантия работы и, как минимум, уменьшение расходов, связанных с поддержкой, т.к. не потребуется распыляться на всех производителей GF.
                                                          0
                                                          И я с такой политикой полностью согласен.
                                                  0
                                                  Круто. В тайне надеялся на такое и очень рад, что именно так и будет.
                                                  +2
                                                  Hyper‐Q, Grid Management Unit
                                                  На Fermi была одна аппаратная очередь, поэтому параллельность возникала только в момент перекрытия задач (проще говоря в большинстве случаев на копировании), на Kepler 32 аппаратных очереди, которые могут работать независимо — это значит что можно породить до 32 стримов и они будут работать параллельно (понятное дело, что ресурсы каждым стримом не должы полностью съедаться, т.е. не все CUDA ядра на каждый стрим).
                                                  Как было на Fermi:


                                                  Как стало на Kepler:
                                                    +1
                                                    Кстати, думаю стоит заменить GK104 на Kepler-I, а GK-110 на Kepler-II т.к. будет два продукта:
                                                    Keper -I (Gemini):
                                                    2GPU на одной плате с большой одинарной точностью и маленькой двойной. Продукт специфичный, но там не будет поддерживаться Hyper-Q, Dynamic Parallelism (что собственно и указано в табличке)

                                                    Kepler-II:
                                                    Продукт с большой двойной точностью, где все эти механизмы будут работать.

                                                    Ну и то, что все это дело PCIe gen.3
                                                      0
                                                      Все это хорошо, только вот самые интересные фичи они добавили в GK110 и это весьма печально. А еще за все время GTC никто ни разу не упомянул OpenCL.
                                                        0
                                                        Кто-нибудь может объяснить «на пальцах» почему NVIDIA Quadro 2000 сильно выигрывает перед NVIDIA GeForce GTX 580 на инженерных вычислениях? (кроме ensight-04, на котором проигрывает)

                                                        Это я взял из статьи на стр.58 в журнале «Железо» за июнь 2012. В статье проведено сравнение, но почему такое многократное преимущество, не очень понятно объяснено.

                                                        По цене кстати, эти карты одинаковые — 15 тыс руб. Поэтому именно их и сравнивали.
                                                          0
                                                          А чего тут удивительного.
                                                          Оптимизация.
                                                            0
                                                            Как? Как блин 192 cuda cores Quadro 2000 уделали 512 cuda cores GTX 580? Засчет какой такой волшебной оптимизации можно добиться таких результатов?
                                                              0
                                                              Вот так, поэтому проф. продукты и стоят немалые деньги, которые направляются на оптимизацию со стороны аппаратной части и программной (совместно с ISV дорабатываются методы).
                                                                0
                                                                В статье в журнале прямо сказано, что по аппаратной части NVIDIA Quadro 2000 примерно равна GTS 450 и красная цена ей 3500 руб, а ее продают за 15 тыс, потому что драйвера там оптимизированные.

                                                                Интересно, в чем же состоит оптимизация? В компиляции с ключом -O2?
                                                                  0
                                                                  Вы пользователь Gentoo?
                                                                  Никто вам никогда не расскажет в чем состоит оптимизация, в общем и целов — оптимизация вызовов и исполнения кода на GPU.

                                                                  >а ее продают за 15 тыс, потому что драйвера там оптимизированные.
                                                                  1 студент-программист стоит порядка 15 тыс, один профи стоит от 80 и выше. Вопрос, почему такая разница? Не надо хотеть все задёшево.
                                                                  0
                                                                  Я понимаю, что профессиональные продукты делают профессионалы. Мне просто интересно: такой разрыв в производительности из-за:
                                                                  1) супер оптимизированных драйверов для Quadro 2000?
                                                                  2) супер оптимизированного алгоритма самой программы для Quadro 2000?
                                                                  3) ничего не супер, просто один и тот же их код работает на Quadro 2000 быстрее, чем на GTX 580? То есть под GTX 580 попросту не оптимизировали. Или вообще никак не оптимизировали, как карта легла.
                                                                    +1
                                                                    Всегда говорилось о том, что OpenGL на квадрах сильно оптимизирован.
                                                                    Т.к. большинство CAD систем на OpenGL — отсюда и такой вывод.

                                                                    >супер оптимизированных драйверов для Quadro 2000?
                                                                    Одна из частей. Вторая — взаимодействие с ISV на предмет оптимизации работы и правильного построения OGL/DX команд.

                                                                    Собственно большие деньги — это результат этого труда.
                                                                    Когда вы покупаете GF для игр, то вы платите тестировщикам, которые гоняют игры и выявляют баги.
                                                                    Когда вы покупаете Quadro, то вы покупаете:
                                                                    — сертифицированное — проходило тестирование все проф. по, которое в списке поддерживаемых
                                                                    — надёжное — наработки на отказ у Quadro больше, весь процесс под контролем компании, обеспечение достаточного запаса прочности
                                                                    — доступное — в течении 3 лет у вас есть гарантия, что вы сможете найти такую же карту и без проблем заменить неработающую. У GF срок жизни обычно максимум год.
                                                                    — администрируемое — можно добавлять раб. станции с Quadro в систему мониторинга и смотреть загрузку. Есть и API и WMI поддержка, возможность удаленного изменения опций
                                                                    — правильное — нет на проф рынке такого понятия, как в играх — чем мощнее тем лучше. Зачастую проф. приложения не так скалируются, как игры, там другие методы работы.

                                                                    И кучу всего всего.
                                                                      0
                                                                      Ну и исполнение DirectX команд тоже оптимизировано, но не всегда это заметно. Поэтому если бы этот тест был для игрушек, то Quadro проиграла бы.
                                                              0
                                                              Если это рендерер, то дело в том, что на обычных картах стоит искуственное ограничение по количеству полигонов на сцене (порядка 1 миллиона). Как только число полигонов превышает его — карта начинает простаивать без всякой причины. Это ограничение достаточно большое, чтобы не достигаться в играх, но достигаться в проф. приложениях.
                                                                0
                                                                Кстати, здесь тоже тестировали видеокарты. Как итог: разрыв в производительности — маркетинговый ход Nvidia и программные ограничения (но не аппаратные).
                                                                +1
                                                                Небольшой отчет по Тесла C2070

                                                                Компьютер на Intel Core i7 990X, стоит 4 карты C2070.
                                                                Общая стоимость — точно не помню, около 400 тыс руб.
                                                                Из них каждая карта Тесла стоит около 80 тыс руб.

                                                                1) DirectX v11 там есть:



                                                                2) Версия драйвера:



                                                                3) Производительность немного не дотягивает до 1 млрд операций:



                                                                4) Производительность в Windows не дотягивает 0.1 балла до максимума.
                                                                Диски там не SSD и даже не 10000 rpm, поэтому на диски не смотрим:



                                                                5) Насчет ECC я не понял, стоит 4 карты, во всех ECC есть, а в первой карте его нет. Брак???

                                                                первая карта


                                                                другие карты


                                                                UPD1. Возникло предположение, что в первую карту воткнут монитор, поэтому она используется как видеоадаптер, а не как CUDA, поэтому там ECC отключилась.

                                                                Проверить гипотезу не могу, потому что винду уже снес в пользу CentOS. Винду ставил из бэкапа на 15 мин специально для получения этих скриншотов.
                                                                  0
                                                                  Да, согласен. Проверил. Есть поддержка, похожая на GF.

                                                                  >Возникло предположение, что в первую карту воткнут монитор, поэтому она используется как видеоадаптер, а не как CUDA, поэтому там ECC отключилась.

                                                                  Скорее всего ECC было выключено ранее. Не важно как детектится карта, ECC не отключается.

                                                                Only users with full accounts can post comments. Log in, please.