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

Question

Я недавно сравнил некоторые физические движки для симуляции и разработки игр. Некоторые из них бесплатны, некоторые с открытым исходным кодом, некоторые коммерческие (1 даже очень коммерческий $$$$). Havok, Ode, Newton (также известный как oxNewton), Bullet, PhysX и «сырая» встроенная физика в некоторых 3D-движках.

На каком-то этапе я пришел к выводу или вопросу: Зачем мне использовать что-то кроме NVidia PhysX, если я могу использовать его потрясающую производительность (если она мне нужна) благодаря обработке на GPU? С будущими картами NVidia я могу ожидать дальнейшего улучшения независимо от обычных этапов генерации процессора. SDK бесплатен и доступен и для Linux. Конечно, это немного ограничено вендором и не является открытым исходным кодом.

Каково ваше мнение или опыт? Если бы вы начали прямо сейчас с разработки, согласились бы вы с вышесказанным?

ура

Answer 1

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

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

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

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

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

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

Удачи!

Answer 2

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

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

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

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

Answer 3

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

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 (блех ...)

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

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

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

Answer 4

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

Answer 5

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

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

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

Answer 6

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

Answer 7

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

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