В новостях прочитал про технологию вычислений CUDA с использованием ресурсов видеокарт nVidia. В них начиная с ряда 8800 поддерживается эта технология, ими выпущен спец. драйвер, SDK и даже компилятор языка C. Скачать можно здесь: http://www.nvidia.com/object/cuda_get.html Интересно, как будет выглядеть в ассемблерном листинге применение этой технологии, и сложно ли будет провести эти вычисления в привычном мне masm? Будет ли это API, COM, будет это на уровне прерываний, новые мнемоники для графического процессора? Простите, если тут я несу чушь, т.к. с программированием железа никогда не имел дела. Меня интересует, сложно ли будет писать прикладные программы, требующие большой нагрузки на вычисления? Означает ли выход этой технологии то, что можно будет перекомпилировать хорошо написанные опенсорсные (или свои собственные) программы ИХ компилятором и добиться прироста производительности существующих программ, имея GF8800 и выше?
CUDA подразумевает вычисления графическим процессором, а не центральным. По сути всю работу выполняет некий аналог геометрических шейдеров из ДХ10, только полученный результат служит не для формирования картинки, а для чего-то другого. Никакого отношения к МАСМу и другим средствам разработки программ для центрального процессора компутера CUDA не имеет. Для получения чего-то полезного фактически нужно писать две программы: одну обычную, которая взаимодействует с пользователем, читает-пишет файлы и всё такое, и вторую для собственно расчётов, которая будет выполняться как раз на графическом процессоре.
SII Ну, т.е. откомпилировать то, что будет взаимодействовать с графическим процессором ты хочешь сказать можно будет только специальным компилятором языка C от nVidia? А как же сопроцессор? Ясный перец, он сегодня в одном флаконе с центральным процессором. Но когда-то был отдельным и физически, не только логически. Я просто подумал, что раз у FPU есть свои регистры и инструкции, то может быть подобным образом может взаимодействовать с видеокартой программа. По ходу я ошибался.
может не очень в тему, но: в природе есть композитные менеджеры (compiz к примеру), которые отрисовывают окна, используя аппаратную реализацию OpenGL в видяхах последних поколений. это значит, что весь контент в окнах может изменяться динамически во время любых манипулаций с ними, а вся работа по отрисовке ложится на видео-карту, разгружая тем самым CPU.
varnie, сенкс за информацию. А как понимать сам термин "композитный менеджер"? Это что-то типа драйвера к соответствующей видюхе или это такая библиотека, которая активно используется для гуёвых окошек? =) Погуглю про compiz.
mc black Да компилировать специальным компилятором. Видео карты будет вычислять только специалезированные блоки. Сопроцессор он всетаки был ближе к процессору. Т.е он логически был им. Просто физически вынесли за приделы процессора. А с видекартой сложнее. Надо не тольько подать команду. Ее нужно записать отдельно. Загнать данные в видео память и обратно после обработки перегнать обратно. Передача данных нужна для ускорения. Так что CUDA применяется для ускорения рассчетов больших блоков данных.
Ассемблер давно уже не используется для программирования видеокарт. Высокоуровневый код компилирует драйвер карты, для каждой модели своя оптимизация и свои особенности.
Booster Используется. Компилирыет не драйвер, а компилятор. И код хрониться в откомпилированном виде.
Насчёт языка не разбирался -- у меня CUDA пока приоритетным не является, я лишь бегло почитал про сию технологию на невидийном сайте, не вдаваясь глубоко в детали. Так что дальше только мои предположения По идее выходит так, что там полноценного Си или ещё какого "обычного" языка попросту не будет, ведь и функционал, и назначение графического процессора весьма сильно отличается от обычного универсального. В первую очередь это касается типов данных: имеют смысл только целые и вещественные числа определённой разрядности, а также векторы и матрицы из этих чисел. Вероятно, будут иметь место ограничения на объявления переменных, на использование управляющих конструкций... В общем, лично я предполагаю, что программы будут писаться на некоем специализированном языке, синтаксис которого довольно близок к Си, но это не Си (собственно, язык шейдеров и является таким "псевдо-Си"). Ошибка в другом Хотя сопроцессор долгое время был физически отдельной микросхемой (впервые он был объединён с ЦП в 80486DX), логически, т.е. с точки зрения программиста, он всегда был частью ЦП: его команды следовали в общем потоке команд ЦП и подчинялись общим с ними правилам. Графический же процессор не просто физически отделён от центрального -- он исполняет свой собственный поток команд, никак не связанный с потоком команд ЦП. Собсно, об этом Pavia выше уже сказал. Ну а вообще в этой идее ничего принципиально нового нет. Например, в своё время для ЕС-1045 был создан матричный процессор ЕС-2435, подключавшийся как устройство ввода-вывода. ЦП "спускал" ему работу, сообщая адрес начала его программы в основной памяти машины, ну а матричный процессор её выполнял (собсно, в IBMовских мэйнфреймах и содранных с них ЕСках все внешние устройства управлялись подобным образом -- выполняли заданные им программы). С CUDA будем иметь примерно то же самое, только на совсем другом технологическом уровне.
Booster Pavia Вообще-то шейдеры пишутся на специальном языке высокого уровня, который компилируется при загрузке этих шейдеров. В принципе можно делать это заранее, но нет смысла: тогда результат будет привязан к конкретному графическому процессору. Так что всё делается уже после запуска программы. Ну а встроен компилятор в драйвер видюхи, в ДиректХ или ещё куда, не суть важно: с точки зрения прикладного программиста можно считать, что за это драйвер отвечает. Вот шейдеры 1-й версии действительно писались на специальном ассемблере. Пы.Сы. Возможно, конечно, что я ошибаюсь, но именно такое мнение у меня сложилось из прочитанного по поводу шейдеров.
Pavia Cuda не знаю, у меня не карты которая его держит. Я имел ввиду, что принят подход с высокоуровневыми языками. HLSL и GLSL компилят дрова и это логично, а то что Cuda отдельный компилятор это странно. SII На чём они пишутся я в курсе, всё таки работаю в этой области. У нас применяется и Cuda, но я не в этой группе работаю.
Pavia, SII, спасибо за развернутый ответ! =) Booster, много раз видел исходники по работе с OpenGL и DirectX на ассемблере. На уровне этих библиотек (драйверов?) с видеокартами и работают. Добавлено: После прочтения написанного: чем больше узнаешь для себя нового, тем шире делаешь границы собственного незнания =)
SII Booster У меня видюшка очень древния. Так что шейдоры я изучаю не очень углубленно. Но насколько я понимаю идет компилирование в байткод. Компилируют сразу чтобь не тратить время на компиляцию во время игры. А вот дальше уже драйвер оптимизирует байт код. ATI сделала програмный блок к GPU, который занимается перекодированием. Из кодов шейдоров и кодов OpenGL, DirectX в коды видео карты. У CUDA там отдельный компилятор СИ. Вернее его подобие, так что SII все верно описал.
mc black Код (Text): много раз видел исходники по работе с OpenGL и DirectX на ассемблере. Я тоже видел, но это или что-то очень простое и древнее. А так уже давно пришли к тому что это зло. Например один и тот же код может работать на всех картах, но от перестановки местами двух строк, производительность может меняться в десятки раз. Потом одна высокоуровневая инструкция на разных моделях карт может развернуться в разные команды, на старых картах в 10 инструкций, а в новых в одну. Всё это уже давно поняли, и от асма отказались. Насчёт Cuda не знаю, не доводилось. Pavia В GLSL точно не байт код, так как компилируется именно исходник в рантайме. В HLSL вобщем-то тоже рантаймовые функции загружают исходник и компилят. Так что про байт код впервые слышу. В Cg тоже есть отдельный компилятор, но он встроен в рантайм который необходим на машине где запускается прога.
Я не против промежуточного кода, но компилить по любасу нужно в рантайме. 2FED Спасибо, подтвердил. Pavia Противоречий не ввижу.
