Submitted by _57rus_AlieN on Thu, 03/05/2009 - 13:46.
Установил AMDStreamSDK 1.3 beta, пробую запустить любой exe из примеров, ругается на отсутствие библиотеки amdcalcl64.dll, соответственно не компилируются проекты - либовский файл на библиотеку есть, но самой библиотеки, соответственно, нет. В чем может быть причина? Заранее спасибо
Конфигурация: ASUS EAH4850 x2, Windows Vista Ultimate 64-bit SP1, Micro$oft Visual Studio 2008
Submitted by _57rus_AlieN on Thu, 03/05/2009 - 17:27.
Оказывается, 1.3 beta пашет тока с Каталистом 8.12 и больше ни с каким. При установке проверяет версию драйвера и, если это не 8.12, просто не устанавливает исполняемые файлы. И главное - молчком, говорит просто что не соответствует версия драйвера, что, естественно, вызывает жгучее желание обновить драйвера до наисвежайшей версии. Причем данная фича прописана в Brook+_Installation_Notes, так что RTFM :)))
Насчет отсутствия поддержки данной карточки - попробую откомпилировать проект и посмотреть как работает.
Отсутствие файла норма, dll компонента переехала в драйвер 3 месяца назад. Ваша видеокарта помоему не поддерживается, я видел жалобы на оффициальном форуме. Поддержка должна появится в 1.4 если не ошибаюсь. Проверьте версию драйвера и посмотрите на оффициальном форуме.
Решил (в который раз) все-таки взяться за изучение сабжа (написание программ). Но скудность документации не позволяет ничего понять (или скудность моего интеллекта?). В общем, вопрос такой: есть ли какие-либо доки (лучше всего учебники) по сабжу, окромя комплектного Stream Computing User Guide?
Например, попытался я написать поиск простых чисел. И написал. Только он не работает (выдает не все простые числа, некоторые пропускает). Но самое интересное - я не придумал, как на видюхе организовать генерацию чисел. Поэтому я запихнул в Stream натуральные числа, сколько влезло, а на видюхе их тестировал. неужели это единственный способ?!
В общем, помогите нубу, дайте ссылки на доки!
Спасибо.
Submitted by B7_Ruslan (not verified) on Fri, 12/26/2008 - 10:48.
Кому тут нужен проект брутфорса МД5 для старта работы со StreamComputing?
Писать на ящик [!<3ddev@mail.ru>!] C инетом перебои, так что почту проверяю не часто(1 раз в неделю), но как прочту сразу отправлю.
Не секрет, что различные игры в разной степени могут использовать потенциал многоядерных процессоров. Какие-то игры хорошо масштабируют быстродействие при переходе от двухъядерных процессоров к четырёхъядерным, другим это удаётся в меньшей степени. Помогают ускорить процесс оптимизации и разработчики драйверов.
Сайт BeHardware провёл исследование, целью которого была оценка степени оптимизации драйверов для видеокарт AMD и NVIDIA под четырёхъядерные процессоры в среде DirectX 9 и DirectX 10 соответственно. Итоги тестирования выявили интересные закономерности. Если в среде DirectX 9 драйверы видеокарт AMD ещё позволяют получить некоторый прирост быстродействия при увеличении числа процессорных ядер, то в среде DirectX 10 величина прироста измеряется единицами процентов. Для драйверов NVIDIA характерна другая закономерность: в среде DirectX 9 прирост быстродействия на системе с четырёхъядерным процессором заметен, но в среде DirectX 10 он выражен гораздо сильнее, и может достигать 21-24%. Такой результат достигнут оптимизацией драйверов.
Французские коллеги вчера сообщили, что AMD признаёт своё упущение, и готова представить в первом квартале 2009 года новую версию драйверов Catalyst, которая позволит видеокартам в среде DirectX 10 более эффективно использовать ресурсы четырёхъядерных процессоров. По оценкам представителей Intel, до 25-40% нагрузки на центральный процессор от игр формируют программный интерфейс Direct3D и драйвер видеокарты. Если распределить эту нагрузку между несколькими ядрами, ресурсами процессора можно управлять более эффективно.
"Catalyst 8.12 принесет новые возможности для серии Radeon HD 4000
Еще в 2005 году, когда ATI выпустила чип R520, было заявлено, что видеокарты серии Radeon 2000 смогут выполнять потоковые рассчеты и выполнять преобразование видео.
По определенным причинам этот проект был тогда закрыт. Однако впоследствии, NVIDIA наделала много шума со своим коммерческим транс-кодером, что дало AMD/ATI толчок к возрождению того проекта 2005 года.
В новой версии драйвера Catalyst 8.12 будет сделан ряд оптимизаций в игровых приложениях, что позволит серии Radeon HD 4000 стать еще более быстрой. Кроме этого, новый Catalyst 8.12 позволит выполнять преобразование видеоконтента заметно быстрее, чем это делается на видеокартах NVIDIA. Если это так, то над CUDA нависла угроза."
Это насчёт кривых дров. Надеюсь будет приличное улучшение.
Улучшение происходит почти с каждой версией (1 - 5%), иначе зачем AMD выпускает их раз в месяц, как часы?
Но я надеюсь на приличное улучшение вместе с Вами : )
P. S. Оффтоп : как на этом форуме цитировать?!
Конечно стоит. Не просто так же они его выкладывают.
Я пробовал запускать пример программы в VS 2008. А вот дальше не продвинулся. Плохо знаю английский. Вот бы кто написал вводное руководство для чайников :)
Да, хорошо бы организовать вместе людей, которые этим занимаются. А то материалов мало, и опытных программеров тоже мало.
А видюхи хорошие(особенно 48xx).
А не подскажете, случаем, где можно почитать о программировании в Brook+ (кроме официального мануала, конечно)? Извините, что не в тему. Прсто хочется изучить это направление, но пока ничего не понятно...
Submitted by Kos (not verified) on Sat, 12/20/2008 - 14:25.
Radeon HD - очень классные видахи просто кто-то не умеет маскировать задержки обращения к текстурному кешу и оператве. Этот вопрос детально обсуждается в мануалах nVidia и с недавних пор появилась инфа об этом у АМД. Нужно группировать треды и читать все необходимые данные единожды из одного треда в группе.
Submitted by Kos (not verified) on Fri, 12/19/2008 - 23:50.
Я кажется Вас на амд-ешном форуме видел, по делу : с другом интересуемся темой уже года полтора, почти год как у нас стоят совместимые с СДК карты - и где-то пол месяцев 9-10 как начали шарить сами. Сделали свой уровень абстракции над CAL, думали делать свой компилятор для кернелов, поскольку асма у брука пугающая - но оказалось что компилятор IL -> SDA(асма конкретного устройства) его спасает. Разбирались со всем сами, английские маны зачитаны до дыр, есть перевод на украинский.
Насчёт тормозов кто-то говорил - всё дело в задержках обращения к памяти и соотношении количества алу/текс клауз в асме самого низкого уровня. Тоесть видаха тут ни при чём, терафлопс без МАДД инструкций не выжмешь никак - но пол можно, я знаю что на обыкновенном бруке не + выжымали 300+ Гфлопс из 2900ХТ.
Submitted by Kos (not verified) on Sun, 12/28/2008 - 13:00.
Нужно утрясти некоторые вопросы типо там авта"рские права АМД и т.д., спрошу модеров на ихнем форуме, перевод был сделан не мной и у меня его нет, а двоешниками для моего научрука. Его вышеназванный вопрос волнуют сильно.
Значит, есть все-таки профессионалы в нашей стране! Это очень радует.
Скажите, пожалуйста, а есть ли какая-либо документация, кроме pdf из пакета SDK?
Спасибо.
Submitted by Kos (not verified) on Sat, 12/20/2008 - 14:13.
Ну данный профессионал из Украины))) Говорю же есть перевод на украинский язык, несколькими двоешниками по мат. методам. исследования операций, за оценку, я перевод вычитывал, некоторые моменты сложно перевести. Ну и переводом этим владеет мой научрук, тоесть у него есть интерес им не выпендриватся. На русском толокового не видел ничего. Может свой блог заведу как сдам сессию - выложу туда своих познаний.
Submitted by Kos (not verified) on Sat, 12/20/2008 - 18:01.
Я уже который год углубляю свои познания с помощью презентаций SIGGRAPH, в принципе я раньше интересовался CUDA и познания о определённых тонкостях работы с видахами именно из нвидиавских мануалов. Я думаю не имеет смысла привязыватся к одной платформе - необходимо знать как это работает на других, плюс есть доки на http://www.anandtech.com/ о деталях архитектуры - это тоже полезно.
Сам ищу, с кем бы пообщаться :)
Программировать не пробовал, пробовал разбираться в примерах из мануала. Понял не все, исчерпывающей документации нет, понятной тоже мало, хотелось бы побольше примеров, коих я вообще не нашел :)
Опять же, вся инфа, что я нашел, ограничивается английской докой.. Но я уверен, что есть люди, которые в этом разбираются. Надо только их найти.
После длительного перерыва во мне проснулось вышеуказаное существо. Решил напостить о программировании видеокарт в свой блог http://justanotherblog565.blogspot.com/
постараюсь быть интересным и информативным.
Спасибо!
Я временно отложил изучение, поскольку моя видюха (4850), похоже, не поддерживается текущей версией AMDStream. Жду дров 8.12, где это должно быть включено.
Ну или я что-то неправильно делаю, но сэмплы выполняются только на CPU.
P. S. У меня "аси" нет, мыло - alexxxx89 на яндексе.
уже несколько месяцев мучаю свою 4850, при том что у меня сейчас 8.7 установлен. Ихний SDK поддерживает все современные видеокарты. Но эртээфемить прийдется дейсвительно долго и нудно:)
Использую непосредственно ихний AMD Intermediate Language .
(Brook+ меня не впечатлил и в результате был забыт как плохой сон, после того как отловил несколько багов. правда это было давно- может сейчас он уже намного лучше)
Submitted by Kos (not verified) on Sat, 12/20/2008 - 14:22.
Я тоже использовал только IL, думал что раз брук генерирует сложный IL значит и исполнятся будет долго, оказалось что у АМД гениальный кампилятор IL в асму и он оставляет намного меньше инструкций. Тоесть в принципе это не плохо. Хотелось бы узнать какие баги нашли вы.
Кстати недавно почитал про DirectX 11 - что то мне подсказывает что он станет стандартом. ООП и семафоры на ГПУ - это мощно, с другой стороны это может отозватся снижением производительности относительно более низкоуровневых API. В принципе очень хороши для написания шейдеров HLSL и GLSL - очень хороший IL дают ны выходе. И глюков в них стопроцентно меньше.
Submitted by Key (not verified) on Wed, 12/31/2008 - 00:20.
Хмм, а откуда такая уверенность? зчем М$ конкурировать самому с собой? Есть у них HPC и денег на нем срубить можно, а с DX денег не много можно получить, если только за счет игр... Да и зачем AMD & Nvidia еще дополнительные затраты нести? Спорно это,- маркетолги не поймутс :)
Submitted by Kos (not verified) on Wed, 12/31/2008 - 14:59.
Уверенность берётся из сравнения платформ, чисто с точки зрения программиста. А использование видах в HPC тренд не первой свежести, но зато сильный, для АМД и Нвидиа никаких дополнительных затрат не предвидится, они реализовуют поддержку ассемблера виртуальной машины, и им всё равно какие шейдеры там будут выполнятся. В новом DirectX SDK - уже есть семплы с computing shaders. Кто не вкурил тему - его проблемы.
Submitted by Key (not verified) on Fri, 01/02/2009 - 14:46.
Да, ваша правда, но AMD что-то говорили об вычислениях c помощью шейдеров в DX11, но давайте подождем, вдруг это маркетинг и только - противодействие инициативе PhysX от конурента. Такой себе ход - на плечах M$ вырвать 1е место :)
Вот, что я понимаю,- SDK DX11 сейчас считает свои примеры в среде эмулятора, увы. Для текущих задач это неприемлемо. И еще возможная сложность трансляции из DX11 в реальный GPU может свести на нет все преимущества унификации, и если по производительности DX11 будет проигрывать хотя бы 50% по сравнению со средами AMD или nVidia, придется выбирать среды и без всяких на то сомнений. Пусть и сложнее будет для программиста, но есть у меня подозрение, что не настолько кардинально в нашей нишевой области. Да и платформ менять не надо - XP, хорошо пусть будет XP итд.. Матерьяльные затраты на смену ллатформ/железа учитывать приходится, в реальных задачах может понадобиться много или даже очень много GPU.
Submitted by Kos (not verified) on Sat, 01/03/2009 - 18:02.
Для того кто знаком и с платформой АТИ и с платформой нВидиа ясно что они по большей части одинаковые. Разница ощутима лишь в том что у АТИ SPMD - у нВидиа SIMD, у АТИ не было де 4-ой серии локального кеша в SIMD(читай SPMD) блоках, но этот недостаток с лихвой компенсировался ёмким общим кешем общим для всех контроллеров памяти (архитектура подсистемы памяти у АТИ поинтересней будет, обратите внимание как R600 превратился в R730 с 4-ёх кратным урезанием пропускной способности памяти и попутным ростом производительности). И у АТИ и у нВидиа железо делается под ДиректХ и не иначе. Driver Level API CUDA и ATI CAL - одинаковые по сути. DirectX11 будет работать на карточках АТИ уровня 4ххх может даже на 3хххх. Кто знает почему сейчас Директ10(9) хуже для gpgpu ? Я вам отвечу, он кеширует передачу данных, и тем самым увеличивает задержки. Он не даёт возможности сделать это самому и немного больше времени тратит на компиляцию. Он просто требует граф. специфики кода, от которой достаточно просто избавится, если в нём шаришь (сделать свои типы возвращаемых значений из пиксельных шейдеров, с семантикой, определённые через другие типы в которых семантика уже не обязательна). Смена платформы осуществляется легко и не принуждённо - у меня сейчас сервак 2008 и всё отлично работает,
С DX11 основной вопрос - это начиная с какого уровня оборудования будут поддерживаться Compute shaders (честно признаюсь, новые примеры не успел посмотреть).
Хотя нас гуры GPU-вычислений и учат, что правда - в регистрах, но локальная быстрая память (разделенная между кучкой шейдеров/threads) делает многое - удобнее (ну вот гистограмму посчитать, например).
А дальше вопрос - либо в CS локальная память будет, либо это в чистом виде stream computing (тоже дело, но куда более ограниченное).
Если OpenCL быстро зарелизят хоть с каким качеством на всех платформах, я бы на него ставил.
Submitted by Kos (not verified) on Sat, 01/03/2009 - 18:06.
Рассказывать достаточно долго, я об этом уже где-то на форуме писал, локальную память ДХ11 обязан поддерживать мне кажется, но семплов с её использованием не видел, работает на Радеон 4ххх, видел расширения АТИ к ХЛСЛ для поддержки gather/scatter - думаю тоже будет и с локальной памятью.
Я могу о DX11 судить только по самплам и той документации, которая имеется. Судя по самплам - локальной памяти нет, поэтому гистограмма в примере про HDR считается таким дурацким способом.
Как оно будет на самом деле - надо смотреть. На эмуляторе производительность смешная, не о чем говорить.
Что касаетя scatter в ATI - трудно поверить. MRT да есть, но там ограниченное количество targets. Конечно, архитектура не предназначена ни у кого, но даже если немного данных надо раскидать - ничего не выйдет без поддержки.
MRT - это multiple rendering targets т.е. переключение выходного потока (из нескольких) по условию. В ATI примерно годовалой давности их было фиксированное небольшое количество (4 что-ли, сейчас не вспомню). Возможно в R7xx оно стало лучше (если целиться в OpenCL, то куда деваться....).
Это не полноценный scatter, хотя для многих задач и может его заменить.
Сейчас наверное уже нет особого смысла вспоминать, после выхода новых версий SDK.
Например, вот этот кернел
kernel void subtractionBug(int a<>, out int c<>, out int d<>)
{ int constant_c = 4194304;
int constant_d = 4194305;
c = a - constant_c;
d = a - constant_d;
}
неверно исполнялся на гпу: 24бит числа (а точнее, числа =< 400000h) вычитались корректно, а вот с большими числами (т.е.
начиная с 400001h) начинались
проблемы.
Сейчас, кстати, проверил как он компилится через Stream KernelAnalyzer:
Comments
Поддерживаются следующие чипсеты:
- ATI Radeon HD 2000+ series, HD 3870, HD 4850, HD 4870
- ATI FireGL V7700
- AMD FireStream 9170, 9270
Удачи!
Установил AMDStreamSDK 1.3 beta, пробую запустить любой exe из примеров, ругается на отсутствие библиотеки amdcalcl64.dll, соответственно не компилируются проекты - либовский файл на библиотеку есть, но самой библиотеки, соответственно, нет. В чем может быть причина? Заранее спасибо
Конфигурация: ASUS EAH4850 x2, Windows Vista Ultimate 64-bit SP1, Micro$oft Visual Studio 2008
Оказывается, 1.3 beta пашет тока с Каталистом 8.12 и больше ни с каким. При установке проверяет версию драйвера и, если это не 8.12, просто не устанавливает исполняемые файлы. И главное - молчком, говорит просто что не соответствует версия драйвера, что, естественно, вызывает жгучее желание обновить драйвера до наисвежайшей версии. Причем данная фича прописана в Brook+_Installation_Notes, так что RTFM :)))
Насчет отсутствия поддержки данной карточки - попробую откомпилировать проект и посмотреть как работает.
Отсутствие файла норма, dll компонента переехала в драйвер 3 месяца назад. Ваша видеокарта помоему не поддерживается, я видел жалобы на оффициальном форуме. Поддержка должна появится в 1.4 если не ошибаюсь. Проверьте версию драйвера и посмотрите на оффициальном форуме.
Think Data Parallel http://justanotherblog565.blogspot.com/
Решил (в который раз) все-таки взяться за изучение сабжа (написание программ). Но скудность документации не позволяет ничего понять (или скудность моего интеллекта?). В общем, вопрос такой: есть ли какие-либо доки (лучше всего учебники) по сабжу, окромя комплектного Stream Computing User Guide?
Например, попытался я написать поиск простых чисел. И написал. Только он не работает (выдает не все простые числа, некоторые пропускает). Но самое интересное - я не придумал, как на видюхе организовать генерацию чисел. Поэтому я запихнул в Stream натуральные числа, сколько влезло, а на видюхе их тестировал. неужели это единственный способ?!
В общем, помогите нубу, дайте ссылки на доки!
Спасибо.
Кому тут нужен проект брутфорса МД5 для старта работы со StreamComputing?
Писать на ящик [!<3ddev@mail.ru>!] C инетом перебои, так что почту проверяю не часто(1 раз в неделю), но как прочту сразу отправлю.
Нужен брутфорс для RAR
Не секрет, что различные игры в разной степени могут использовать потенциал многоядерных процессоров. Какие-то игры хорошо масштабируют быстродействие при переходе от двухъядерных процессоров к четырёхъядерным, другим это удаётся в меньшей степени. Помогают ускорить процесс оптимизации и разработчики драйверов.
Сайт BeHardware провёл исследование, целью которого была оценка степени оптимизации драйверов для видеокарт AMD и NVIDIA под четырёхъядерные процессоры в среде DirectX 9 и DirectX 10 соответственно. Итоги тестирования выявили интересные закономерности. Если в среде DirectX 9 драйверы видеокарт AMD ещё позволяют получить некоторый прирост быстродействия при увеличении числа процессорных ядер, то в среде DirectX 10 величина прироста измеряется единицами процентов. Для драйверов NVIDIA характерна другая закономерность: в среде DirectX 9 прирост быстродействия на системе с четырёхъядерным процессором заметен, но в среде DirectX 10 он выражен гораздо сильнее, и может достигать 21-24%. Такой результат достигнут оптимизацией драйверов.
Французские коллеги вчера сообщили, что AMD признаёт своё упущение, и готова представить в первом квартале 2009 года новую версию драйверов Catalyst, которая позволит видеокартам в среде DirectX 10 более эффективно использовать ресурсы четырёхъядерных процессоров. По оценкам представителей Intel, до 25-40% нагрузки на центральный процессор от игр формируют программный интерфейс Direct3D и драйвер видеокарты. Если распределить эту нагрузку между несколькими ядрами, ресурсами процессора можно управлять более эффективно.
"Catalyst 8.12 принесет новые возможности для серии Radeon HD 4000
Еще в 2005 году, когда ATI выпустила чип R520, было заявлено, что видеокарты серии Radeon 2000 смогут выполнять потоковые рассчеты и выполнять преобразование видео.
По определенным причинам этот проект был тогда закрыт. Однако впоследствии, NVIDIA наделала много шума со своим коммерческим транс-кодером, что дало AMD/ATI толчок к возрождению того проекта 2005 года.
В новой версии драйвера Catalyst 8.12 будет сделан ряд оптимизаций в игровых приложениях, что позволит серии Radeon HD 4000 стать еще более быстрой. Кроме этого, новый Catalyst 8.12 позволит выполнять преобразование видеоконтента заметно быстрее, чем это делается на видеокартах NVIDIA. Если это так, то над CUDA нависла угроза."
Это насчёт кривых дров. Надеюсь будет приличное улучшение.
Улучшение происходит почти с каждой версией (1 - 5%), иначе зачем AMD выпускает их раз в месяц, как часы?
Но я надеюсь на приличное улучшение вместе с Вами : )
P. S. Оффтоп : как на этом форуме цитировать?!
Я сам не проверял. Но видел тесты, где более новые версии работали медленнее.
Я не знаю :(
Зависит от приложения: починили одно - сломали другое :) Бывает, но не так уж часто.
Конечно стоит. Не просто так же они его выкладывают.
Я пробовал запускать пример программы в VS 2008. А вот дальше не продвинулся. Плохо знаю английский. Вот бы кто написал вводное руководство для чайников :)
А давайте создадим команду программеров АТИ
Да, хорошо бы организовать вместе людей, которые этим занимаются. А то материалов мало, и опытных программеров тоже мало.
А видюхи хорошие(особенно 48xx).
Люди, вы где? :) Пишите сюда, кто хочет в команду. Обсудим.
А не подскажете, случаем, где можно почитать о программировании в Brook+ (кроме официального мануала, конечно)? Извините, что не в тему. Прсто хочется изучить это направление, но пока ничего не понятно...
Наиболее лучший вариант - скачать САL SDK. А вообще Радеоны - настоящие тормоза, т.к. среднее время выполнения инструкции - 1-12 тактов
Radeon HD - очень классные видахи просто кто-то не умеет маскировать задержки обращения к текстурному кешу и оператве. Этот вопрос детально обсуждается в мануалах nVidia и с недавних пор появилась инфа об этом у АМД. Нужно группировать треды и читать все необходимые данные единожды из одного треда в группе.
Я слышал карты превосходные, дрова очень кривые.
А Вы не слышали, в чем проявляется кривизна дров? У меня, к примеру, такого ощущения нет...
Ну то есть, мне говорили, что разработчики халтурят с дровами. Написаны не оптимальным способом.
Конкретно, я не знаю.
Alex, вы программировать под их карты пробовали? Если да, хочу с вами пообщаться. :) Куча вопросов, а с английским не очень.
Я кажется Вас на амд-ешном форуме видел, по делу : с другом интересуемся темой уже года полтора, почти год как у нас стоят совместимые с СДК карты - и где-то пол месяцев 9-10 как начали шарить сами. Сделали свой уровень абстракции над CAL, думали делать свой компилятор для кернелов, поскольку асма у брука пугающая - но оказалось что компилятор IL -> SDA(асма конкретного устройства) его спасает. Разбирались со всем сами, английские маны зачитаны до дыр, есть перевод на украинский.
Насчёт тормозов кто-то говорил - всё дело в задержках обращения к памяти и соотношении количества алу/текс клауз в асме самого низкого уровня. Тоесть видаха тут ни при чём, терафлопс без МАДД инструкций не выжмешь никак - но пол можно, я знаю что на обыкновенном бруке не + выжымали 300+ Гфлопс из 2900ХТ.
А мне руководство на украинском можно? Очень нужно,интересуюсь а с английский я дуб, вот и простаивает HD4850
Нужно утрясти некоторые вопросы типо там авта"рские права АМД и т.д., спрошу модеров на ихнем форуме, перевод был сделан не мной и у меня его нет, а двоешниками для моего научрука. Его вышеназванный вопрос волнуют сильно.
Значит, есть все-таки профессионалы в нашей стране! Это очень радует.
Скажите, пожалуйста, а есть ли какая-либо документация, кроме pdf из пакета SDK?
Спасибо.
Ну данный профессионал из Украины))) Говорю же есть перевод на украинский язык, несколькими двоешниками по мат. методам. исследования операций, за оценку, я перевод вычитывал, некоторые моменты сложно перевести. Ну и переводом этим владеет мой научрук, тоесть у него есть интерес им не выпендриватся. На русском толокового не видел ничего. Может свой блог заведу как сдам сессию - выложу туда своих познаний.
Ну я, типа, тоже оттуда :)
Язык не имеет значения(если английский :), предпочитаю в оригинале. Есть что-то из документации, чего нет в комплекте SDK?
Я уже который год углубляю свои познания с помощью презентаций SIGGRAPH, в принципе я раньше интересовался CUDA и познания о определённых тонкостях работы с видахами именно из нвидиавских мануалов. Я думаю не имеет смысла привязыватся к одной платформе - необходимо знать как это работает на других, плюс есть доки на http://www.anandtech.com/ о деталях архитектуры - это тоже полезно.
Сам ищу, с кем бы пообщаться :)
Программировать не пробовал, пробовал разбираться в примерах из мануала. Понял не все, исчерпывающей документации нет, понятной тоже мало, хотелось бы побольше примеров, коих я вообще не нашел :)
Опять же, вся инфа, что я нашел, ограничивается английской докой.. Но я уверен, что есть люди, которые в этом разбираются. Надо только их найти.
164 потом 904 и 077 - моя ася :)
Кого я находил на русском, кто хоть что-то делал:
http://salnikov-a.livejournal.com/
После длительного перерыва во мне проснулось вышеуказаное существо. Решил напостить о программировании видеокарт в свой блог
http://justanotherblog565.blogspot.com/
постараюсь быть интересным и информативным.
Think Data Parallel http://justanotherblog565.blogspot.com/
Спасибо!
Я временно отложил изучение, поскольку моя видюха (4850), похоже, не поддерживается текущей версией AMDStream. Жду дров 8.12, где это должно быть включено.
Ну или я что-то неправильно делаю, но сэмплы выполняются только на CPU.
P. S. У меня "аси" нет, мыло - alexxxx89 на яндексе.
уже несколько месяцев мучаю свою 4850, при том что у меня сейчас 8.7 установлен. Ихний SDK поддерживает все современные видеокарты. Но эртээфемить прийдется дейсвительно долго и нудно:)
Что делать?..
Какого ж тогда моя 4850 упорно не хочет запускать примера (все выполняется на проце)...
Ихний последний СДК поддерживает драйвер 8.9 и ниже,
http://forums.amd.com/devforum/messageview.cfm?catid=328&threadid=101580...
если установлен 8.10 или 8.11, то могут быть проблемы...
P.S.:или http://www.gpgpu.ru/node/68
У меня 8.8, так что дело не в этом...
А Вы только примеры гоняете, или сами уже начали осваивать?
Использую непосредственно ихний AMD Intermediate Language .
(Brook+ меня не впечатлил и в результате был забыт как плохой сон, после того как отловил несколько багов. правда это было давно- может сейчас он уже намного лучше)
Я тоже использовал только IL, думал что раз брук генерирует сложный IL значит и исполнятся будет долго, оказалось что у АМД гениальный кампилятор IL в асму и он оставляет намного меньше инструкций. Тоесть в принципе это не плохо. Хотелось бы узнать какие баги нашли вы.
Кстати недавно почитал про DirectX 11 - что то мне подсказывает что он станет стандартом. ООП и семафоры на ГПУ - это мощно, с другой стороны это может отозватся снижением производительности относительно более низкоуровневых API. В принципе очень хороши для написания шейдеров HLSL и GLSL - очень хороший IL дают ны выходе. И глюков в них стопроцентно меньше.
Хмм, а откуда такая уверенность? зчем М$ конкурировать самому с собой? Есть у них HPC и денег на нем срубить можно, а с DX денег не много можно получить, если только за счет игр... Да и зачем AMD & Nvidia еще дополнительные затраты нести? Спорно это,- маркетолги не поймутс :)
Уверенность берётся из сравнения платформ, чисто с точки зрения программиста. А использование видах в HPC тренд не первой свежести, но зато сильный, для АМД и Нвидиа никаких дополнительных затрат не предвидится, они реализовуют поддержку ассемблера виртуальной машины, и им всё равно какие шейдеры там будут выполнятся. В новом DirectX SDK - уже есть семплы с computing shaders. Кто не вкурил тему - его проблемы.
Да, ваша правда, но AMD что-то говорили об вычислениях c помощью шейдеров в DX11, но давайте подождем, вдруг это маркетинг и только - противодействие инициативе PhysX от конурента. Такой себе ход - на плечах M$ вырвать 1е место :)
Вот, что я понимаю,- SDK DX11 сейчас считает свои примеры в среде эмулятора, увы. Для текущих задач это неприемлемо. И еще возможная сложность трансляции из DX11 в реальный GPU может свести на нет все преимущества унификации, и если по производительности DX11 будет проигрывать хотя бы 50% по сравнению со средами AMD или nVidia, придется выбирать среды и без всяких на то сомнений. Пусть и сложнее будет для программиста, но есть у меня подозрение, что не настолько кардинально в нашей нишевой области. Да и платформ менять не надо - XP, хорошо пусть будет XP итд.. Матерьяльные затраты на смену ллатформ/железа учитывать приходится, в реальных задачах может понадобиться много или даже очень много GPU.
Для того кто знаком и с платформой АТИ и с платформой нВидиа ясно что они по большей части одинаковые. Разница ощутима лишь в том что у АТИ SPMD - у нВидиа SIMD, у АТИ не было де 4-ой серии локального кеша в SIMD(читай SPMD) блоках, но этот недостаток с лихвой компенсировался ёмким общим кешем общим для всех контроллеров памяти (архитектура подсистемы памяти у АТИ поинтересней будет, обратите внимание как R600 превратился в R730 с 4-ёх кратным урезанием пропускной способности памяти и попутным ростом производительности). И у АТИ и у нВидиа железо делается под ДиректХ и не иначе. Driver Level API CUDA и ATI CAL - одинаковые по сути. DirectX11 будет работать на карточках АТИ уровня 4ххх может даже на 3хххх. Кто знает почему сейчас Директ10(9) хуже для gpgpu ? Я вам отвечу, он кеширует передачу данных, и тем самым увеличивает задержки. Он не даёт возможности сделать это самому и немного больше времени тратит на компиляцию. Он просто требует граф. специфики кода, от которой достаточно просто избавится, если в нём шаришь (сделать свои типы возвращаемых значений из пиксельных шейдеров, с семантикой, определённые через другие типы в которых семантика уже не обязательна). Смена платформы осуществляется легко и не принуждённо - у меня сейчас сервак 2008 и всё отлично работает,
Я глянул мельком на DX11, на мой взгляд OpenCL будет таки гораздо удобнее (и мультиплатформенней - в перспективе)
С DX11 основной вопрос - это начиная с какого уровня оборудования будут поддерживаться Compute shaders (честно признаюсь, новые примеры не успел посмотреть).
Хотя нас гуры GPU-вычислений и учат, что правда - в регистрах, но локальная быстрая память (разделенная между кучкой шейдеров/threads) делает многое - удобнее (ну вот гистограмму посчитать, например).
А дальше вопрос - либо в CS локальная память будет, либо это в чистом виде stream computing (тоже дело, но куда более ограниченное).
Если OpenCL быстро зарелизят хоть с каким качеством на всех платформах, я бы на него ставил.
Рассказывать достаточно долго, я об этом уже где-то на форуме писал, локальную память ДХ11 обязан поддерживать мне кажется, но семплов с её использованием не видел, работает на Радеон 4ххх, видел расширения АТИ к ХЛСЛ для поддержки gather/scatter - думаю тоже будет и с локальной памятью.
Я могу о DX11 судить только по самплам и той документации, которая имеется. Судя по самплам - локальной памяти нет, поэтому гистограмма в примере про HDR считается таким дурацким способом.
Как оно будет на самом деле - надо смотреть. На эмуляторе производительность смешная, не о чем говорить.
Что касаетя scatter в ATI - трудно поверить. MRT да есть, но там ограниченное количество targets. Конечно, архитектура не предназначена ни у кого, но даже если немного данных надо раскидать - ничего не выйдет без поддержки.
Верить не нужно, нужно мануалы читать. Что за терминологию вы используете ? какие тагреты ?
MRT - это multiple rendering targets т.е. переключение выходного потока (из нескольких) по условию. В ATI примерно годовалой давности их было фиксированное небольшое количество (4 что-ли, сейчас не вспомню). Возможно в R7xx оно стало лучше (если целиться в OpenCL, то куда деваться....).
Это не полноценный scatter, хотя для многих задач и может его заменить.
Сейчас наверное уже нет особого смысла вспоминать, после выхода новых версий SDK.
Например, вот этот кернел
kernel void subtractionBug(int a<>, out int c<>, out int d<>)
{ int constant_c = 4194304;
int constant_d = 4194305;
c = a - constant_c;
d = a - constant_d;
}
неверно исполнялся на гпу: 24бит числа (а точнее, числа =< 400000h) вычитались корректно, а вот с большими числами (т.е.
начиная с 400001h) начинались
проблемы.
Сейчас, кстати, проверил как он компилится через Stream KernelAnalyzer:
; -------- Disassembly --------------------
00 TEX: ADDR(48) CNT(1) VALID_PIX
0 SAMPLE R0.x___, R0.xyxx, t0, s0 UNNORM(XYZW)
01 ALU: ADDR(32) CNT(13)
1 x: ADD_INT R0.x, (0xFFC00000, -1.#INDf).x, R0.x
y: MOV R0.y, 0.0f
z: ADD_INT R0.z, (0xFFBFFFFF, -1.#QNANf).y, R0.x
w: MOV R0.w, 0.0f
2 x: MOV R2.x, PV1.z
y: MOV R2.y, PV1.w
z: MOV R2.z, PV1.w
w: MOV R2.w, PV1.w
3 x: MOV R1.x, R0.x
y: MOV R1.y, R0.y
z: MOV R1.z, R0.y
w: MOV R1.w, R0.y
02 EXP_DONE: PIX0, R1 BRSTCNT(1)
END_OF_PROGRAM
"проблемная" инструкция по каналу z, вроде все нормально.
В IL компилит тоже без особых патологий:
"dcl_literal l12, 0x00400000, 0x00400000, 0x00400000, 0x00400000"
"dcl_literal l13, 0x00400001, 0x00400001, 0x00400001, 0x00400001"
.
.
.
"mov r272.x___, l12.x000"
"mov r273.x___, l13.x000"
"iadd r274.x___, r269.x000, r272.x000_neg(xyzw)"
.
"iadd r275.x___, r269.x000, r273.x000_neg(xyzw)"