Archive for the ‘Multi-Core’ tag

Recent “The Evolution of PhysX” article has unvealed the current situation with performance improvements among various PhysX SDK vesions, however, one interesting case has remained outside the coverage – performance scaling in multithreaded environments.

It is known that, while PhysX SDK 2.8 has rather limited multi-threading capabilities (mostly working on per-scene or per-compartment basis), PhysX SDK 3.x can distribute various tasks across worker threads much more effective, and thus offer better support for multi-core CPUs.

But how well does multi-threading actually work in PhysX 3 (we’ll take the latest 3.3 version)? Using the same PEEL (Physics Engine Evaluation Lab) tool to the record the performance metrics, we will try to shed the light on this question.

Preset:1080: with this preset, the settings are the following:: 1920×1080 fullscreen, duration of 60 sec, 60000 particles, heavy additional graphics load and multithreaded PhysX synchronized on the rendering.

Preset:720: with this preset, the settings are the following: 1280×720 fullscreen, duration of 60 sec, 30000 particles, moderate additional graphics load and multithreaded PhysX synchronized on the rendering.

New: PhysX built-in CPU multicore option added.

New: score submission with oZone3D.Net account.

Update: the additional graphics load option covers now the whole screen and not only the upper-right corner.

Update: revamp of the main startup dialog box (now a bit simpler to use).

Update: compiled with PhysX SDK 2.8.4.6.

Bugfix: fixed a nasty deadlock that hung FluidMark sometimes at the end the tests.

As everyone else, we have very little information about next major release of PhysX SDK – 3.0, which was rumored as complete rewrite of current SDK, full of new features and extended capabilities, currently kept under straight NDA.

Today, as answer to all the hype about PhysX and SSE instructions, Nvidia’s senior PR manager Bryan Del Rizzo has stated in interview to THINQ.co.uk website, that new SDK 3.0 will feature “a task-based approach that was developed in conjunction with [Nvidia] Apex product to add in more automatic support for multi-threading“.

In generally, SDK 3.0 will automatically take advantage of however many cores are available, or the number of cores set by the developer, and will also provide the option of a “thread pool” from which “the physics simulation can draw resources that run across all cores“. – adds THINKQ.co.uk

We will keep an eye on all SDK 3.0 traces and post new info as we’ll find it.

We’ve already did more or less detailed features overview in our FluidMark 1.2 Beta preview article (in addition, more technical details are available from original post), so this time we will just point on certain changes in release version in comparison to beta one.

Main window haven’t underwent much changes.. (click to view full picture)

.. while benchmarking process was improved, to achieve results standardization. Every benchmarking sequence now starts with so called “Warming-Up” state, to ensure that all particles are emitted on the scene. In addition, default settings are now set to 60 000 particles and one minute timed run.

Moreover, new FluidMark 1.2 is now officially approved by Nvidia. According to JeGX, FluidMark developer, NV engineers have helped with bug fixing and overall optimizations, but have not influenced development process in order to give an advantage to GeForce GPUs or penalize CPUs.

As we mentioned previously, upcoming FluidMark 1.2, next version of popular GPU PhysX testing and benchmarking application, will include support for Multi-Core CPU PhysX calculations, and overall multi-threading optimizations as well.

Jerome Guinot, FluidMark developer, was kind enough to provide us with latest beta-version of new Fluid-Mark 1.2, and we’ll try to answer finally, what is faster – GPU PhysX or properly optimized CPU PhysX.

But first, lets take a closer look at new FluidMark. (click to view full picture)

Main control panel now includes several additional options, like “Force PhysX CPU” – ability to switch between GPU and CPU PhysX, without necessity to use Nvidia Control Panel.

“Multi-core PhysX” checkbox enables all multi-threading optimizations, vital and most interesting part of new FluidMark.

“# of CPU cores” is used specify number of CPU cores dedicated to simulation (up to 32 in current version), however this option is no so transparent as it looks – increased number of cores adds additional fluid emitters to the scene (one emitter per core or two in general), and with equal number of particles, various number of emitters can affect performance.

PCGH: It could be read that your game offers an advanced physics simulation as well as a support for Nvidia’s PhysX (GPU calculated physics) can you tell us more details here? Does regular by CPU calculated physics affect visuals only or is it used for gameplay terms like enemies getting hit by shattered bits of blown-away walls and the like?

Oles Shishkovstov: Yes, the physics is tightly integrated into game-play. And your example applies as well.

PCGH: Besides PhysX support why did you decide to use Nvidia’s physics middleware instead of other physics libraries like Havok or ODE? What makes Nvidia’s SDK so suitable for your title?

Oles Shishkovstov: We’ve chosen the SDK back when it was Novodex SDK (that’s even before they became AGEIA). It was high performance and feature reach solution. Some of the reasons why we did this – they had a complete and customizable content pipeline back then, and it was important when you are writing a new engine by a relatively small team.

PCGH: What are the visual differences between physics calculated by CPU and GPU (via PhysX, OpenCL or even DX Compute)? Are there any features that players without an Nvidia card will miss? What technical features cannot be realized with the CPU as “physics calculator”?

Oles Shishkovstov: There are no visible differences as they both operate on ordinary IEEE floating point. The GPU only allows more compute heavy stuff to be simulated because they are an order of magnitude faster in data-parallel algorithms.

As for Metro2033 – the game always calculates rigid-body physics on CPU, but cloth physics, soft-body physics, fluid physics and particle physics on whatever the users have (multiple CPU cores or GPU). Users will be able to enable more compute-intensive stuff via in-game option regardless of what hardware they have.

Pay attention to last paragraph – Metro 2033 will feature true multi-core implementation of GPU PhysX content – feature that most PhysX titles are lacking currently ? We are curious to see if this will really work, and since game has already gone gold, we’ll learn that very soon.

Old PhysX fans will certanly recognize this name – Novodex Rocket (PhysX Rocket later on). This application combines two roles: demo physics playground (with large number of preliminarily created and configurable scenes, ability to change and visualize SDK parameters) and physics editor, which can export objects data to COLLADA or NxuStream.

PhysX Rocket was often used by Ageia to demonstrate SDK features and PPU computing capabilities in year 2005, and was included in SDK package as PhysX tool (till SDK 2.7.3.).

John Ratcliff, PhysX Rocket creator, has made a nice present recently – he revealed an updated legacy version of Rocket, which is based on latest PhysX SDK 2.8.3 and includes advanced UI options (unavailable in previous public versions), but is missing some vital demo scenes and object files. Fortunately, we were able to merge this updated Rocket with old one, from SDK 2.7.3 Tools – this means all demos like in regular Rocket, but SDK 2.8.3 solver and additional UI options from new one.

PhysX FluidMark is popular benchmarking application, that is often used to test stability and performance of GPU PhysX configurations. It performs PhysX SDK based SPH Fluids particle simulation, which can be calculated on CPU or compatible Nvidia GPU, however, only one CPU core can be used in first case.

After all those “Multi-Core CPU Support Is Disabled in PhysX” claims by AMD and following hype, JeGX (FluidMark developer) decided to leverage multi-threading capabilities of PhysX SDK and augment FluidMark with actual multi-core CPU support.