[cuda] К какому opensource-проекту примкнуть?

Примкните к какому-нибудь проекту, реализующему эту самую куду и сделайте поддержку amd, powervr хотя бы. А вендорлокин в опенсорсе не устраивайте.

Осилить OpenCL - не проблема. Проблема в том, что беглый поиск по клюевым словам на sourceforge.net выдает кучу мертворожденных или слишком специфичных проектов. Но, уверен, есть масса программ, не заявляющих себя как дислодробильные, но где-то всё равно вынужденных считать большие обьёмы данных и тормозить. Вот примерно такое и ищу.

(Пере)сборка ядра же.
/me плачет, умаляет на коленках написать.

И параллелится очень даже хорошо.

Мм. Если же не ядро, то.
1.Распараллеливание для gcc (apt-build эксперименты с флагами и оптимизацией системы прошли бы на разы быстрее)
2. Прослойку таки для ядра, чтобы некоторые тупые кодировщики видео ли аудио видели что ядро не одно (У Athlon X4!!) а мноога. Хотя хм. это довольно таки трудоёмкая работа, включается в себя не только реализацию для CUDA и один Лор с ней не справится.
2а.(уточнённое) Короче чтобы сотни аудио флаков для сотового можно было кодить в mp3 на видеокарточке.

Ну в общем большинство приложений, более-менее плоно работающих с анимацией. Поскольку та же OpenGl хорошо параллелится, то например ускорение прорисовки того же gtk, на уровне оптимизаций движка, какого-нибудь муррин. То же касается многих библиотек, способных компосайтить софтверным путём, типо imagemagick, gd, imlib и тд. Ускорение той же cairo средствами параллелилизма. Профиты от работы получат большинство приложений. Я бы сосредоточился именно на оптимизации инструментов. Возможно даже в Иксы влезть, но там правда уже давно одни битмапы суются, а сам протокол почти не юзается для проприсовки.

Ещё конечно было бы очень интересно видеть грамотное распараллеливание как парсинга, так и исполнение в python и perl интерпретаторах. Но там пахнет далеко не только применением cuda|opencl.
Легко параллелится всякая фреймовая хрень, типо медиа, крипто и компрессо. Браться за то, где параллельностью и не пахнет. Но опять же, часто там можно обойтись банальным openmp или ещё более банальным пложением кучи рабочих потоков. Но тема всё равно интересная, ибо используется очень широко, а работает до сих пор остойно. Скажем ускорение компрессии пусть даже путём увеличения нагрузки на cpu очень актуально.

Граммар наци негодуэ! Постараюсь больше не постить не зачитав. Всё пытаюсь поймать себя на этой мысли, да не получается:(

>Но там пахнет далеко не только применением cuda|opencl.

Это задачи вообще не для GPU. GPU пригодно только для параллельного исполнения одинакового кода, причем желательно без ветвлений и циклов.

>причем желательно без ветвлений и циклов.
Это желательно только если ты нищеброд и на современные GPU у тебя денег не хватило.

>Это желательно только если ты нищеброд и на современные GPU у тебя денег не хватило.

Лиспофил видел CUDA/OpenCL только на картинках? С таким подходом ты напишешь поделку, которая в 512 потоков в GPU будет работать медленнее, чем в 1 поток на CPU.

Оправдываешься?

Перепиши какой-нибудь рендер на opencl (например, blender render).

Всем спасибо за ответы. Особенно, за Blender.