freepascal.ru

Serafim писал(а):Я бы с радостью написал подобный Фрэймуорк, если бы это было так просто и если бы моих знаний хватило на это. Но тут нужна работа не одного человека, а многих, возможно, даже нескольких десятков, и нужно тесное сотрудничество с AMD/ATI, nVidia и Intel, или по крайней мере очень хорошее знание архитектур их продуктов. При этом нужно ещё очень много свободного времени, чего у меня в день бывает не более 5 часов.

1. Модульная архитектура (многоуровневая) - это основной цикл, это дополнительный работающий с ATI, это дополнит работающий с nVidia и т.д.
2. Ели цель есть 1 хватит, главное цель чтоб была правильная и времени от полугода по 8 часов.
3. Архитектура - смотришь на официальном сайте на английском языке, есть ещё 3 книги GPU Gems.

С архитектурой то понятно, но чтобы это всё написать нужно знать как напрямую вызывать инструкции GPU. Если эмулировать команды Паскаля через GLSL, то будет уменьшаться производительность. В принципе, если знать как вызываются инструкции GPU, то можно напрямую на них и писать, без написания переводчика из Паскаля в инструкции GPU.
С сайта ATI скачал документацию по Open GPU, может быть там что-нибудь есть по вызову инструкций GPU напрямую, а то что-то поисковики ничего не могут найти.

инструкции GPU - напрямую не вызываются вроде. Как таковые шейдеры - это и есть инструкции GPU. GPU - умеет производить только математические расчёты. А эмулировать работы полноценного процесора на видеокарте не получится, только математические расчёты.

Нет, вроде бы вызываются, вот, например, http://developer.amd.com/gpu_assets/r600isa.pdf - описание машинных инструкций видеокарт серии AMD/ATI Radeon HD 2000 и как они вызываются. Но только там разбираться ещё нужно, наверное проще тогда уже писать на Stream SDK
Шейдеры потом ещё переводятся в машинный язык GPU, поэтому шейдеры - это не машинный язык графического процессора.
GPU может ещё и условные выполнения кода и циклы делать и ещё и функции вызывать, а не только математические расчёты, правда я не знаю как там у него с динамической памятью.

Могу ошибаться, но в моём понимании дело обстояло так. Разработчики игр и разработчики видеокарт, при разработке игр зашли в тупик применяя фиксированный графический контейнер. Видеокарты уже могли выполнять больше чем - отрисовывать полигоны, а какой работой загрузить видеокарту непонятно. Тогда совместными усилиями был придуман - не фиксированный графический конвеер, в нём видеокарта параллельно с отрисовкой полигонов могла производить матричные вычисления. В тот момент первые шейдеры были написаны на машинном языке GPU. Но так как поколения видеокарт постоянно меняется и фирм производителей не 1. И под каждую модель необходимо было писать свои инструкции - разработчикам просто стало неудобно и накладно писать все шейдеры на машинном языке GPU. Тогда были придуманы HLSL и GLSL (опять же в моём понимании и сокращённо) - высокоуровневые языки для каждого из графических API для написания шейдеров, при их выполнении они компилируются с помошью установленного драйвера видеокарты в инструкции машинного языка GPU оптимизированные под видеокарту на которой запускаются. После чего был придложен межплатформенный язык шейдеров CG, который работал как под OpenGL, так и под DirectX. Видеокарты ещё подросли в мощности и их уже можно использовать вне игр, но вотшейдеры ограничены тем что могут производить только математические расчёты и только из под графического API. Тогда было решено разработать интерфейс запуска шейдеров для математических расчётов без использования графического API (хотя бы без его прямого вызова) и считать не только математику та к у nVidia родилась CUDA у ATI - CTM, у Intel - Larrabee (вроде ещё пока не вышла). Пока технологии новые, у них нет кросплатформенной связки наподобие CG как у шейдеров но могут они больше. При всём при этом используешь ты CUDA или CG - основное их применение кроме игр: "ускорять физические эффекты в играх, выполнять научные расчёты, обрабатывать фотографии, перекодировать видеоролики, а скоро научатся и строить трёхмерные изображения методом трассировки лучей". Я вот сижу и думаю куда их ещё засунуть, не ускорять же нажатие кнопки в интерфейсе пользователя .

