@iManiacDev8 мая 2011 в 17:13

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

2 мин

6.9K

Настройка Linux *

Перевод

+64

Комментарии 64

@Ilya_Smelykh 8 мая 2011 в 17:26

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

@redchrom 8 мая 2011 в 17:36

s/стекером состояния/трекером состояния/. В оригенале полагаю было state tracker.

@iManiacDev 8 мая 2011 в 17:47

Да именно так, исправил…

@ananazzz 8 мая 2011 в 17:41

Лет через 5-7, мне кажется, в PC процессор нужен будет только за тем, чтобы загрузить BIOS ;-)

@TheWanderer 8 мая 2011 в 17:57

Ну как бы всё начинается с биоса…

@SovGVD 8 мая 2011 в 18:03

ну как бы биос отмирает

@TheWanderer 8 мая 2011 в 18:05

Ничего другого на EFI кроме маков я пока не видел… Всё остальное с биосом

@SovGVD 8 мая 2011 в 18:11

недавно вроде бы пробегали статьи на хабре что кто-то от биоса начинает отказываться, да и любимая всеми винда вроде бы уже поддерживает небиос =)
да еще ARMы наращивают мощности активно, оставаясь при этом довольно экономичными, жалко что мощности растут, а до адекватной оси (телефонные не в счет), которая бы использовала все аппаратные возможности, как до Плутона

@TheWanderer 8 мая 2011 в 18:19

На счет ARM — с Вами кто-то не согласен www.iphones.ru/iNotes/139314 ;)

@SovGVD 8 мая 2011 в 18:24

если они это сделают — будет шедевр, но на_данный_момент куча разрозненных портов Linux под разные армы с разной оптимизацией и все уже устарели, из более менее красивых щас вспомню только AlwaysInnovating — у них что то интересное на BeagleBoard, сразу несколько осей работает на стареньком TI OMAP

@Shirixae 8 мая 2011 в 21:24

Под Win8 ARM поддержка заявлена, в сети даже были утёкшие билды.

@muromec 8 мая 2011 в 21:40

вы совершенно не понимаете, что такое «поддержка ARM».

это бессмысленное словосочетание, потомучто ARM — это только набор инструкций, которым оперирует процессор.

скомпилировать бинарь под армовый процессор — это не проблема вобщемто.

проблема запуска винды на армах — в поддержке платформы… но армовое железо — это зоопарк, который не имеетобщей платформы.

виндос восемь может поддерживать какой-то конкретный (или несколько) SoC и их стандартную обвязку, но не арм вообще.

@Shirixae 9 мая 2011 в 04:51

Ну вот теперь пришли вы, благородный джентльмен, всё мне разъяснили, и теперь я буду умный. Спасибо :)

@roman_tik 8 мая 2011 в 19:58

недавно вроде бы пробегали статьи на хабре что кто-то от биоса начинает отказываться

ASUS уже вроде на своих материнках BIOS на UEFI меняет.

@ArtRoman 8 мая 2011 в 22:44

О HP тоже со своими графическими «биосами» и утилитами диагностики знаю.

@gMaXi 9 мая 2011 в 17:38

и у MSI вроде как встречается

@widowmaker 8 мая 2011 в 18:16

Я вот пишу с MSI P67A-GD65 с UEFI, особой разницы с биосом не заметил, кроме картинок и поддержки мышки. Наверно самая приятная особенность — это попробовать новую версию прошивки без собственно прошивки, но особого применения я ей не нашел, т.к. на мамке 2 модуля UEFI и при отказе первого можно загрузится со второго.

@Deeman 9 мая 2011 в 03:50

Посмотрите в сторону Coreboot. :)

@Klaus 9 мая 2011 в 07:50

Bootloader

@Popik 8 мая 2011 в 18:28

Как бы класс задач, которые можно эффективно распараллелить на куде весь мал. А гонять непараллельные вычисления на графическом ядре это удел душевнобольных, поэтому от процессора общего назначения уйти вряд ли получится.

@zizop 8 мая 2011 в 17:46

Ну всё к тому идёт собственно… Раз есть простаивающий ресурс, то почему-бы им не воспользоваться. А если сделать универсальный подход, да ещё и подсистемы ядра вынести то это будет бомба. Понятное дело, что проблем куча, без этого никуда.

