Совет, необходимый для физического движка

Вот ответ относительно выбора CUDA или OpenCL. У меня нет рекомендации по книге.

Если вы хотите запускать свою программу на наборах микросхем NVIDIA и ATI, OpenCL облегчит вашу работу. Однако вы захотите написать разные версии каждого ядра, чтобы получить хорошую производительность на каждом чипсете. Например, на картах ATI вы захотите вручную векторизовать код с использованием типов данных float4 / int4 (или согласиться с почти четырехкратным ухудшением производительности), тогда как NVIDIA лучше работает со скалярными типами данных.

Если вы ориентируетесь только на NVIDIA, то программировать на CUDA несколько удобнее.

Я бы посоветовал в первую очередь спланировать простую игру в качестве тестового примера для вашего движка. Базовая игра будет стимулировать разработку функций и API. Написание движка без четкой цели делает проект более рискованным. Хотя я согласен с тем, что nVidia и ATi следует рассматривать как отдельные цели по соображениям производительности, я бы рекомендовал вам начинать ни с того, ни с другого.

Я лично написал физический движок для Uncharted: Drake's Fortune - игры для PS3 - и я прошел тест на C ++, и когда он заработал, сделал попытку оптимизировать его для VMX, а затем поместил на SPU. Имейте в виду, я сделал лишь часть того, что хотел сделать изначально из-за нехватки времени. После этого я сделал итерацию, чтобы разделить этапы данных и сформулировать конвейер преобразований данных. Это важно, потому что современные процессоры, выполняющие нетривиальный код, будь то CPU, GPU или SPU, большую часть времени проводят в ожидании кешей. Вы должны уделять особое внимание структурам данных и конвейерно их так, чтобы у вас был небольшой рабочий набор данных на любом этапе. Например. Сначала я делаю широкую фазу, поэтому мне не нужны формы, но мне нужны ограничивающие рамки мирового пространства. Поэтому я разделил ограничивающие прямоугольники на отдельный массив и вычислил их все вместе на другом проходе, который записал их оптимальным образом. В качестве входных данных для вычисления bbox мне нужны преобразования фигур и некоторые их границы, но не обязательно все фигуры. После широкой фазы я вычисляю / обновляю sim-острова, в то же время выполняя узкую фазу, для которой мне действительно нужны формы. И так далее - я описал это с изображениями в статье Game Physics Жемчуг написал.

Думаю, я пытаюсь сказать следующие моменты:

1. Убедитесь, что у вас есть четкая цель, которая движет вашим развитием - в случае с игровым физическим движком лучше всего подойдет простая игра с продуманным дизайном.
2. Не пытайтесь оптимизировать, пока у вас не будет работающего продукта. Сначала напишите его как можно проще и быстрее и исправьте все математические ошибки. Разработайте его так, чтобы вы могли позже портировать его на CUDA, но не начинайте писать ядра CUDA, пока на экране не появятся коробки.
3. После того, как вы напишите первый проход на C ++, оптимизируйте его для ЦП: оптимизируйте его так, чтобы он не перегружал кеш, и разделите код, чтобы не было спагетти вызовов, а весь код с каждого этапа был локализован. Это поможет: а) портировать на CUDA б) портировать на OpenCL в) портировать на консоль г) сделать его достаточно быстрым д) сделать возможным отладку.
4. Во время разработки не поддавайтесь искушению заняться тем, о чем вы только что подумали, если только эта функция не является необходимой для вашей четкой цели (см. № 1) - вот почему вам нужна цель, которая направит вас к ней и позволит завершить реальный проект. . Отвлекающие факторы обычно убивают проекты без четких целей.
5. Помните, что так или иначе разработка программного обеспечения является итеративной. Это нормально, если вы сделаете набросок, а затем доработаете его. Кожа, полоскание, повторение - это мантра программиста :)

Дать совет легко. Если вы хотите что-то сделать, просто сделайте это, а мы будем сидеть сложа руки и критиковать :)