В настоящее время я использую raytracer. Поскольку raytracing чрезвычайно усложняется, и поскольку я все равно буду изучать программирование CUDA, мне было интересно, есть ли у кого-нибудь опыт объединения этих двух. Я не могу сказать, соответствуют ли вычислительные модели, и я хотел бы знать, чего ожидать. У меня создается впечатление, что это не совсем совпадение на небесах, но приличное повышение скорости было бы лучше, чем ничего.raytracing with CUDA
В CUDA очень опасно то, что расходящийся поток управления в вашем коде ядра абсолютно соответствует производительности KILLS из-за структуры базового оборудования графического процессора. Графические процессоры обычно имеют массивные параллельные рабочие нагрузки с высококогерентным потоком управления (т. Е. У вас есть несколько миллионов пикселей, каждый из которых (или, по крайней мере, с большими рядами которых) будет работать с точной точной шейдерной программой, даже принимая одно и то же направление через все ветви, что позволяет им сделать некоторые аппаратные оптимизации, например, только иметь один кеш инструкции, модуль выборки и декодировать логику для каждой группы из 32 потоков. В идеальном случае, который является общим в графике, они может транслировать одну и ту же инструкцию для всех 32 наборов исполнительных блоков в одном цикле (это называется SIMD или Single-Instruction Multiple-Data). Они могут эмулировать MIMD (несколько инструкций) и SPMD (однопрограммный) , но когда потоки внутри потокового мультипроцессора (SM) расходятся (берут разные пути кода из ветви), логика проблемы фактически переключается между каждым кодовым контуром на по циклам. Вы можете себе представить, что в худшем случае, когда все потоки находятся на разных путях, ваше использование аппаратного обеспечения просто снизилось в 32 раза, эффективно уничтожив любое преимущество, которое у вас было бы, выполнив на GPU процессор, особенно учитывая накладные расходы, связанные с сортировкой набора данных от CPU, через PCIe, до графического процессора.
Это говорит о том, что трассировка лучей, хотя и в некотором смысле параллельная данным, имеет широко расходящийся поток управления для даже скромно сложных сцен. Даже если вам удастся сопоставить кучу плотно расставленных лучей, которые вы выбрасываете рядом друг с другом на один и тот же SM, данные и местоположение инструкции, которые вы имеете для первоначального отскока, не будут сохраняться очень долго. Например, представьте себе все 32 высококогерентных луча, отскакивающих от сферы.После этого отскока все они пройдут в совершенно разных направлениях и, вероятно, ударят по предметам из разных материалов, с различными условиями освещения и т. Д. Каждый материал и набор условий освещения, окклюзии и т. Д. Имеет свой собственный поток команд, связанный с ним (для вычисления рефракции, отражения, поглощения и т. Д.), И поэтому становится довольно сложно запускать один и тот же поток команд даже на значительную долю нитей в SM. Эта проблема, с современным уровнем качества в коде трассировки лучей, снижает коэффициент использования графического процессора в 16-32 раза, что может сделать производительность неприемлемой для вашего приложения, особенно если это в режиме реального времени (например, игра). Он по-прежнему может быть выше CPU, например. ферму рендеринга.
В настоящее время в исследовательском сообществе рассматривается новый класс ускорителей MIMD или SPMD. Я бы рассматривал их как логические платформы для программного обеспечения, в режиме реального времени raytracing.
Если вас интересуют используемые алгоритмы и их сопоставление с кодом, проверьте POVRay. Также посмотрите на картирование фотонов, это интересная техника, которая даже приближается на один шаг к представлению физической реальности, чем трассировка лучей.
Это, безусловно, можно сделать, было сделано и является горячей темой, которая в настоящее время относится к гуру raytracing и Cuda. Я бы начал с просмотра http://www.nvidia.com/object/cuda_home.html
Но это в основном проблема исследований. Люди, которые делают это хорошо, получают из него рецензируемые научные исследования. Но скважина в этом пункте по-прежнему означает, что лучшие результаты GPU/Cuda являются приблизительно конкурентоспособными с лучшими в своем классе решениями для CPU/multi-core/SSE. Поэтому я думаю, что немного рано предполагать, что использование Cuda ускорит трассировку лучей. Проблема заключается в том, что хотя трассировка лучей «смущающая параллель» (как говорится), это не проблема «фиксированного ввода и вывода», которая напрямую сопоставляется с графическими процессорами - вам нужны деревья, стеки, динамические структуры данных и т. Д. Это можно сделать с помощью Cuda/GPU, но это сложно.
Ваш вопрос был не совсем понятен в отношении вашего уровня опыта или целей вашего проекта. Если это ваш первый лучевой трассировщик, и вы просто пытаетесь учиться, я бы избежал Куды - вам понадобится 10 раз больше времени на разработку, и вы, вероятно, не добьетесь хорошей скорости. Если вы умеренно опытный программист Cuda и ищете сложный проект, а трассировка лучей - это просто забавная вещь, чтобы научиться, во что бы то ни стало попытаться сделать это в Cuda. Если вы делаете коммерческое приложение, и вы хотите получить конкурентную скорость - ну, это, наверное, дерьмовый выстрел в этот момент ... вы можете получить преимущество в производительности, но за счет более сложного развития и зависимость от конкретного оборудования.
Вернитесь через год, ответ может отличаться после другого поколения или двух из GPU-скорости, разработки компилятора Cuda и опыта сообщества исследователей.
Nvidia продемонстрировала луч-трассировщик в CUDA на своей конференции NVision в этом году. Вот ссылка на их слайды об этом.
Большое спасибо, это действительно интересный материал! – 2008-09-30 09:02:12
Просто указатель на my open-source, portable (Windows/Linux) GPL implementation of a CUDA raytracer.
У меня есть небольшой проект, строящий мой первый raytracer, и я никогда не делал никаких работ CUDA, поэтому я вхожу в плохое положение, чтобы сделать что-то отличное, но в течение следующего года я работаю с технологией GPGPU. Это заставляет меня познакомиться с CUDA, и мне было интересно, в какой мере я могу использовать это знание. – 2008-09-19 15:42:24
Вы уверены, что это неловко параллельная проблема? Решение найти следующий объект отражения и вариации в обработке материалов (как указывает Мэтт Дж), похоже, что они могут сильно нарушить параллелизм. Но, пожалуйста, поправьте меня, если я ошибаюсь. – 2013-08-27 22:08:20