это не совсем так, у него есть механизм 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 не особо помогает в трассировке, нужно пакетами делать, а это уже сильное ограничение.
Хотя такие работы конечно-же есть и в избытке. Но на практике это страшно неудобно.

Сообщение отредактировал FROL_256 - Mar 8 2011, 13:27

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

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

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


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


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

Сообщение отредактировал FROL_256 - Mar 8 2011, 17:05

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

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

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

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

Сообщение отредактировал FROL_256 - Mar 9 2011, 10:52

>Остается открытым вопрос о производительности 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), но без ущерба для производительности для нее этот конвейер можно применить для чего-то еще с какой получится эффективностью.
Если это не сделать, то лучше не тратить время на ерунду, сразу писать про коня в вакууме отчет или диссерт, или что там у вас, и даже не отвлекаться на реальность.