Доброе время суток. Меня интересует встречал ли кто бесплатный (ну или условно-бесплатный) мультипроцессор для ПЛИС со следующими характеристиками:
1) Исходники на VHDL
2) поддержка плавающей точки
3) компилятор хотя бы какой-нибудь, хоть с чего-нибудь

Собственно, обычные процессоры для ПЛИС не устраивают тем, что на них очень неэффективно будут выполняться операции, в которых велика длинна конвейера.
В то же время, длинна конвейера для мультипроцессора абсолютно неважна (т.к. он одновременно выполняет множество потоков и зависимости по данным нет).
Я подумал, что наверняка должны быть такие, но сам пока не нашел.

Спасибо!

Не встречал.
Считаю, что из трех понятий - ПЛИС, плавающая_точка и производительность- одно лишнее.
В некоторых специальных случаях, бывают исключения.
Но чтобы победить конкурентов по цене, потреблению или производительности, нужна хитрая задача, 81-битные или 129-ти битные числа, а еще лучше, 21-битные. Ну и т.п. случаи, когда руками оптимизированный конвейер плотно руками же утрамбован в аккуратный квадратик, который размножен на всю микросхему.

Потому и не кусают (С)

opensparc t1, t2?

О, похоже на то что нужно, спасибо! Буду изучать.

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

Ух, если честно, OpenSPARC меня немного напугал. Очень уж там много всего и тулзы совершенно незнакомые используются...документация просто гигантская.
Я такое наверное не потяну, буду искать чего-нибудь попроще. Да и 50Mhz на Virtex5 как-то не очень впечатляют.

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

Ну вообще то что я делаю с FPGA - это больше академический интерес. Я хотел бы включить это в свой диссер.
Хочу сделать процессор для рейтрейсинга) Суть идеи в том, что можно было бы большую часть функциональности реализовать программно, а то, что занимает много времени - аппаратно, в виде отдельных юнитов.
Вообще я думаю что так можно было бы ускорять не только рейтрейсинг.

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

Мультипроцессор с эффективными операциями FPU мне нужен потому что помимо подсчета пересечений остальные вычисления тоже довольно тяжелые.
Если процессор держит на себе скажем 16 потоков одновременно то даже если длинна конвейера 16, то никаих хазардов не будет и перформанс будет 100 MFlops на 100Mhz именно из-за того, что нет зависимостей по данным.
Если я буду использовать Nios 2 то во-первых, производительность окажется совсем на нуле, а во-вторых мое сравнение будет не совсем верным.
Чтобы процессор не простаивал во время подсчета пересечений мне нужно как можно больше потоков на него повесить. Просто одно поточный CPU это не совсем не то что мне нужно.
Я хотел бы показать, насколько можно поднять перформанс в трассировке лучей, добавив спец. фукнц. юниты. То есть я буду сравнивать производительность просто мультипроцессора без этого юнита и с ним.

Но вообще чем больше времени я на это трачу тем больше понимаю, что затея не очень удачная.
Собственно я пока-что делаю свой мультипроцессор, но замучался) Подумал, что может лучше поискать на стороне.

>Но вообще чем больше времени я на это трачу тем больше понимаю, что затея не очень удачная.
>Собственно я пока-что делаю свой мультипроцессор, но замучался) Подумал, что может лучше поискать на стороне

Нормальная, нормальная затея.

Будем считать, что чистая производительность синтезируемых в микросхеме FPU вам подходит.
Пусть этих FPU 100-200 шт.

Оборачиваем каждый FPU триггерами и блоками памяти для подачи данных и снятия результата. Это будет процессор. Считаем, что процессор будет специализированным и что "программу" можно реализовать аппаратно.
Соединяем процессоры древовидной или кольцевой шиной, возможно, с переходом на пониженную частоту.
Получаем мультипроцессор, что-то вроде GPU. С мультипроцессорами работаем из корневого узла шины

Дополнительные компоненты процессора и шины должны быть на уровне 10-20% от ресурсов FPU.
Иначе перформанс вряд ли получится впечатляющим.

Ну это в идеале наверное, да. Я так далеко не смотрю пока)

>Ну это в идеале наверное, да. Я так далеко не смотрю пока)

Я думал, вы Nvidiю хотите побить.

У простого мультпроцессора код килобайт на 100 в в верилоге. Если FPU взять из ядер (Xilinx?), своего кода совсем мало будет.

