GPU tools & набортные видюхи

Доброго всем времени суток.
Просветите чайника, в данной области, плз.
У меня такой вопрос: дружат ли все эти SDK (CUDA, OpenCL и пр.) с набортными (теми что на матерях) видюхами?
Если да, то начиная с какого семейства? Если нет, то почему.
2 модератор:
В великобуржуйском языке я не силен, а ресурсов на "великом и могучем" не так уж и много.
Не чайника убивайте сразу.
Спасибо.

Forums: 

Это зависит, если я не

Это зависит, если я не ошибаюсь, от того какой чип в видюхе. Этот чип соответственно должен поддерживать нужную технологию.

Технология CUDA - чисто НВидиевская, работает только на их микросхемах (вот ссылочка с более подробной инфой - http://www.nvidia.ru/object/cuda_gpus_ru.html)

opencl - штука кросплатформенная, но естественно тоже не везде идёт. Точнее сказать не могу

SDK NVidia дружит с

SDK NVidia дружит с ноутбучной отдельной графикой (которая 8500M и выше).
SDK ATI - соответственно - с ATIшной отдельной графикой.

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

Доброго всем времени

Доброго всем времени суток.
Моя вина, мне стоило выразить свою мысль точнее.
Я имел ввиду чипсеты AM690G-AM785G (ну и их конкуренты от nVidia тоже), т.е. обычные писюковые мамки с интегрированной графикой.
Просто в случае, когда имеется такая мамка и внешняя более мощная видяха, интегрированная видяха "ржавеет за даром". Вот и подумал, можно ли ее как-то задействовать в качестве доп. вычислителя.
Ведь их занятость могла бы неплохо "пришпорить" такие вещи как игры, кодирование видео, архиваторы и пр.

Ну вот конкретно для AMD

Ну вот конкретно для AMD список железа с поддержкой ATI Stream (включая OpenCL) просто перечислен у AMD:
http://developer.amd.com/gpu/ATIStreamSDK/Pages/default.aspx#two

Никаких интегрированных чипсетов в списке нет.

У NVidia в интегрированную графику для десктопов входит geforce 7xxx (если я правильно их таблички прочитал) - там cuda тоже нету.

Надыбал страничку, под

Надыбал страничку, под названием "ATI Stream SDK v1.4-beta System Requirements".
Там перечислены чипсеты начиная с AMD760G до AMD790GX.
Да, хохма получается: 1.4 держал чипсеты, а 2.1 не признает их!
Снова маркетинг в карман потребителей какает. :-(

Я вот до чего додумался (не в коей мере не претендую на открытие): в будущей битве gpu выиграет та контора, которая сумеет больше денег раздать игрописательским компаниям. Следовательно, потребители продукции проигравшей стороны, вынуждены будут снова выкладывать свои кровные, для покупки поддерживаемого играми железа.
Я не оговариваюсь, акцентируя внимание на играх, как показывает история развития компов, именно игры чаще всего оказывались стимуляторами развития железа.

Приглашаю к обсуждению всех, кому это интересно.
Прошу не судить строго, мой программерский век закончился на i8086-i386, примерно со смертью MS-DOS (как самостоятельной ОС), а с тех пор много чего изменилось.
Теперь, собственно, к чему я клоню (чисто абстрактная болтовня. Надеюсь модератор простит, если чего нарушил ненароком).
Возможно ли создать драйвер виртуального потокового процессора, именно из незадействованных чипсетов?
Попробую пояснить свою сырую мысль (эх моё косноязычие):
Представим, в системе появляется виртуальный потоковый процессор (VSP), объединяющей в себе какое-то число потоковых вычислителей. Драйвер VSP обеспечивает механизмы синхронизации и пр. необходимые функции, а также загрузку библиотек унифицированных (для создания платформонезависимости ) псевдокоманд и API. Эти библиотеки псевдокоманд, по своей сути являются набором функций на gpu-понятном языке. Движок игры (БД, антивируса и пр.) взаимодействует с VSP через API. Т.е программерам движков и прикладного софта нет нужды заморачиваться с драйверами и пр. Для них, в системе, есть лишь данные о количестве доступных вычислителей, их примерной "скорострельности", ну и конечно потребные им псевдокоманды.
Т.е механизм напоминает механизм взаимодействия классического 86 с 87, только вместо команды WAIT вызывавшей остановку CPU, до получения результатов от MPU, здесь CPU продолжает выполнение других потоков, периодически анализируя флажок наличия результата конкретного вычислителя VSP. После появления флажка готовности, прерванный поток продолжает свое выполнение, а вычислитель может быть задействован другим потоком.
Плюсы:
1. Программерам прикладного уровня нет необходимости лезть в системное программирование, затачиваться под какую-либо конкретную платформу, т.к все псевдокоманды унифицированы.
2. Софтовая реализация драйвера и API, позволяет легко модифицировать все это хозяйство с целью оптимизации и устранения ошибок.
3. Унифицированная система команд, позволяет рассчитывать что смена поколений GPU, а также введение новых псевдокоманд, не вызовет проблем несовместимости со старым железом.
Недостатками, имхо, будет некоторое снижение "скорострельности", из-за прослойки API, ну и титанические усилия по реализации всего этого.
Прошу высказывать свои соображения по этому поводу, желательно конструктивные.

Вообще то я имел ввиду

Вообще то я имел ввиду немного другой подход (с точки зрения прикладника): без использования дополнительного софта и пр. танцев с бубном. Просто подключаешь dll-ку и вызываешь нужные тебе псевдокоманды (они же функции), не заморачивая себе голову дополнительными языками, регистрами и пр.
Ведь используя в своей программе COM-порт, к примеру, через WinAPI, Вы не ломаете себе голову на тему "а в каком регистре и какой бит нужно взвести/уронить?", Вы просто работаете с файлами.
Аналогия конечно "притянутая за уши", но это чтобы меня понятнее было.

Тогда надо и начинать с

Тогда надо и начинать с API.

Если у нас "универсальный счетный процессор", то API к нему - это язык программирования или ассемблер.
Ну так и есть уже такое, "язык программирования - OpenCL", ассемблер - OpenGL-ный ассемблер для шейдеров.

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

Я конечно уже анахронизм в

Я конечно уже анахронизм в программирование, но API - application program environment, а язык программирования - это язык программирования.
Если Вы имеете ввиду на чем создавать API, то да Вы безусловно правы OpenCL и пр.
Но пишущему движок или какой другой софт, ему это(OpenCL и пр) уже не должно быть нужным, он юзает уже созданные API, библиотеки и может вызывать их из любого удобного ему языка программирования (C, Delphi и пр.).
Т.е я говорю о создании "прослойки" м/у чипсетом и традиционными языками программирования.

Что касается иллюзии, во времена MSDOS существовало несколько драйверов для мышек, "правильный" драйвер приходилось искать методом "тыка". И тоже казалось что это никогда не кончится.
Но сейчас драйвера для мыши - тема не актуальная для типовых мышей, за исключением случаев когда нужно задействовать доп. кнопки, ну и пр. Я уже не говорю о появлении устройств PnP, которые тогда переводили как "плаг энд плач", т.к. без "танцев с бубном" они редко заводились, а то и вовсе отказывались работать.
Работа делалась и всё устаканилось.

Я еще раз

Я еще раз переформулирую.

Библиотеки - это под конкретную прикладную задачу. Или неприкладную. Умножение матриц, разложение фурье, сжатие видео, подбор пароля, ну я не знаю.
Ну естественно, авторы уже существующих библиотек потихоньку понесут их на GPU/OpenCL - там где это имеет смысл. А прикладной программист останется с (уже) существующим API.

Но я вас так понял, что речь идет о некоем "виртуальном вычислителе" т.е. без спецификации задачи. Горшочек - вари, считатель - считай.
Если мы никакой конкретной задачей не ограничились, сегодня хотим видео сжимать, а завтра - пароли подбирать, то универсальное API к такому вычислителю - это язык Fortran (или C или Lisp или машина тьюринга).

Практически в точку. Я

Практически в точку.
Я говорил про универсальные вычислители, к которым, в зависимости от потребности ПО, подгружаются библиотеки с соответствующими функциями (псевдокомандами).
Самым простым случаем действительно было бы сварганить кучу библиотек с с функциями на все случаи жизни.
Но, имхо, тут есть подводный камень - безопасность. В случае с библиотеками, как я понимаю, нет возможности контролировать какой процесс и как использует ресурсы ГПУ.
Допустим Вы установили какую-то софтинку, которая чего-то там делает, а если это троян подбирает пароль к учетке админа? Или того хуже - Ваша машина в бот-сети и корёжит чьи-то серваки?

Поэтому мне и пришла в голову мысля про необходимость некоего централизованного механизма контроля и управления(VSP) универсальными вычислителями. До кучи он осуществляет все необходимые функции синхронизации, диспетчеризации , обработки ошибок и пр, ну Вам виднее чего там еще необходимо. Реализуется драйвером VSP.

Для работы со всем этим, из языков высокого уровня, имеется API, через которое прикладнику становится доступным все это хозяйство.

При попытке реализовать такой

При попытке реализовать такой API он выродится в язык(и) программирования + JCL. С 60-х годов мало что изменилось по сути.

Если не секрет, почему Вы так

Если не секрет, почему Вы так решили?
Ведь в MSDOS INT21 не выродился в язык программирования и даже не превратился в надстройку к языкам.
Может Вы меня снова не поняли?
Попробую объяснить так.
В header-ах, как обычно, прописаны функции. Прикладная софтина (ПС) загружает dll-ку с функциями VSP.
1. ПС: "VSP, тук-тук, ты дома?" Вызов функции VSP_Presented.
VSP: " Да."
ПС: "А сколько виртуальных попугаев ты способен застрелить за секунду?"
VSP: " 1000"
ПС: "А сколько у тебя не занятых стволов?" Return_Empty_Cores
VSP: " 3"
ПС: "Тогда будь добреньким, перемножь эти 2 матрицы".
VSP: " Хорошо, записываю этот вычислитель на твое имя?" Грузит библиотеку матриц, подставляет данные матриц функции, написанной на OpenCL или шейдерах и отдаете все это незанятому вычислителю.
ПС: "А другим потоком посчитай углы отклонения лучей света проходящего через призму. Как закончишь передай плиз эти данные видяхе, пусть рисует."
VSP: " Ладно, просчитаю - отдам." Аналогично для другого вычислителя.
ПС: "А еще мне нужно просчитать траекторию полета пули про таком-то боковом ветре. Как досчитаешь все 3 задачи, свистни. А я пока спрошу хозяина, может он уже передумал."
VSP: "Ладно, ладно. И чё тебе не спится?." Грузит 3-й вычислитель.

Утрирую конечно, но лишь для понятности.

Ну так MS-DOS Int21 и матрицы

Ну так MS-DOS Int21 и матрицы не мог перемножить, правильно?

Вы либо делаете фиксированный и простой API, либо произвольный.

Конечно не мог. Через него

Конечно не мог.
Через него осуществлялся доступ ко многим другим функциям, как самой ОС так и железа.
Его было бы уместнее сравнивать не с вычислителями(ведь вычислители это физические процессоры ГПУ), а с VSP.
И для общения прикладной софтины с VSP совсем не нужны никакие OpenGL, OpenCL и пр.
А для работы VSP с ГПУ, вот тут да, тут карты в руки OpenCL, OpenGL, CUDA и пр .
Упрощенно, VSP получив от прикладной софтинки вызов функции, грузит в память библиотеку, в которой эта софтинка написана на шейдерах, "скармливает" свободному процессору ГПУ эти шейдеры и входные данные. А после того как функция будет посчитана, вернет прикладухе результаты.
Поэтому я не понимаю, зачем прикладухе отдельный язык общения с VSP?
Имхо, API в данном случае, будет мало чем отличаться от работы с каким-нибудь другим контроллером, например винта или вышеозначенного мной COM-порта.
Единственное существенное отличие будет в том, что это будет виртуальное устройство, через которое будет осуществляться взаимодействие с ГПУ и которое будет выполнять все сервисные функции.

Послушайте, ну "у винта"

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

Но у вычислителя - либо есть простое API примерно как у машины Тьюринга - и можно решать любую задачу, либо есть API куда более высокого уровня "перемножить две матрицы" или "играть видео" - но через API перемножения матриц вы не проиграете видео (и наоборот).

И я не понимаю, как можно сделать обозримое высокоуровневое API для *всего*, всех вычислительных задач. Вы для начала их исчислите....

OpenCL

OpenCL может быть обвёрткой не только для GPU.
Даже сейчас OpenCL может использовать CPU.
Ничто не мешает написать вам свой вариант OpenCL, который будет использовать хоть кластер, хоть FPGA, хоть реальную тележку Тьюринга которая катается на реальных(физических) рельсах, в которой сидит машинист Петя.
И приложения которые используют OpenCL легко буду использовать вашу библиотеку(вообще без переработок).
Фактически использование OpenCL похоже на описанный вами псевдокод с попугаями.

Вы понимаете, что в случае Windows, OpenCL возможно реализовать как раз в виде DLL(и есть уже готовые реализации от NVidia и ATI)? И как раз эти DLL можно использовать в разных языках программирования.

"Т.е я говорю о создании "прослойки" м/у чипсетом и традиционными языками программирования."
OpenCL как раз и является прослойкой между языками программирования и физическими/виртуальными вычисляторами.