Разработка для PlayStation 3 Linux

Я заинтересован в разработке программного обеспечения для консолей Sony PlayStation 3, которые содержат многоядерный процессор Cell, предназначенный для любого дистрибутива PS3-совместимого Linux.

"Один PS3 выполняет лучше, чем доступные верхние настольные компьютеры, и сравнивается с целым числом 25 узлов суперкомпьютера IBM Blue Gene . > ". ~ Графическая сетка PlayStation3

Самое главное:

Итак, для начала:

Ответы

Ответ 1

Вы можете попробовать Offload С++ из программного обеспечения Codeplay. Он обеспечивает расширенный диалект С++, который ускоряет разработку программного обеспечения на многоядерном оборудовании, таком как процессор Cell.

Инструментальная кросс-компилятор позволяет компилировать код для PS3 в Windows, который может быть полезен с учетом ограничений ресурсов (например, системной памяти) на консоли PS3 под управлением Linux, что может повлиять на время компиляции и использовать PS3 как рабочий стол неловко.

Версии компилятора и инструментов Offload С++ доступны для таргетинга на PS3 GameOS и Linux на Cell с помощью Cell BE SDK. Версия Cell Linux интегрируется с Eclipse CDT для IDE.

Отказ от ответственности: я разработчик в Codeplay.

Ответ 2

Вы также можете попробовать Ubuntu 8.10 (Intrepid Ibex). Их поддержка PS3 довольно хороша, и инструкции по установке и грубый праймер на компиляции можно найти здесь. GCC 4.3 и binutils 4.18 включают цели для Cell PPU (общая целевая PowerPC) и SPU, а также есть пакеты, доступные в репозиториях Ubuntu (например, spu-gcc, spu-g++, spu-binutils, ppu-gdb, spu-newlib, и т.д.), которые будут скомпилировать для вас двоичные файлы.

В отношении правильной среды IDE вышеупомянутые утилиты должны интегрироваться с любыми IDE (то есть KDevelop, Eclipse CDT, Code:: Blocks), если вы можете найти файлы подсветки синтаксиса (доступные для большинства популярных IDE). Также доступен Cell SDK и потенциально может обеспечить лучшую интеграцию, а пакеты доступны для RHEL 5.2 и Fedora 9 (они должны иметь возможность использовать иностранец, чтобы вытащить их в Debian/Ubuntu, но не уверены в этом).

OpenMPI - прекрасная идея, они смогли скомпилировать ее для blade-серверов Cell (здесь), поэтому я не подумайте, что это должна быть проблема. Вы также можете прокрутить свою собственную передачу сообщений, так как низкие издержки - это ключ к извлечению хорошей производительности на Ячейке (хотя я не знаю, насколько хорошо подходит OpenMPI для этого, это может быть здорово).

Ответ 3

Книга Мэтью Скарпино, Программирование Cell Processor, довольно современна и имеет много хорошей информации. Кроме того, на веб-сайте для книги есть много примеров кода, доступных для загрузки.

Был также курс MIT по параллельному программированию через процессор Cell, который имеет некоторую хорошую информацию, хотя некоторые из них устарели, а именно, он использует старую клеточную механику, где libspe предоставил свои собственные потоки. С новейшей версией библиотеки вам нужно будет получать ваши потоки из других источников (pthreads, boost, whatever), чтобы запускать параллельные программы.

Что касается OS и компилятора, я использую Yellow Dog Linux 6.1. В то же время YDL неплохо развивается, намного лучше, чем Fedora 9, хотя это, вероятно, связано с тем, что YDL поставляется с суперлегким оконным менеджером, а Fedora 9 - нет. У меня было несколько проблем с сетью, но это, скорее всего, продукт слегка странной сетевой среды, в которой у меня установлена ​​система.

После запуска и запуска YDL я затем установил пакеты sdk fedora для ячеек (это требует немного работы, поскольку установка celldk script ложно распознает YDL как RHEL, а не Fedora). У YDL есть большая часть SDK, доступная в одном из своих репозиториев пакетов, но по умолчанию не так много его устанавливают, просто компиляторы (конечно, я не понял этого, пока я уже не взломал установщик IBM, чтобы сделать правильная вещь). Я просто использую базовые компиляторы IBM (не XL).

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

Ответ 4

Помните, что при запуске кода в SPE их специального дизайна размер стека по умолчанию сильно варьируется от компилятора к компилятору и может вызвать всевозможные проблемы при переполнении. Как правило, хорошей практикой является объявление большинства данных по всему миру в коде SPE и исключение стека, за исключением очень небольших распределений переменных.

Поскольку нет кеша (или... всего его кэша L2 в некотором смысле), нет реального снижения производительности для этого, и вы никогда не столкнетесь с проблемами, например, попыткой данных DMA на или с адреса памяти это уже недействительно и т.д.

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