PhysX для высокой производительности через GPU?

Отказ от ответственности: я никогда не использовал PhysX, мой профессиональный опыт ограничен Bullet, Newton и ODE. Из этих трех мне больше всего нравится ODE; это наиболее численно стабильный, а у двух других есть проблемы со зрелостью (полезные суставы не реализованы, разрешенные комбинации сустав/двигатель ведут себя неопределенным образом и т. д.).

В своем вопросе вы упомянули о проблеме привязки к поставщику, но стоит повторить: если вы используете PhysX в качестве единственного физического решения, люди, использующие карты AMD, не смогут запустить вашу игру (да, я знаю, что это может заставить работать, но это не официально и не поддерживается NVIDIA). Один из способов обойти это — определить механизм аварийного переключения с помощью ODE или чего-то еще в системах с картами AMD. Это работает, но удваивает нагрузку. Соблазнительно думать, что вы сможете скрыть различия между двумя движками за общим интерфейсом и один раз написать большую часть кода игровой физики, но большинство ваших трудностей с игровой физикой будет связано с особенностями вашей конкретной игры. физический движок, определяющий значения таких вещей, как контактное трение и восстановление. Эти значения не имеют согласованных значений в физических движках и (в большинстве случаев) не могут быть получены формально, так что вы застряли в поиске красивых, играбельных значений экспериментальным путем. С PhysX плюс аварийное переключение вы выполняете всю эту работу дважды.

На более высоком уровне я не думаю, что какой-либо из API-интерфейсов потоковой обработки еще полностью готов, и я бы не хотел браться за один из них, пока, по крайней мере, мы не узнаем, как реакция клиентов Intel Larrabee формирует людей. конструкции.

Не рассматривая PhysX как очевидный выбор для разработки высококлассных игр, я бы сказал, что его следует избегать, если только вы не считаете, что люди с картами AMD составляют значительную часть вашей игровой базы (крайне маловероятно), или вы иметь достаточное количество программистов и QA для тестирования двух физических движков (более правдоподобно, хотя, если ваша компания настолько богата, я слышал хорошие отзывы о Havok). Или, я думаю, если вы разработали физическую игру с такими высокими требованиями к производительности, что вас может удовлетворить только потоковая физика — но в этом случае я бы посоветовал вам создать группу и позволить закону Мура делать свое дело в течение года. или два.

Ответ на раннее обновление 2013 года: я разрабатываю для того, что я считаю большой тройкой ОС: Linux, OS X, MS. Я также разрабатываю с тремя большими физическими библиотеками: PhysX, Havok, Bullet.

Что касается PhysX, я недавно провел несколько тестов с последней версией 3.2.2 на момент написания этой статьи. На мой взгляд, nVidia действительно снизила эффективность библиотеки. Самым большим является отсутствие ускорения для твердых тел. Либ ускоряет только частицы и ткань. Даже они не взаимодействуют с обычными твердыми телами. Я совершенно озадачен тем, что nVidia делает это, поскольку у них есть огромный маркетинговый ход, продвигающий приложения с ускорением на GPU, сосредоточив внимание на научных вычислениях с большой движущей силой, являющейся моделированием физики.

Так что, хотя мои ожидания, что королем физического симулятора будут PhysX, Havok и Bullet, в таком порядке, на самом деле я вижу обратное. Bullet выпустила библиотеку 2.8.1 с выборкой поддержки OpenCL. Bullet — относительно небольшая библиотека с щедрой лицензией. Их целью является выпуск версии 3 с полностью интегрированным ускорением твердого тела OpenCL.

Часть комментариев говорит о нескольких путях кода. Мое мнение, это не слишком большая проблема. Я уже поддерживаю три ОС с минимальной поддержкой жесткого кода (по большей части многопоточность и не использую код, специфичный для ОС; используйте шаблоны C++ и std lib). То же самое и с библиотеками физики. Я использую разделяемую библиотеку и абстрагирую общий интерфейс. Это нормально, потому что физика не сильно меняется ;) Вам все равно нужно настроить среду моделирования, управлять объектами, рендерить итерации в среде, очищать, когда закончите. Остальное флеш, реализовал на досуге.

