По наводке с Stream computing уже здесь почитала про новые графические технологии.
Я уже давала ссылку на статью про Intel CGPU. Идея состоит в том, что Intel хочет считать графику на своем CPU. NVidia и ATI на это приготовили свои ответы, они предлагают производить расчеты, не связанные с графикой, на GPU. Новые технологии называются NVidia CUDA и ATI CTM.
Про NVidia CUDA информации больше всего. Причем информация в восторженных тонах. Официальная бумага вот: NVidia CUDA Programming Guide.
CUDA - технология, применяемая начиная с GeForce 8800. Теперь NVidia предлагает переносить некоторые арифметические расчеты на GPU. Переносить их нужно в том случае, если эти расчеты хорошо можно распараллелить. Для программирования этого нового GPU используется С-подобный язык. От С он отличается несильно, туда вводятся новые ключевые слова вроде __device__ , __global__ и __host__, с помощью которых можно указать о переносе расчетов на GPU. Есть некоторые ограничения на использование рекурсии и статических переменных. Ну и еще кое-что по-мелочи.
Меня очень озадачила одна мысль NVidia. Они как-то так мягко и ненавязчиво рассказывают о том, какие современные графические API неудобные, с драйверами вечные проблемы, да и для неграфических приложений они не подходят... Вот у нас тут есть С-подобный язык, который все умеет, есть компилятор к нему, вот его и используйте. То есть DirectX становится вроде как и не нужным уже. Интересно, что думает по этому поводу Микрософт.
Cтатьи и мнения про CUDA:
NVIDIA CUDA Quick Summary
NVIDIA CUDA Introduction
A quick programmer’s look at NVIDIA’s CUDA
Nvidia releases Cuda - and reinvents Stream Processing?
G80 Architecture from CUDA - обсуждение на Beyond3D
Про ATI CTM информации гораздо меньше и восторгов меньше. Официальная бумага: ATI CTM Guide
Идея та же - все распараллелить. Только вот никакого С-подобного языка тут нет. Все делаем на языке ассемблера.
Основная идея, которая прослеживается и у NVidia, и у ATI - внедрить в массы Stream Processing. Я нашла пост, в котором эта идея критикуется: Stream processing for the Masses? I don’t think so! Вообще все, что касается параллелизма увеличивает сложность разработки, это требует высокой квалификации программистов, поэтому массовость этих технологий под сомнением.
NVidia, правда, придумала язык, чтобы процесс упростить. Понятно, что он не зря С-подобный, NVidia надеятся переманить кого-то из огромной армии С-программеров.
Но надо сказать, что уже есть зоопарк языков по программированию GPU. К примеру Cg, HLSL, Sh, BrookGPU... Теперь вот еще один.
В посте Stream computing уже здесь lrrr предполагает, что будут разработаны новые функциональные языки программирования для таких GPU. Я думаю, что и старые подошли бы, тот же Erlang, возможно после какой-то доработки. Вопрос в том, удастся ли победить сложность с их помощью.
Ссылки по теме:
Imagine - разработка Стэнфордского университета. Тема все та же - stream processing на GPU.
Quaternions and spherical trigonometry
5 дней назад
Atom feed
15 коммент.:
угу
или Erlang или Haskell
причём второе даже вероятнее, учитывая странное положение с реализациями эрланга…
угу
или Erlang или Haskell
причём второе даже вероятнее, учитывая странное положение с реализациями эрланга…
Я вспомнила про Erlang, поскольку он заточен про многопоточные приложения. Насчет Haskell'я не уверена, но вроде он для многопоточности не предназначался?
А что там не так с реализациями? Я не так много знаю про Erlang, но там есть Open Source реализация, с ней проблемы какие-то?
Мне кажется, что если разрекламировать "массам" параллельное программирование сейчас, то мы получим кошмар 70-х годов, когда переполнения буфера, утечки памяти и segmentation fault были "верными" спутниками большинства Сишных программ...
Идея NVidia ни в коем случае не Stream processing.
В чем идея CTM/потоковой машины: у нас есть входной поток данных, мы над ними делаем операции, пишем выходной поток.
А в CUDA нам дают:
* локальный кэш и довольно большой
* scatter т.е. возможность записать
не в поток, а куда угодно (в глобальную память).
И это уже совсем другая жизнь, чем с HLSL/Cg/GLSL/Brook/RapidMind.
Erlang тут не в тему никак :)
"Параллельность" Erlang это то что называется concurrency -- т.е. параллельность выполнения программы она, гхм, семантическая что ли, by design, ключевые слова клиент-сервер, сообщения, многопоточность, синхронизация итп.
А CUDA (или вот Data Parallel Haskell) -- это parallelism, то бишь распараллеливание вычислений, которые можно и последовательно производить вполне.
Вот что идеально было б на GPU реализовывать имхо, это некоторое подмножество какого-нибудь APL-based векторного языка.
> Насчет Haskell'я не уверена, но вроде он для многопоточности не предназначался?
Скоро (уже в этом году) для Хаскелла сделают версию GHC с поддержкой Nested Data Parallelism - возможно, часть вычислений можно будет перенести в GPU (об этом упоминается в презентации Пейтон Джонса)
А пока вся параллельность в Хаскелле ручная... :о(
Из того немножко, что я понял по
CUDA, уместна следующая аналогия: лет десять или более назад шло сражение в умах - что победит RISC или CISC. Последний победил, хоть у него внутри что-то от RISC. Ну так вот: была жила фирма Nextgen, и у нее был свой x86 процессор. Был он тучен, и ему нужна была своя мамка. Внутри он был RISC, а снаружи CISC, а стоил дешево. Народ попросил: а можно нам компилировать прямо во внутренние инструкции, но народу объяснили что-то невнятное. Потом эта команда ушла в AMD делать K6 (насколько помню).
Итак, в процессе создания ускорителя его тестировали - потрошили и так, и эдак, причем иногда без 3d штук. Походу поучилось много всяких примочек, из которых получился драйвер CUDA и некоторые куски компиллятора.
Наконец, ускоритель заработал как надо в 3D, и разработчики и их университетские дружбаны взмоились: хотим такой вот чисто вычислительный аксель!
Nvidia не стала ломаться, и инициативу масс поддержала.
Если под этой системой даже и работают готовые библиотеки для матричных вычисений, скорее всего, это университетская игрушка для написания PhD. Затем остепененный народ идет обсуживать многочисленные суперкомпьютеры в США (применяемые, в основном, военными), и про баловство с CUDA забывает.
Слишком уж долго развиваются коммерческие суперкомпьютеры, и там имеются побежденные узкие места. А в CUDA слишком много непобежденных узких мест.
Так что победа CUDA как вычислительной системы для масс, IMHO, за горами.
Я заинтересован в испоьзовании ускорителя по своему основному назначнию, но есть задачи вроде быстрых сверток - блурров, для которых возможность обработки тредами, разделяющими память внутри блока зело удобна.
Причем с окально вычисленным ядром свертки.
К сожалению, сейчас CUDA работает, насколько я понял, со скалярами, а не векторами пикселов. Так что буду следить за тем, что да как, и стоит ли овчинка выделки.
Я занимался GPGPU используя Cg и уже на этом уровне нам удавалось достичь интересных результатов. CUDA в сочетании новых платформ таких как Tesla значительно увеличит быстродействие хорошо распараллеливаемых приложений, не только в вычислениях вообще(что само по себе интересно) но и в графических вычислениях таких как вычисления связанные с реализацией реалистичных моделей освещения, или физики. Вопрос в том, что все это идет по большому счету на уровне исследований и внедрение этих технологий в коммерческий софт наверное ожидать не придется даже в геймдеве в ближайшие лет 5 эта технология не получит широкого распространения.
обучится CUDA самостоятельно можно за месяц максимум, другой вопрос что если мозг закостенелый и не способен учится новому то это будет сложно, но я не думаю что такие проблемы возникают у выпускников ведущих вузов страны. Низкоквалифицированному веб программисту конечно будет тяжело, но Среднему С++ разработчику - вполне по зубам, если у него есть определнный багаж фундаментальных знаний или елементарные навыки программирования на MPI или OpenMP. В конце концов это не диссертацию написать - изучить CUDA.
И вообще грядет эра многопоточных приложений, я надеюсь вы заметили? Тот же интел к которому я имею некоторое отношение, постоянно рекламирует многопоточные пиложения проводит конкурсы и олимпиады(правда с присущим этой компании расгельдяйством)
Cuda (nVidia) и Intel rules это вы хотите сказать? Ладно, да! я тоже согласен с этим, nvidia разрабатывала свою новую библиотеку совместно с ATI, а у ATI'шников возможности по расчётам на железе намного больше чем у nVidia по крайней мере были (а щас уже надо смотреть, хотя и так ясно что nVidia впереди), распараллеливание задач это, то, чем занимаются и в Intel и в nVidia, и примеры и достижения уже есть...
У интела, что и понятно на нагрузку CPU Intel TBB (threading building bloks), а у nVidia на железном уровне CUDA.
Будущее за такими технологиями, которые позволяют всё ускорять
Я далеко не спец в параллелизме и прочих высоких материях, просто в прошедьшие 32 часа - время, которое мне известны четыре буквы CUDA - оно сожрало мой моск. В принципе получил неплохие результаты для рассчётов внутри нашей БД, но что-та мерещица мне что технология в продукци нами собираемой в ближайшие пол года неприжывёца...
скорее всего я чего-то непонял в технологии, а то мне страшна нехватает быстрой, не поточной, а человеческой, инициализации шаред мэмори.....
2x4m:
скорее всего я чего-то непонял в технологии, а то мне страшна нехватает быстрой, не поточной, а человеческой, инициализации шаред мэмори.....
Интерфейс работы с CUDA нельзя назвать интуитивно понятным, увы. Но я надеюсь, что NVidia будет это направление дорабатывать и ситуация будет постепенно меняться к лучшему.
Меня очень озадачила одна мысль NVidia. Они как-то так мягко и ненавязчиво рассказывают о том, какие современные графические API неудобные, с драйверами вечные проблемы, да и для неграфических приложений они не подходят... Вот у нас тут есть С-подобный язык, который все умеет, есть компилятор к нему, вот его и используйте.
Хотелось бы почитать источник в оригинале, честно говоря.
То есть DirectX становится вроде как и не нужным уже. Интересно, что думает по этому поводу Микрософт.
Как же DirectX становится не нужным уже, если визуализация в CUDA через OpenGl/DirectX.. Или я чего-то не знаю, или никакой альтернативы GAPI CUDA из себя не представляет.
2gd.ua:
Хотелось бы почитать источник в оригинале, честно говоря.
Все источники я по ходу поста указала. Но за давностью лет уже не помню, в каком именно об этом говорилось...
Как же DirectX становится не нужным уже, если визуализация в CUDA через OpenGl/DirectX.. Или я чего-то не знаю, или никакой альтернативы GAPI CUDA из себя не представляет.
Даже до CUDA народ писал свой собственный graphics pipeline полностью на шейдерах. Одна из модных идей (я видела несколько реализаций) - отрисовка методом трассировки лучей на CUDA.
Даже до CUDA народ писал свой собственный graphics pipeline полностью на шейдерах. Одна из модных идей (я видела несколько реализаций) - отрисовка методом трассировки лучей на CUDA.
Это хорошо, но рисующих примитивов в CUDA не наблюдается - рендеринг через opengl или dx.
2gd.ua:
Это хорошо, но рисующих примитивов в CUDA не наблюдается - рендеринг через opengl или dx.
А что понимается под "рисующими примитивами". Высокоуровневые средства работы с графикой? Возможность вывода на экран?
CUDA не предоставляет каких-либо высокоуровневых средств работы с графикой, это да.
Но в той же трассировке лучей весь смысл в том, чтобы написать свою собственную работу с графикой (при этом сбросив часть вычислений на GPU).
Возможность вывода на экран - можно работать с видеопамятью и без DirectX'а.
Насколько это всё нужно/удобно - это уже другая история. Но каких-либо концептуальных проблем что-либо отрендерить с помощью CUDA, не используя графические API, я не вижу.
Отправить комментарий