LINUX.ORG.RU

Ускорение ядра Linux с помощью графического процессора GPU

 , , , , ,


0

1

Исследования Университета штата Юта, спонсированные частично компанией NVIDIA, направлены на изучение ускорения ядра Linux с использованием ускорения графического процессора GPU. Вместо того чтобы просто позволить приложениям пользователя использовать огромную силу предлагаемых современных графических процессоров, исследователи надеются ускорить части ядра Linux запустив его прямо на GPU.

>>> Подробности

Всегда было интересно — какие команды поддерживают эти самые GPU?
Предлагаю, также, использовать вычислительные мощи гуглофонов, подключенных по usb.

kompas ()

GFX карта не является неотъемлемой частью. компьютера, если это будет допольнительна фича не в ущерб производительности - то хорошо, если нет то не нужно даром.

anonymous ()

Игры проприетарщиков

гореть им в аду!

anarquista ★★★★★ ()

Исследования Университета штата Юта, спонсированные частично компанией NVIDIA, направлены на изучение ускорения ядра Linux с использованием ускорения графического процессора GPU.

«Yeah! We're gay! And this is our adopted love child! We're not from around here! Don't make us go back to our liberal city home with a tales of prejudice and bigotry in the heart of Utah!» (c)

имхо наркоманская задумка, что там ускорять? лучше б дрова нормальные открытые запилили

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

сходил по ссылке

Запланирована поддержка для открытого языка вычислений OpenCL Gallium3D со стекером состояния, но она еще не скоро будет готова.

что такое стекер? гугл дает ссылку на эту хабр и «стекер расшотался из за того что постоянно провода тыкаешь туда сюда»
и да, добавьте ссылок в статью

fads ★★ ()

вещества же хорошие!

MaZy ★★★★ ()

Почему вообще не закопают обычные процессоры, если на гпу всё так прекрасно «ускоряется»?

nudoru-kun ()

А что, ядро уже тормозит на обычных цпу?

anonymous ()
Ответ на: комментарий от nudoru-kun

Почему вообще не закопают обычные процессоры, если на гпу всё так прекрасно «ускоряется»?

про ARM то производители и разработчики думают не из-за ненависти к Intel, мощные процессоры то нужны не более чем игрунам на интеле. даже серверы на Atom-ах делают и видимо будут делать на ARM-ах. а считать на GPU.

tommy ★★★★★ ()

кастую в трэд анонимуса предсказывавшего это года 2 назад...

Thero ★★★★★ ()

Ненужные жуткие костыли: ядро общается само с собой через юзерспейсный софт

xorik ★★★★★ ()

Instead of figuring out GPU specs via reverse-engineering, it simply uses a userspace helper to do CUDA-related work for kernelspace requesters.

Ололо. Шутники что ли?

anonymous ()

Здесь весьма кстати была бы концепция микроядра

ttnl ★★★★★ ()

Обсудили уже, даже миркосрачик был. И вообще, я хочу на амд, амд, амд!

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

>А что, ядро уже тормозит на обычных цпу?
Сильно, аж до 12309!

darkshvein ☆☆ ()

не знаю как будет на fermi, а на всем предыдущем железе, ветвления, переносы данных host-device, sparse reads, убивают производительность.

на первый взгляд операционка как раз такая штука которую при помощи GPGPU можно только замедлить.

vasaka ★★★ ()

А как они собрались ускорять свободное ядро , если доступа к вычислительной части ГПУ без проприетарных блобов?

anonymous ()

OpenCL и CUDU - вселенское зло, условно пригодно только для рэйтрэйсинга да и то особого прироста не дает, разве что видеокарта топовая, а так лучше купит на те же деньги 4 восьмиядерника, толку больше будет.

anonymous ()
Ответ на: комментарий от nudoru-kun

>Почему вообще не закопают обычные процессоры

Потому что есть код, который нифига не параллелится. И для него и нужен cpu.

если на гпу всё так прекрасно «ускоряется»?


Да, но далеко не все алгоритмы. И вообще, ставлю пиво, что и на gpu начнут скоро писать такой быдлокод, что gtx590 проседать будет.

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

>условно пригодно только для рэйтрэйсинга

flacuda, CUDA h.264 encoder, ...

4 восьмиядерника


Это ты где нашел такие дешевые восьмиядерники?

