Комментарии 64
Интересно, но хотелось бы узнать какие подситемы хотят вынести в GPU, на мой взгляд, было бы не плохо если какие то инструменты вынесли на GPU, но не целые подсистемы.
s/стекером состояния/трекером состояния/. В оригенале полагаю было state tracker.
Лет через 5-7, мне кажется, в PC процессор нужен будет только за тем, чтобы загрузить BIOS ;-)
Ну как бы всё начинается с биоса…
ну как бы биос отмирает
Ничего другого на EFI кроме маков я пока не видел… Всё остальное с биосом
недавно вроде бы пробегали статьи на хабре что кто-то от биоса начинает отказываться, да и любимая всеми винда вроде бы уже поддерживает небиос =)
да еще ARMы наращивают мощности активно, оставаясь при этом довольно экономичными, жалко что мощности растут, а до адекватной оси (телефонные не в счет), которая бы использовала все аппаратные возможности, как до Плутона
да еще ARMы наращивают мощности активно, оставаясь при этом довольно экономичными, жалко что мощности растут, а до адекватной оси (телефонные не в счет), которая бы использовала все аппаратные возможности, как до Плутона
На счет ARM — с Вами кто-то не согласен www.iphones.ru/iNotes/139314 ;)
если они это сделают — будет шедевр, но на_данный_момент куча разрозненных портов Linux под разные армы с разной оптимизацией и все уже устарели, из более менее красивых щас вспомню только AlwaysInnovating — у них что то интересное на BeagleBoard, сразу несколько осей работает на стареньком TI OMAP
Под Win8 ARM поддержка заявлена, в сети даже были утёкшие билды.
вы совершенно не понимаете, что такое «поддержка ARM».
это бессмысленное словосочетание, потомучто ARM — это только набор инструкций, которым оперирует процессор.
скомпилировать бинарь под армовый процессор — это не проблема вобщемто.
проблема запуска винды на армах — в поддержке платформы… но армовое железо — это зоопарк, который не имеетобщей платформы.
виндос восемь может поддерживать какой-то конкретный (или несколько) SoC и их стандартную обвязку, но не арм вообще.
это бессмысленное словосочетание, потомучто ARM — это только набор инструкций, которым оперирует процессор.
скомпилировать бинарь под армовый процессор — это не проблема вобщемто.
проблема запуска винды на армах — в поддержке платформы… но армовое железо — это зоопарк, который не имеетобщей платформы.
виндос восемь может поддерживать какой-то конкретный (или несколько) SoC и их стандартную обвязку, но не арм вообще.
недавно вроде бы пробегали статьи на хабре что кто-то от биоса начинает отказыватьсяASUS уже вроде на своих материнках BIOS на UEFI меняет.
Я вот пишу с MSI P67A-GD65 с UEFI, особой разницы с биосом не заметил, кроме картинок и поддержки мышки. Наверно самая приятная особенность — это попробовать новую версию прошивки без собственно прошивки, но особого применения я ей не нашел, т.к. на мамке 2 модуля UEFI и при отказе первого можно загрузится со второго.
Посмотрите в сторону Coreboot. :)
Bootloader
Как бы класс задач, которые можно эффективно распараллелить на куде весь мал. А гонять непараллельные вычисления на графическом ядре это удел душевнобольных, поэтому от процессора общего назначения уйти вряд ли получится.
Ну всё к тому идёт собственно… Раз есть простаивающий ресурс, то почему-бы им не воспользоваться. А если сделать универсальный подход, да ещё и подсистемы ядра вынести то это будет бомба. Понятное дело, что проблем куча, без этого никуда.
Если резюмировать — на данный момент на GPU только шифрование/расшифровка AES, а это жалкая пара сотен строк кода, и возможно крайне незначительное ускорение (особенно если учесть что текущее ядро поддерживает аппаратное ускорение AES встроенное в некоторые современные процессоры) — совершенно не соответствующие эпичному заголовку «запуск Linux на GPU».
Все с чего-то начинается. Многие вызывающие сейчас уважение проекты в момент рождения были смешны или казались не более чем игрушкой.
тут дело немного в другом: вполне возможно использовать GPU для более широкого круга задач, но при этом нужны алгоритмы расчитанные на SIMD архитектуру, а их сейчас не так уж и много, тем более в пространстве ядра
если будут алгоритмы — то будет и смысл в разработке, сейчас же пока что пользы от поддержки GPGPU в ядре будет не очень много
если будут алгоритмы — то будет и смысл в разработке, сейчас же пока что пользы от поддержки GPGPU в ядре будет не очень много
Претензии в данном случае к заголовку alizar-style
Я вот только не могу понять, а как же безопасность — программы на CUDA могут читать и записывать память друг друга. Но если люди из nvidia изобретут защищенный режим для видеокарты, то это будет просто замечательно.
В режиме ядра?
Извините, но я не понял, к какой именно фразе относится ваш вопрос.
Защищенный режим для видеокарты не требует выделения режима ядра.
Сейчас GPU часть CUDA программ выполняется без какой-либо защиты. Любая GPU программа может записать и прочитать по любому адресу видеопамяти — на GPU никаких режимов сейчас нет. Единственное ограничение — программы разных процессов не могут исполняться одновременно. Можно пытаться строить защиту исходя из этого, но тут есть масса подводных камней. Возможно им удалось их все обойти.
Защищенный режим для видеокарты не требует выделения режима ядра.
Сейчас GPU часть CUDA программ выполняется без какой-либо защиты. Любая GPU программа может записать и прочитать по любому адресу видеопамяти — на GPU никаких режимов сейчас нет. Единственное ограничение — программы разных процессов не могут исполняться одновременно. Можно пытаться строить защиту исходя из этого, но тут есть масса подводных камней. Возможно им удалось их все обойти.
открою страшную тайну: все ядерные драйвера могут читать и писать память друг-друга.
Нельзя просто взять и запустить Linux на GPU. Нужно ещё придумать, какие специфичные вычисления внутри ядра вообще имеет смысл так запускать. Может оказаться, что таких и вовсе нет. GPU всё-таки специализированный процессор.
А я всегда почему-то считал, что все упирается как минимум в скорость переключения колец защиты… А тут оказывается для ускорения ядра надо математические действия ускорять…
Мне кажется, что будущее будет за системами на одном кристалле, когда процессор полностью интегрирован с видеоускорителем. Существующие системы с видеоускорителем находящимся внутри процессора все еще имеют разделение на два отдельных устройства в логическом уровне, пожалуй, это накладывает некоторые ограничения на возможности орагнизации совместных вычислений.
В тоже время на данный момент имеется практически 30 летний опыт разделения вычислений на два отдельных чипа, и вероятно, что будут иметь место проблема перехода на новые методики разработки ОС.
KGPU — это шаг в верном направлении но хотелось бы, чтобы он не имел жесткой привязки к конкретному производителю.
В тоже время на данный момент имеется практически 30 летний опыт разделения вычислений на два отдельных чипа, и вероятно, что будут иметь место проблема перехода на новые методики разработки ОС.
KGPU — это шаг в верном направлении но хотелось бы, чтобы он не имел жесткой привязки к конкретному производителю.
А пусть пока только nVidia, не вижу ничего страшного. Если они сделают что- то реально полезное, то конкуренция не заставит себя долго ждать. Странно было бы если они изначально на OpenCL ориентировались, т.е. вкладывали бы свои средства в разработку продукта, который на блюдечках получат бесплатно конкуренты.
>Мне кажется, что будущее будет за системами на одном кристалле, когда процессор полностью интегрирован с видеоускорителем.
в современных SoC, MCU и GPU — это как раз два разных логических устройства, хоть и в одном кристалле.
просто потому, что дизайн ARM-ядра берется (лицензируется) готовый, а дизайн GPU — делают отдельно.
в современных SoC, MCU и GPU — это как раз два разных логических устройства, хоть и в одном кристалле.
просто потому, что дизайн ARM-ядра берется (лицензируется) готовый, а дизайн GPU — делают отдельно.
НЛО прилетело и опубликовало эту надпись здесь
чего к GPU вообще привязались? в нормальных системах AES и так гоняется аппаратно.
и все остальное, что имеет смысл ускорять (куча аудио-видео кодеков и шифрование) — тоже переносится на аппаратный уровень давно.
я уже молчу, что в той же тегре вообще можно оффлоадить произвольные задачи на настоящий arm-сопроцессор.
и все остальное, что имеет смысл ускорять (куча аудио-видео кодеков и шифрование) — тоже переносится на аппаратный уровень давно.
я уже молчу, что в той же тегре вообще можно оффлоадить произвольные задачи на настоящий arm-сопроцессор.
хм, интересно, но практическое применение уже нашло?
например: в вебсервере или в компьютерном клубе для обработки видео посредством группы машин?
П.С. интересуюсь только ради любопытства
например: в вебсервере или в компьютерном клубе для обработки видео посредством группы машин?
П.С. интересуюсь только ради любопытства
Хм… Это ж какое раздолье будет для ноутов подобных Toshiba AC-100 )
Да там вроде и так тегровое видео очень многое на себе вытаскивает, чего один процессор не потянул бы.
Под убунтой там молотит один процессор, вроде. С другой стороны, он не такой уж и слабый.
Насколько я понимаю, в части железной организации там всё совсем печально, удивительно, как там хотя бы андроид стабильно работает. А уж рабочую убунту на нём считаю вообще чудом :) Хотя, если бы производитель дал дрова в исходниках, думаю, моделька пользовалась бы ещё большим спросом ))
Да ну ладно, клевая моделька. Главное понимать, что это всего-лишь большой КПК с клавиатурой. Отсутствие тачскрина через пару часов перестает беспокоить даже)
HD играется, игры летают.
HD играется, игры летают.
Согласен, тем более за свою цену (у нас видел по цене меньше 6тыр).
Кстати, под убунту вроде софт даже компилить не требуется, в репозиториях я видел бинарники под armel. Вообще, как там живётся, на нестандартной архитектуре?)
Кстати, под убунту вроде софт даже компилить не требуется, в репозиториях я видел бинарники под armel. Вообще, как там живётся, на нестандартной архитектуре?)
Честно — особо с ним не ковырялся. Накатил убунту, нет звука… А покупался он как замена читалке и диванного плеера… Так что накатил кастомный 2.2 с маркетом и радуюсь жизни) Иногда только добивает, что некоторые приложения самовольное переворачивают экран (особенно во время работы «мастера первого запуска»), а так — шикарнешая вещь. Но грамм 200 на батарейку я бы ей добавил на месте инженеров Toshiba. Или выпустил бы усиленные батареи… Для ноутбука он живет долго, но для мобильного устройства — непростительно мало. С выключенным экраном, включенным wifi и GSM — 12-14 часов.
Стоп, какие GSM? Там же вроде только 3G-комплектации… ))
Ну я в смысле мобильную сеть вообще. 3G отключается при включении wifi, так что сказать «с включенным WiFi и 3G нельзя»
Звонить нельзя (при попытке позвонить на симку в нем отвечают, что абоненту такой сервис недоступен — что очень плохо… могли бы смски присылать «вам звонили»), смски отправляются и получаются прекрасно.
Звонить нельзя (при попытке позвонить на симку в нем отвечают, что абоненту такой сервис недоступен — что очень плохо… могли бы смски присылать «вам звонили»), смски отправляются и получаются прекрасно.
Ну то есть закрыть его, оставив все приложения болтаться в сети, и пойти в длительную прогулку не получится. Приходится в спящий режим отправлять (действительно 6-7 дней в нем живет), но тогда он не работает совсем)
Хочу форк с OpenCL! Причём у OpenCL не вижу проблем с работой системы без APU/GPU. А вот у CUDA куда больше проблем.
У меня перед словом «Linux» в этой статье отображаются два квадрата — управляющие символы юникода e280 и 8be2
Лицам, заинтересованным в получении дополнительной информации о проекте KGPU для увеличения ядра Linux с помощью GPU
я уже принес с подвала корпус с кнопкой «Турбо»
Linux… Nvidia GPU… Всё уже давно сказано Торвальдсом:
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ускорение ядра Linux с помощью графического процессора GPU