Альтера у меня, циклон 4. Ну да, собственно FPU я возьму из библиотек. Проблемма не в количестве кода а в том, что это все нужно отладить, чтоб работало.

http://opencores.org/project,theia_gpu

Ух-ты здорово, жалко только что верилог)

там же на опенкорах и опенриск есть, но он тоже на верилоге и 1 ядро.
но зато есть всё остальное гцц4.5.1, ждб и фпу.

это не совсем так, у него есть механизм Custom Instruction. если к этому добавить самописный FPU с поддержкой SIMD (а можно и несколько), то производительность можно получить очень даже ничего. я не знаком с рейтрейсингом, приведу другой пример. допустим при обработке сигнала активно используется FFT. можно пойти по пути создания монстра а-ля спарк, а реализацию оставить программной. а можно прикрутить к ниосу корку FFT с подходящей оберткой, DMA и т.п. думаю, понятно, кто кого уделает.

Тут уже искали? => TMS320C6678.

http://www.gaisler.com/ - LEON3. Имеется в наличии FPU, "многоядерность", и прочие вкусности.
На Spartan3A, при частоте генератора 125 МГц, частота ядра составляла более 40 МГц.

В рейтрейсинге много зависимых вычислений, поэтому DSP подход ИМХО не прокатит. Опять же каждый поток может пойти по своим делам, это тоже проблемма.
Но спасибо за ссылки, я думаю что на основе готового FPU мне будет легче сделать то что я хочу.

а есть какая-нибудь популярная литература по теме?

Популярная литература по теме трассировки лучей?
Ну немного есть:
http://ray-tracing.ru
http://www.fcenter.ru/online.shtml?article...are/videos/8749
http://www.devmaster.net/articles.php (искать Raytracing)
http://www.pbrt.org/

Собственно даже SSE не особо помогает в трассировке, нужно пакетами делать, а это уже сильное ограничение.
Хотя такие работы конечно-же есть и в избытке. Но на практике это страшно неудобно.

как пример, можно сделать аппаратный блок для юнит-теста и прикрутить к нему Custom Instruction (в терминах ниоса). за 1 такт смысла нет делать, надо конвейеризовать. я так понимаю, этих пересечений вагон и тележку надо посчитать?

Если применение ПЛИС не принципиально, то может Вам все это дело реализовать на CUDA?

Я имел ввиду, что в среднем за один такт будет считаться. То есть если юнит загружен работой, то по нему треугольники будут проходить со скоростью один треугольник в клок.
Я думал так сделать сначала, но плохо то, что у ниоса с плавающей точкой ахтунг. Помимо пересечений есть вообще говоря и другие вычисления. Если в результате окажется, что боттлнек просто напросто в том, что ниос неуспевает посчитать шейдинг, я получу немного не те числа при сравнении. Можно конечно еще считать шейдинг и проч. вещи. с фиксированной точкой...возможно вы правы и начать стоит именно с этого.


Это уже давно есть Интерес сделать аппаратное решение.


Боюсь DSP мне не подойдет, но все-равно спасибо.

так FPU ему можно внешний прикрутить. хотя бы тот, что на опенкорках.

Остается открытым вопрос о производительности FPU при наличии всего одного потока.
Ну вот допустим у нас 10 стадий в конвейере FPU (В альтеровской либе 12 вообще). Это ж будет латентность 10 клоков при любой зависимости.
Но вообще наверное можно попробовать забить на это и действительно сделать на ниосе.

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

Да дело даже не в частоте. Если будет 100 Mhz меня устроит. Перф не задарма, а за счет того, что мультипроцессор выполняет поочередно команды из разных потоков и зависимостей по данным нет. То есть одна команда в клок это на мультипроцессоре спокойно можно сделать, даже если это команда с плавающей точкой. А если поток один, то любая зависимость => задержка в 10 клоков => падение производительности в 10 раз.

>Остается открытым вопрос о производительности FPU при наличии всего одного потока.
>Ну вот допустим у нас 10 стадий в конвейере FPU (В альтеровской либе 12 вообще). Это ж будет латентность 10 клоков при любой зависимости.
>Но вообще наверное можно попробовать забить на это и действительно сделать на ниосе.

У вас получается действительно всего один поток и требуется готовность результата FPU через такт?

Задержка готовых FPU бывает от 2...4 до 24...48 тактов.
http://www.eecg.toronto.edu/~myrto/gpuarch-ispass2010.pdf