С появлением OpenCL в основных библиотеках (nVidia Cuda очень близка — см. демо-версии Bullet OpenCL) объем работы подключаемых модулей физики сократится.

Итак, начиная с нуля и занимаясь только физическим моделированием? Вы не ошибетесь с Bullet. Небольшая, гибкая лицензия (бесплатная), очень близкая к готовой к производству OpenCL, которая будет кросс-платформенной для трех больших операционных систем и решений для графических процессоров.

Удачи !

Вы можете найти это интересным:

http://www.xbitlabs.com/news/video/display/20091001171332_AMD_Nvidia_PhysX_Will_Be_Irrelevant.html

Это предвзято... по сути, это интервью с AMD... но в нем есть некоторые моменты, которые, я думаю, стоит учитывать в вашем случае.

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

Так что, если вы действительно хотите, чтобы в вашем движке использовалось аппаратное ускорение физики СЕЙЧАС, выберите Physx, но имейте в виду, что, когда решения, подобные тем, которые постулирует AMD в этой статье, станут доступны (они абсолютно будут, но они еще не здесь), вы столкнетесь с неприятным выбором:

1) перепишите свой движок для использования (вставьте название нового кроссплатформенного физического движка с аппаратным ускорением), потенциально изменяя динамику вашей игры в Плохую сторону

2) продолжать использовать только Physx, полностью игнорируя пользователей AMD

3) попытаться заставить Physx работать на графических процессорах AMD (черт...)

Помимо идеи Дэвида использовать физический движок ЦП в качестве запасного варианта (выполняя вдвое больше работы и создавая 2 движка, которые ведут себя неодинаково), единственным другим вариантом является использование чистой физики ЦП.

Однако по мере того, как такие вещи, как OpenCL, становятся мейнстримом, мы можем увидеть, как ODE/Bullet/kin начинает включать это ... IOW, если вы сейчас кодируете его с помощью ODE/Bullet/kin, вы можете (вероятно, в конечном итоге) получить ускорение GPU «бесплатно». позже (без изменений в вашем коде). Он по-прежнему будет вести себя немного иначе с версией GPU (неизбежная проблема из-за эффекта бабочки и различий в реализации с плавающей запятой), но, по крайней мере, сообщество ODE/Bullet/kind будет работать с вами, чтобы уменьшить этот разрыв. .

Вот моя рекомендация: используйте физическую библиотеку с открытым исходным кодом, которая в настоящее время использует только ЦП, и подождите, пока она начнет использовать графические процессоры через OpenCL, CUDA, потоковый язык ATI и т. д. Когда это произойдет, производительность будет стремительно расти, и вы избавь себя от головной боли.

Я использовал ODE, а теперь использую PhysX. PhysX упрощает создание сцен и (мое личное мнение) кажется более реалистичным, однако для PhysX нет адекватной документации; на самом деле почти никакой документации вообще. С другой стороны, ODE имеет открытый исходный код и содержит множество документов, учебных пособий и т. д. PS: использование ускорения графического процессора значительно помогает мне и моим коллегам; мы используем разрушение APEX и частицы PhysX.

Гипотетическая выгода от будущих карт GFX — это хорошо, но в будущем также будут выгоды от дополнительных ядер ЦП. Можете ли вы быть уверены, что в будущих картах GFX всегда будет свободная емкость для вашей физики?

Но, вероятно, лучшая причина, хотя и немного расплывчатая в данном случае, заключается в том, что производительность — это еще не все. Как и в случае с любой сторонней библиотекой, вам может потребоваться поддерживать и обновлять этот код в течение многих лет, и вы захотите убедиться, что интерфейсы разумны, документация хороша и что у нее есть возможности, которые вам нужны. требовать.

Могут быть и другие математические проблемы, такие как некоторые API, предлагающие более стабильное решение уравнений и тому подобное, но я оставлю комментарий по этому поводу эксперту.

PhysX работает с картами не от nVidia, просто не ускоряется. Оставив его в том же положении, с которого должны запускаться другие двигатели. Проблема в том, что если у вас есть физическая симуляция, которая работает только с аппаратным ускорением физики.

если весь ваш код можно массово парализовать, то дерзайте!

для всего остального графические процессоры крайне неадекватны.