devl547 ★★★★★ ()
Ответ на: комментарий от nudoru-kun

если на гпу всё так прекрасно «ускоряется»?

Дык, как раз и не всё, а строго опредлённые вещи. И программы, чтобы от графического ускорителя был толк, должны быть специально под это дело заточены. Надеяться запустить обычную программу на гпу и получить адское ускорение всег --- как минимум наивно.

ugoday ★★★★★ ()

Господа, вспоминаем про разработку CPU с GPU в одном флаконе. Там это самое оно будет. То, что сделано сейчас, это просто доказательство идеи и для реального применения не пригодно. Идея: ускорить отдельные операции в ведре при помощи GPU если оно есть в системе. А это доказательство возможности реализации этой идеи. Собранное на коленке из того, что было, но это совершенно нормально и достаточно для доказательства.

anonymous ()

еще бы SQL сервер на GPU

anonymous ()

Сопроцессор тоже когда то отдельно шел...

namezys ★★★★ ()

судя из новости на опеннете, aes они ускорили в 6 раз. так что очень даже хорошо выглядит, но реализация черезжопная из-за CUDA и юзерспейса...

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

>А что, ядро уже тормозит на обычных цпу?

Хороший вопрос, кстати. Я бы его переформулировал как «какой процент производимых вычислений занимают операции ядра, и стоит ли в таком случае заниматься их переносом на гпу?»

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

> OpenCL и CUDU - вселенское зло, условно пригодно только для рэйтрэйсинга

OpenCL отлично подходит для многих распараллеливаемых алгоритмов. Например для подсчёта хэшей, что уже сейчас даёт прибавку в скорости на два порядка, скажем в восстановлении паролей и генерации биткойнов.

JustGuest ()

Косая проприетарщина!! И нарушение GPL.

guitarist ★★ ()

Вот ядро и доросло до тяжёлой вычислительной задачи.

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

>Здесь весьма кстати была бы концепция микроядра

1) В ядре линукс есть fuse

2) В ядре линукс есть cuse

3) Из ядра линукс можно вызывать юзерспейсный код

Что тебе ещё из «концепции микроядра» не хватает?

Led ★★★☆☆ ()

А в ядре разве есть большое количество чистых вычилений? Видеокарты только это умеют, считать числа в 100500 потоков. Джедаев котрые смогли бы как то хитро переложить задачи ядра в чистые расчёты у них точно нет.

ranka-lee ()
Ответ на: комментарий от r0mik

r0mik > aes они ускорили в 6 раз

И зачем это в ядре? У меня трукрипт жрет несколько % при работе с криптоконтейнером. Не вижу профита.

JustGuest > Например для подсчёта хэшей, что уже сейчас даёт прибавку в скорости на два порядка, скажем в восстановлении паролей и генерации биткойнов.

На правах оффтопа, нашел https://en.bitcoin.it/wiki/Mining_hardware_comparison . Как я понял ати выигрывает за счет большего количества шейдерных процессоров.

А какие есть еще операции, где опенцл на ати превосходит куду нвидии столь сильно?

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

> И зачем это в ядре?

dm-crypt например. на i5 без aes-ni жрет ну точно не несколько процентов, а вполне ощутимо так.. тогда как запись без шифрования вообще ничего не жрет, так что есть зачем. но только не в такой реализации

r0mik ()

Скоро до процессора сетевой карточки доберутся и будут на нем запускать отдельные куски ядра. Имхо маразм.

nt_crasher ★★★ ()
Ответ на: комментарий от ranka-lee

> А в ядре разве есть большое количество чистых вычилений? Видеокарты только это умеют, считать числа в 100500 потоков. Джедаев котрые смогли бы как то хитро переложить задачи ядра в чистые расчёты у них точно нет.

Могут найтись, где-нибудь в районе работы с сетью. Шифрование тоже хорошо на куду ложится.

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

> Это ты где нашел такие дешевые восьмиядерники?

Может имел ввиду восьмипоточный(4 CPU) Corei7-2600K, цена 300$ Да, и через месяц повяться 8-ядерные Bulldozer, они будут стоить дешевле, это по-любому, так как они сливают Corei7-2600.

rom-hvichia ()
Ответ на: комментарий от Thero

> кастую в трэд анонимуса предсказывавшего это года 2 назад...

Чего тебе?

anonymous ()

А че, криптографию на гпу считать было бы нормально

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