По моему скромному мнению,
сосредотачиваться только на арифметических операциях бессмысленно - выйдет равноудаленный от пупа вселенной конь в вакууме, ну ровно как "математики" пытаются оптимизацию софта делать, когда не хотят даже слышать как компьютер устроен.
Чем кормить-то будете свой конвейер? Верно, из памяти брать, а она во многих не топовых FPGA (что альтера, что зайлингс) отстает от DSP блоков.
Пытаться чего-то достичь в производительности, сопоставимого хоть в чем-то с процессорами общего назначения, как мне кажется, можно только на максимальных тактовых частотах и эффективном использовании всех ресурсов - даже если денег немеряно, чтобы навтыкать на плату дюжину чипов по 5-8 килобаксов, то интерконнект между ними все убьет.

В общем, как ни выкручивайся, а все равно нужно изучить и архитектуру FPGA и задачу, урезать разрядность до необходимого минимума (block floating point, например), оптимизировать задачу в целом, наложить оптимально на архитектуру, profit.
Как промежуточный вариант - сделать под эту самую задачу мега-оптимальный дизайн, но как бы программируемый.
То есть, он полностью заточен под текущую задачу (ray tracing), но без ущерба для производительности для нее этот конвейер можно применить для чего-то еще с какой получится эффективностью.
Если это не сделать, то лучше не тратить время на ерунду, сразу писать про коня в вакууме отчет или диссерт, или что там у вас, и даже не отвлекаться на реальность.

Согласен со Shtirlits, если аппаратно только вычисление какого-нибудь рейтрейсинга или еще делать - прирост в производительности скоее всего получите незаметный, постоянно процессор дергать на загрузку конвеера... По моему смысл есть аппаратно задачу решать глобальнее, с использованием DMA, например на входе - картинка, на выходе - результаты рейтрейсинга для всей картинки, без участия процессора, тогда и конвеер не простаивает, и процессор не занят

Опасаюсь, что процессор тут из-за желания использовать готовый код трассировщика, а производительность получить не выкидыванием лишних операций (например, не 80 бит, а 24; не универсальная плавающая точка, а фиксированная и т.п.), а использованием FPGA как эдакий ковёр, под который весь мусор заметается. "а тут у нас программируемая логика, на которой делается конвейер и процессор..."
Ничего не выйдет. В доступную микросхему влезет половина конвейера и будет работать на 50 MHz.
Будет грустно.
А если всё это как следует пропустить через голову, сделать аккуратную специализированную реализацию, которая на максимальных тактовых использует и память, и DSP-блоки и внешнюю память и шину к чему-оно-там-подключено, то будет все просто летать, но нафиг никому через полтора-три года не нужное.
Будет грустно.

а почему пропустили



имхо, запрос прямо идеально соответствует ЛЕОНу

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

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

Почему один? У меня потоков столько сколько пикселей на экране. Я думаю их группами по 16 выполнять.
В том то вся и идея, что какова бы ни была задержка, если потоков много, я могу латентность скрыть.
Длинна конвейера 16? => 16 потоков. 30? => 32 потока. 48? => значит будет 48 потоков. нужно просто поочередно команды из разных потоков брать.
То ест такой гипер-трединг очень высокой степени как бы.


Асболютно согласен. Это не вся работа, но надо с чего-то начать. Пока что я думаю сделать прототип а не промышленную железку. Это моя инициатива а не чья-то еще, так что отчет мне писать не для кого.


Такие работы есть, просто повторять их не имеет большого смысла.


Ну почти, но не совсем. Дело в том, что ускорители рейтрейсинга уже давно есть. И есть статьи по тому как их делали.
Я хочу сделать не просто железку которая считает пресечения, а сделать программируемый процессор. Такое решение на котором в теории можно было бы ускорить обычный C++ код, добавив к нему всего-лишь небольшой юнит описанный на VHDL.

Ну насчет LEON-а я думал. Я еще раз хочу подчеркнуть, что не мультиядерность мне нужна а многопоточность. Это немного разные вещи.
Потоки стоять не будут. Поскольку хочу сделать только прототип, то все данные я положу в память на чипе. Ничего грузить извне я не собираюсь, это должен быть только прототип.

Но вобщем я попробую наверное на обычном проце сделать, типа LEON или Nois 2. А там посмотрим.

Спасибо еще раз всем за ценные замечания!