всё идёт по кругу?
на первых процах x86 был внешний мат. сопроцессор (x87) - птом его интегрировали в кристал
теперь новая реинкарнация мат. сопроцесора?

alexs писал(а):всё идёт по кругу?
на первых процах x86 был внешний мат. сопроцессор (x87) - птом его интегрировали в кристал
теперь новая реинкарнация мат. сопроцесора?

А дальше будет ещё круче, AMD в 2009 году выпустит Fusion, в нём в одном чипе будет совмещён обычный процессор и GPU (RV 800, по моему, правда эти видеокарты ещё не вышли), да и Larrabee - это вообще, как сообщает сама Intel, несколько десятков, сотен и даже тысяч обычных процессоров совмещённых в одном чипе.
В принципе уже сейчас можно реализовать рейтрейсинг на GPU, есть даже нормально работающие варианты на CPU, например, http://www.virtualray.ru, правда в нём все апроксимировано сферами, но освещение и тени выглядят просто отлично, а со временем рейтрейсинг, где всё аппроксимировано треугольниками будет вообще обычным делом. Уже сейчас ATI и nVidia показывают такие программы, правда в них рейтрейсинг обсчитывается двумя - четырьмя самыми мощными их видеокартами, и скорость получается около 30 кадров в секунду, при разрешении 1920x1080.
Да и если говорить, то это скорее процессор скоро станет вспомогательным средством для видеокарты, ведь видеокарта может не только математические расчёты производить, но и уже выполнять практически все функции процессора, например Stream SDK от ATI и CUDA от nVidia, на них можно компилировать обычные C/C++ программы и всё будет работать так же, как и на CPU, только процессоров в сотни раз больше. А ещё через какое-то время не будет никакого разделения на процессор и GPU, будет один чип, выполняющий функции и процессора и графического процессора.

и выйдет вин ХХХ и тормознёт этих монстров

Тут палка о двух концах, где то читал статью, что в принципе современные CPU - это мега-интерпритаторы, съедающие АСМ код и переводящий его в свой язык сигналов (тут неимет разницы делается это на самом камне или в драйверах, не будем на этом останавливаться) и что самое узкое место в программе это получение данных из оперативной памяти, а уж с винта - тем более вечность. И тут встаёт делема перед производителями GPU (я думаю, что у них так же интерпретатор) - их GPU - заточен под вывод графики и соответственно математические расчёты, если они решат в видеокартах нарастить функционал, то естественно производительность упадёт - тогда выход 2 интепритатора один для игр другой для всего остального (к чему сейчас Intel со своими встроенными картачками пытается дойти). Попросту получается что можно создать многопроцессорную машину навтыкав в неё "видеокарт" с камнями совмещающими в себе интерпретаторы CPU + GPU (какие нибудь модифицированные версии Intel ATOM). Но тут как говорится решает рынок... Будет интересен рынок видеокарт интелу - увидим видеокарты CORE2DUO , будет интересен рынок CPU nVidia - будут у нас процессоры GTX260 . В ATI vs AMD - вроде вообще как уже разработка идёт полным ходом (Fusion) - под лозунгом 2 интерпретатора 1 камень. Поэтому я как то к CUDA пока никак. CG как то по привычнее будет.

Добавлено спустя 2 минуты 13 секунд:
У видеокарт скорость обмена с памятью вроде как ниже чем у процессора, по крайней мере была 3 года назад. поэтому CUDA - это только начало - как 1 шейдеры.

Добавлено спустя 1 минуту 33 секунды:
Через 3 года - покупаем видеокарту цепляем к ней винт, мышь+ клаву, блок питания и монитор (память своя в 1 гиг уже есть) - компьютер собран

Я вот сижу и думаю куда их ещё засунуть, не ускорять же нажатие кнопки в интерфейсе пользователя

например, проблема разархивирования большого количества файлов - актуально на почтовых серверах (где надо вложенные архивы на вирусы проверять)
или поиск по рег.выражению в массиве (хотя не уверен что это можно на гпу ускорить, или можно?)

Slavikk писал(а):У видеокарт скорость обмена с памятью вроде как ниже чем у процессора, по крайней мере была 3 года назад. поэтому CUDA - это только начало - как 1 шейдеры.