@fzfx 9 мая 2011 в 16:26

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

@BarsMonster 8 мая 2011 в 17:47

Если резюмировать — на данный момент на GPU только шифрование/расшифровка AES, а это жалкая пара сотен строк кода, и возможно крайне незначительное ускорение (особенно если учесть что текущее ядро поддерживает аппаратное ускорение AES встроенное в некоторые современные процессоры) — совершенно не соответствующие эпичному заголовку «запуск Linux на GPU».

@polym0rph 8 мая 2011 в 20:11

Все с чего-то начинается. Многие вызывающие сейчас уважение проекты в момент рождения были смешны или казались не более чем игрушкой.

@Goganchic 8 мая 2011 в 20:24

тут дело немного в другом: вполне возможно использовать GPU для более широкого круга задач, но при этом нужны алгоритмы расчитанные на SIMD архитектуру, а их сейчас не так уж и много, тем более в пространстве ядра
если будут алгоритмы — то будет и смысл в разработке, сейчас же пока что пользы от поддержки GPGPU в ядре будет не очень много

@romx 9 мая 2011 в 02:54

Претензии в данном случае к заголовку alizar-style

@halyavin 8 мая 2011 в 18:33

Я вот только не могу понять, а как же безопасность — программы на CUDA могут читать и записывать память друг друга. Но если люди из nvidia изобретут защищенный режим для видеокарты, то это будет просто замечательно.

@akzhan 8 мая 2011 в 19:52

В режиме ядра?

@halyavin 8 мая 2011 в 20:18

Извините, но я не понял, к какой именно фразе относится ваш вопрос.
Защищенный режим для видеокарты не требует выделения режима ядра.
Сейчас GPU часть CUDA программ выполняется без какой-либо защиты. Любая GPU программа может записать и прочитать по любому адресу видеопамяти — на GPU никаких режимов сейчас нет. Единственное ограничение — программы разных процессов не могут исполняться одновременно. Можно пытаться строить защиту исходя из этого, но тут есть масса подводных камней. Возможно им удалось их все обойти.

@muromec 8 мая 2011 в 20:47

открою страшную тайну: все ядерные драйвера могут читать и писать память друг-друга.

@halyavin 9 мая 2011 в 04:28

CUDA программы обычно запускают из юзерспейса.

@amdf 8 мая 2011 в 18:51

Нельзя просто взять и запустить Linux на GPU. Нужно ещё придумать, какие специфичные вычисления внутри ядра вообще имеет смысл так запускать. Может оказаться, что таких и вовсе нет. GPU всё-таки специализированный процессор.

@Veliant 8 мая 2011 в 19:17

А я всегда почему-то считал, что все упирается как минимум в скорость переключения колец защиты… А тут оказывается для ускорения ядра надо математические действия ускорять…

@muromec 8 мая 2011 в 20:40

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

подозреваю, что в блочном вводе-выводе, стоимость самого сискола — не самое узкое место.

@Klu4nik 8 мая 2011 в 19:37

Мне кажется, что будущее будет за системами на одном кристалле, когда процессор полностью интегрирован с видеоускорителем. Существующие системы с видеоускорителем находящимся внутри процессора все еще имеют разделение на два отдельных устройства в логическом уровне, пожалуй, это накладывает некоторые ограничения на возможности орагнизации совместных вычислений.

В тоже время на данный момент имеется практически 30 летний опыт разделения вычислений на два отдельных чипа, и вероятно, что будут иметь место проблема перехода на новые методики разработки ОС.

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

@polym0rph 8 мая 2011 в 20:15

А пусть пока только nVidia, не вижу ничего страшного. Если они сделают что- то реально полезное, то конкуренция не заставит себя долго ждать. Странно было бы если они изначально на OpenCL ориентировались, т.е. вкладывали бы свои средства в разработку продукта, который на блюдечках получат бесплатно конкуренты.

@muromec 8 мая 2011 в 20:29

>Мне кажется, что будущее будет за системами на одном кристалле, когда процессор полностью интегрирован с видеоускорителем.

в современных SoC, MCU и GPU — это как раз два разных логических устройства, хоть и в одном кристалле.

просто потому, что дизайн ARM-ядра берется (лицензируется) готовый, а дизайн GPU — делают отдельно.

