LINUX.ORG.RU

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

 


0

0

Некоторое время назад мне пришлось написать CUDA-реализацию одного алгоритма. Понравилось. Хочу попробовать написать что-нибудь для живого opensource-проекта. Что и где можно распараллелить так, чтоб от этого была польза людям?

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

ixrws ★★★
()
Ответ на: комментарий от ixrws

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

chatbot
() автор топика

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

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

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

darkshvein ☆☆
()
Ответ на: комментарий от chatbot

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

ixrws ★★★
()

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

ixrws ★★★
()
Ответ на: комментарий от ixrws

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

ixrws ★★★
()
Ответ на: комментарий от ixrws

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

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

linuxfan
()
Ответ на: комментарий от linuxfan

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

Love5an
()
Ответ на: комментарий от Love5an

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

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

linuxfan
()
Ответ на: комментарий от vkos

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

chatbot
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.