Это у видеокарт то скорость обращения к памяти ниже чем у процессора? При её скорости за 2,5 ГГц и ширине до 512 бит, когда на системных платах 1600 МГц и, по моему, 32 или 64 бита. Да и видеокарты используют стандарты памяти вполть до GDDR5, тогда как системные платы только только начинают выходить с DDR3.

ev писал(а):например, проблема разархивирования большого количества файлов - актуально на почтовых серверах (где надо вложенные архивы на вирусы проверять)
или поиск по рег.выражению в массиве (хотя не уверен что это можно на гпу ускорить, или можно?)

Можно и то и то, если например каждый файл в своём потоке обрабатывать или разбивать файл на несколько кусков и каждый из них разархивировать по отдельности, а потом соединять всё вместе. Массивы так же можно разъединять на отдельные части и анализировать каждую по отдельности, только нужно на стыке частей массива проверять отдельно.

1. Процы.
Да, современный проц сейчас является ничем иным как интерпретатором asm-комманд в свой микрокод
Основной тормоз — память. Притом не скорость прокачки,а latency (какой бы широкой труба нефтепровода не была, нефть дотечет до точки назначения только через nn дней). И если скорость прокачки все время растет, то latency уже не меняется десятилетия. Потому придумали кеш. Эта система кеширования стала настолько монструозной, что у современных процессоров 80% транзисторов отводится под кеш и интерпретатор asm-кода. И только 20% - под АЛУ

2. Видеокарты.
Они заточены под паралельную обработку данных. Без ветвлений. Сплошной поток однотипных комманд, на сотнях процессоров.
Память заточена под оссобенность графики — локальность данных. Потому задержки сдесь не играют большой роли. Гораздо важнее — скорость(ширина трубы нефтепровода). Потому у видеокарт нет такого кеша как на ЦПУ

Специфика ЦПУ - брать маленькие объемы памяти из разных мест. Задержки критичны (длина нефтепровода).
Специфика ГПУ - большие объемы сгруппированные локально. Критична скорость прокачки (ширина трубы)

3. GP-GPU (General Purpose GPU)
Алгоритмы программ должны хорошо паралелится. Без ветвлений. С последовательным обращением к памяти (sequential access)
Любое нарушение правила — удар по производительности

Теперь возьмем обычную С++ программу. Удовлетворяет она этим требованиям?
Под сколько потоков она расчитана? На скольки процах ГПУ она будет выполнятся?
Сколько у нее ветвлений, и условных переходов, вызовов подпрограмм?
Сколько у нее одинокостоящих переменных по которым она прыгает в произвольной последовательности?

Если писать под ГПУ, то специально для него. Ни о каких кроссплатформенных решениях не может быть и речи (в общем случае)

*vmr писал(а):Если писать под ГПУ, то специально для него. Ни о каких кроссплатформенных решениях не может быть и речи (в общем случае)

Цитата http://www.f1cd.ru/news/pc/287/:
"Андрей Хумбер (Andrew Humber) из nVidia сообщил еще больше: "CUDA – это просто наше брендовое название для C компилятора. В остальном же они идентичны." Андрей Хумбер так же отметил финансово-аналитический день, проведенный компаний в апреле, когда была показа астрофизическая симуляция, которая работала на встроенной графике с 8 процессорами, на видеокарте из серии GeForce 8 со 128 ядрами и на четырехядерном CPU. Как сообщает nVidia на всех GPU использовалась одна и та же программа, и один и тот же исходный код использовался как для GPU, так и для CPU."

Да производительность при ветвлениях и произвольном доступе к данным на GPU будет уменьшаться, но всё-равно, обработка рейтрейсинга на видеокарте с 1600 процессорами, работающими на частоте около 700 МГц, будет гораздо быстрее, чем на CPU, даже 6 ядерном Xeon от Intel. И кроссплатформенный код, как говорит nVidia, возможен, другой вопрос, что скорее всего, не всё, что можно реализовать на CPU, будет работать и на GPU.

ну а что далко ходить? может кто возмется сделать програмку разархивирования?
вот и сравним на реальной задачке - что быстрее и на сколько именно

Вот и подошли к логическому завершению топика. Ждём программу и тестов .