НЛО прилетело и опубликовало эту надпись здесь

@muromec 8 мая 2011 в 22:08

в тегре, процессор и gpu — два отдельных устройства, живущих в одном кристалле

@muromec 8 мая 2011 в 20:38

чего к GPU вообще привязались? в нормальных системах AES и так гоняется аппаратно.

и все остальное, что имеет смысл ускорять (куча аудио-видео кодеков и шифрование) — тоже переносится на аппаратный уровень давно.

я уже молчу, что в той же тегре вообще можно оффлоадить произвольные задачи на настоящий arm-сопроцессор.

@Obramko 9 мая 2011 в 20:08

Как по мне, имеет смысл ускорять роутинг.
У меня уже писюк за 800 баксов (или сколько там) тарабанит больше, чем тарабанила бы циска за N*1000 баксов.
А вот если туда еще и аппаратный выбор маршрутов…

@k7xx 8 мая 2011 в 21:07

хм, интересно, но практическое применение уже нашло?
например: в вебсервере или в компьютерном клубе для обработки видео посредством группы машин?
П.С. интересуюсь только ради любопытства

@ArtRoman 8 мая 2011 в 22:51

Для этого сейчас и работает cuda и прочие mpich'и. А перенос ядра, имхо, очень дорого будет стоить, надо переносить более специфичные и мелкие задачи. Например, может, работу небольших утилит, что ускорит какие-то определённые операции…

@inkvizitor68sl 8 мая 2011 в 22:39

Хм… Это ж какое раздолье будет для ноутов подобных Toshiba AC-100 )

@ArtRoman 8 мая 2011 в 22:48

Да там вроде и так тегровое видео очень многое на себе вытаскивает, чего один процессор не потянул бы.

@inkvizitor68sl 8 мая 2011 в 22:49

Под убунтой там молотит один процессор, вроде. С другой стороны, он не такой уж и слабый.

@ArtRoman 8 мая 2011 в 22:55

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

@inkvizitor68sl 8 мая 2011 в 22:56

Да ну ладно, клевая моделька. Главное понимать, что это всего-лишь большой КПК с клавиатурой. Отсутствие тачскрина через пару часов перестает беспокоить даже)
HD играется, игры летают.

@ArtRoman 8 мая 2011 в 23:04

Согласен, тем более за свою цену (у нас видел по цене меньше 6тыр).
Кстати, под убунту вроде софт даже компилить не требуется, в репозиториях я видел бинарники под armel. Вообще, как там живётся, на нестандартной архитектуре?)

@inkvizitor68sl 8 мая 2011 в 23:12

Честно — особо с ним не ковырялся. Накатил убунту, нет звука… А покупался он как замена читалке и диванного плеера… Так что накатил кастомный 2.2 с маркетом и радуюсь жизни) Иногда только добивает, что некоторые приложения самовольное переворачивают экран (особенно во время работы «мастера первого запуска»), а так — шикарнешая вещь. Но грамм 200 на батарейку я бы ей добавил на месте инженеров Toshiba. Или выпустил бы усиленные батареи… Для ноутбука он живет долго, но для мобильного устройства — непростительно мало. С выключенным экраном, включенным wifi и GSM — 12-14 часов.

@ArtRoman 8 мая 2011 в 23:13

Стоп, какие GSM? Там же вроде только 3G-комплектации… ))

@inkvizitor68sl 8 мая 2011 в 23:17

Ну я в смысле мобильную сеть вообще. 3G отключается при включении wifi, так что сказать «с включенным WiFi и 3G нельзя»
Звонить нельзя (при попытке позвонить на симку в нем отвечают, что абоненту такой сервис недоступен — что очень плохо… могли бы смски присылать «вам звонили»), смски отправляются и получаются прекрасно.

@inkvizitor68sl 8 мая 2011 в 23:19

s/при включении wifi/при подключении к беспроводной сети/
Надо бросать сидеть по ночам, уже совсем заговариваюсь.

@inkvizitor68sl 8 мая 2011 в 23:15

Ну то есть закрыть его, оставив все приложения болтаться в сети, и пойти в длительную прогулку не получится. Приходится в спящий режим отправлять (действительно 6-7 дней в нем живет), но тогда он не работает совсем)