PHYSX NEWS PHYSX SDK
PROJECTS TABLE
GPU PHYSX
GAMES INFO
PHYSX
ARTICLES
PHYSX WIKI FORUM
РУССКИЙ ENGLISH


:: Back to news index ::

PhysX SDK 2.8.4: say goodbye to System Software

with 39 comments

nvidia-physx

Newest PhysX SDK 2.8.4.2 is ready for public beta testing – this is last and most stable current generation SDK, next one is going to be 3.0.

In addition, SDK 2.8.4. will be used as basis for upcoming APEX 1.0 toolset.

[18.08.10] Update: Release notes were supplemented with “driverless” mode description.

[19.08.10] Update #2: bug in the PhysXLoader code, that was preventing it from loading the local DLLs in 2.8.4, is now fixed. Replace the PhysXLoader.dll and PhysXLoader64.dll in your SDK installation with the new files from the archive “2.8.4_Loader_patch.rar“, found in the 2.8.4 folder on the developer download site.

[20.08.10] Update #3: PhysX SDK 2.8.4.3 with fixed PhysXLoader .dlls and included (previously missing) PhysXDevice.dll – is ready.

Currently, binary builds are available for 32- and 64-bit PC Windows, and Xbox 360

RELEASE NOTES:

General

  • Removed PhysX Loader source code from source distribution. THIS WILL BE REVERTED FOR RELEASE. PhysXLoader code will be supplied to source licensees.
  • Discontinued the Training Programs.
  • Added source code of NxTetra (tet-maker) utility to source distribution.
  • Removed spin waits from sample code.
  • Added API to permit the user to specify the order in which compartments are simulated.
  • Added compression limits to cloth.
  • Cloth simulation no longer performs prediction for kinematic rigid bodies for improved interaction behavior.
  • New driverless loader option for PC CPU distribution. In 2.8.4, application developers must ship PhysXCore.dll, PhysXCooking.dll, the cudarXX_XX_X.dll and physxdevice.dll with the application ‘locally’, in the directory where the .exe is located:

1. The application requests PhysXCore or PhysXCooking (v 2.8.4) from the PhysXLoader.

2. PhysXLoader searches for another DLL called ‘PhysXUpdateLoader’.

3. If PhysXUpdateLoader is not found, PhysXLoader will load the local PhysXCore or PhysXCooking.

4. If PhysXUpdateLoader is found, it looks for an updated replacement for the PhysXCore or PhysXCooking dlls.

5. If PhysXUpdateLoader cannot find the specified replacement DLL, PhysXLoader will load the local PhysXCore or PhysXCooking dlls.

6. If PhysXUpdateLoader can find the replacement DLLs, these will be loaded in place of the local PhysCore or PhysXCooking dlls.

7. The net result is that the developer has more control over the game installation process, doesn't have to worry about shipping a large System Software with the game, doesn't have to worry that the player will break his System Software somehow, etc.

  • Better rotation matrix input validity checking.
  • Made Desc::isValid() more verbose.
  • CUDA errors are now reported to the debug stream.
  • Added extended scene statistics for GPU memory usage.
  • Lowered the default GPU memory heap size to 32 MB from 128 MB. You may use NxPhysicsSDKDesc::gpuHeapSize to change how much GPU memory is allocated for physics.
  • Disabled GPU acceleration by default. Clear NX_SDF_NO_HARDWARE to enable it.
  • Corrected inertia and volume computation for capsule. For the same capsule dimension and density, the mass and inertia is slightly different compared to the previous release.

Performance

  • Enabled /arch:SSE2 compiler switch for all optimized PC builds.
  • Optimized PS3 SPU Memory Manager
  • Optimized AgPerfmon AgPerfUtils wrapper
  • Optimized cloth simulation on PS3, XBOX 360, PC CPU

Fixed Bugs

  • Debugged PS3 SPU Memory Manager
  • Fluids now collide properly when static shapes are removed or added.
  • Fixed crash bug in character controller sample.
  • Fixed a number of bugs in the HSM.

API changes

  • Cloth
    • NxCloth::getShapePointers() no longer returns shape flags.
    • Added methods to NxCloth and members to NxClothDesc to set compression parameters.
    • NxCloth::setFlag() can no longer be used to change NX_CLF_BENDING_ORTHO, use flag in NxClothDesc instead.
  • Fluids
    • Removed NxFluidFlag::NX_FF_ENABLE_STATIC_FRICTION. Static friction is enabled by default now.
  • Removed NX_SDKF_EXTENDED_DESCRIPTOR.
  • Added NxPhysicsSDK::resizeGpuHeap() to allow changing the GPU heap size after SDK creation. See the GPU Memory section of the User’s Guide for details.
  • NxPhysicsSDKDesc::flags has NX_SDKF_NO_HARDWARE set by default.
  • Added checkValid() method to descriptors that return an error code instead of the boolean of isValid().
  • The experimental NxScene::simulateCompartments() method has been added. It gives more control over the order in which compartments get simulated.

You can download PhysX SDK 2.8.4.2 Beta via Developer Support Center.

If you are experiencing trouble with registration of PhysX Developer account, please refer to our registration guide.

Written by Zogrim

August 16th, 2010 at 5:00 pm

Posted in PhysX Drivers, PhysX SDK

Tagged with , ,

39 Responses to 'PhysX SDK 2.8.4: say goodbye to System Software'

Subscribe to comments with RSS

  1. Hi everyone,

    First, my apologies for the confusion surrounding the ‘driverless model’ change in PhysX 2.8.4. The documentation is not current, and the release notes are too sparse. I’ll be taking steps to correct that in the coming days, as we work towards release. In the meantime I can answer some questions here.

    There are no good excuses for things like this, but then agains there are always excuses. As often happens in middleware development, we needed to get the headers and libs out the door for a few specific projects, and we faced the choice of either having a closed beta now, and postponing general availability until the docs were ready, or pushing out the beta (with old docs) to all PhysX developers . I chose the latter because there are minimal changes in functionality to 2.8.4 vs. 2.8.3 (it’s mostly an optimization and bug fix release), so most developers already using 2.8.3 won’t have a problem in the transition. The one exception is the ‘driverless model’ change, but unless there is a bug we don’t know about, nobody should really notice a problem with that while working with the beta.

    Regarding the ‘driverless model’, I’ll step back a bit and describe the overall situation, and how 2.8.4 (and PhysX-3 soon) changes that picture.

    The need for a ‘System Software’ and the PhysXLoader was driven primarily by the PhysX architecture for the old Ageia AG-1011 PPU, and was intended to provide compatibility for updated hardware running older applications. This was the ‘driver model’ for PhysX. Although our goal from the beginning was to separate the software PhysX implementation from the PPU (later GPU) implementation, in 2.x they were somewhat mixed in the PhysXCore.dll (which is the heart of the System Software) due to technical reasons that seemed insurmountable at the time. The 2.x code base hasn’t changed radically since the Nvidia acquisition, the real changes are going into PhysX-3, but we have changed things enough that we can now meet the request that we have heard many times over the years: “please, please get rid of System Software and let me load PhysXCore from my local directory.” Many developers have real difficulty with the size of the System Software (it’s grown to 75MB over the years) and with the idea of a dependency on a third-party binary component for core software compatibility (as opposed to a true ‘driver’ that only implemented GPU features).

    In 2.8.4, application developers must ship PhysXCore.dll and PhysXCooking.dll with the application (and a couple of other minor DLLs, to ensure GPU compatibility in the future). Typically this would mean that the application installer just puts those DLLs in the local directory (where the .exe is found). GPU compatibility for new hardware will be provided by a different update mechanism that can load a new core/cooking DLL from an update installation, in place of the local core/cooking DLL that shipped with the game. The PhysXLoader in 2.8.4 works like this:

    1. Application requests PhysXCore or Cooking, version 2.8.4, from the PhysXLoader.
    2. PhysXLoader looks to see if it can find ‘PhysXUpdateLoader.dll’. If it can’t find one, PhysXLoader loads the local PhysXCore/Cooking from the application directory.
    3. If PhysXUpdateLoader is present, it looks to see if there are replacement DLLs appropriate for the specific PhysXCore.dll/PhysXCooking.dll version requested. If it finds one, it will load that DLL; if it doesn’t find one, PhysXLoader will continue to load the local DLL.

    The net result is that the developer has more control over the game installation process, doesn’t have to worry about shipping a large System Software with the game, doesn’t have to worry that the player will break his System Software somehow, etc.

    We will be updating the documentation and release notes with a more complete description of this mechanism. Again, sorry for the confusion. I take your feedback seriously, please let me know what you think of the new approach.

    Thanks,
    Mike Skolones

      

    Mike Skolones

    17 Aug 10 at 6:48 pm

  2. A modular installer(ie ship an installer with just specific DLLs with the app) would have solved the problem.

    Plus perhaps less hacking of existing DLLs… So people are less nervous about having a central DLL.

    NVIDIA ship new OpenGL implimentations all the time without problem, nobody insists on having them in there own folder (which is mostly software talking to some sort of core driver).

    But I guess PhysX is not mature enough for that.

      

    David Black

    17 Aug 10 at 7:29 pm

  3. –>A modular installer(ie ship an installer with just specific DLLs with the app) would have solved the problem.

    That’s more or less what the current situation is. The specific DLLs go with the app. There’s no need for us to package it into a separate installer, although if there is enough demand for that, we’ll consider it.

    –>NVIDIA ship new OpenGL implimentations all the time without problem, nobody insists on having them in there own folder

    Some developers have indeed insisted to us that the DLLs should be local. You are right, PhysX is nowhere near the maturity of OpenGL, and indeed is fundamentally a different type of produc. Much of the PhysX implementation is software running on the CPU, it is not a thin layer on a core driver. Because of the importance of the software components, developers look at it differently than they do with OpenGL, and have told us many times that they would like the additional control of being able to ship with local DLLs.

      

    Mike Skolones

    17 Aug 10 at 7:57 pm

  4. Hey, Mike, thanks for explanation :)
    That really does make sence.

      

    Zogrim

    17 Aug 10 at 8:39 pm

  5. >>>–>A modular installer(ie ship an installer with just specific DLLs with the app) would have solved the problem.

    That’s more or less what the current situation is. The specific DLLs go with the app. There’s no need for us to package it into a separate installer, although if there is enough demand for that, we’ll consider it.
    <<<

    Hmm, not sure if we are talking about something different.

    What I meant was that you basically have the same system software installer as now, which installs to a central location. However the installer is not one big file, but a bunch of files for each version. The developer can choose to delete the .msi file for versions of PhysX they dont need if they are short on space.

    "Some developers have indeed insisted to us that the DLLs should be local. You are right, PhysX is nowhere near the maturity of OpenGL, and indeed is fundamentally a different type of produc. Much of the PhysX implementation is software running on the CPU, it is not a thin layer on a core driver. Because of the importance of the software components, developers look at it differently than they do with OpenGL, and have told us many times that they would like the additional control of being able to ship with local DLLs."

    I am not sure about the distinction, it is all software. If it is running on the GPU "CUDA" cores or the CPU should be irrelevant.

    The OpenGL driver includes a lot of complicated (presumably) CPU code, for example shader compilers. In addition(like PhysX) it probably has a bunch of PTX/CUDA code for emulating fixed function parts of the graphics pipeline.

    I think developers look at it differently because changes, at least are not seen to, go through such a thourough review and testing process. ie the ARB or similar internal procedures. (this of course has negative aspects as well).

      

    David Black

    17 Aug 10 at 9:22 pm

  6. Yes, I take your point that in many ways PhysX and OpenGL are similar, and could work with similar distribution models. However there is a big difference, as you point out, in that PhysX changes quickly without going through a process as rigorous as the OpenGL ARB; changes are often made in response to individual developer requests for specific projects, and are pushed out several times per year. Many game developers have indicated to us that they would like more flexibility with the physics implementation, because they are accustomed to writing their own physics systems and they think that physics requirements are more volatile than requirements for OpenGL.

    I’m certain that whether we chose to continue to provide core dlls through a central installation, or chose to ship them locally with applications, some people will rejoice and others will complain. I think that the number of developers impacted negatively by the old system is far greater than those who will be negatively impacted by having to ship a local dll.

    The system will be cleaner in PhysX-3 than it is in 2.8.4. The latter is a compromise between wanting to ‘go driverless’ and the need to avoid ripping apart the 2.x code base that much.

    On to another topic…I was just doing more testing on the beta installer, and I find that a certain file, PhysXDevice.dll, seems to be missing from the 32-bit installation. This could cause some problems for people who don’t already have system software installed for 2.8.3 work, we will fix it for the release of course.

      

    Mike Skolones

    17 Aug 10 at 10:01 pm

  7. David Black
    What I meant was that you basically have the same
    system software installer as now, which installs to a central location

    Don’t think another PSS (or PSS at all) is good idea.
    Take CPU PhysX SDK based games – you can find users with PhysX drivers problems for almost every single title:
    Mass Effect 2
    Dragon Age
    Metro 2033
    NFS Shift
    etc, etc.. ever heard of such problems with games on Havok ? Bullet ? ODE ? Newton ? Nope

    Devs are switching from PhysX SDK because of don’t like “admin requirement on installation (as PhysX system software required this), and don’t want to “worry about any PhysX driver conflicts”

    In Ageia times, some guys were hacking PhysXLoader just to get rid of the System Software

    So from my point, “going driverless” is the right way

      

    Zogrim

    17 Aug 10 at 10:52 pm

  8. I am not against a driverless model in general.

    It is just a trade off between NVIDIA spending the (considerable) amount of time and money making PhysX unconditionally stable so we dont get such problems, ever. eg driver level quality control, like they apply to the OpenGL driver.

    vs

    The ability to innovate quickly and possibly pander to the whims of the big games companies. (hopefully not to much quality is lost through introducing backdoors and other hacks).

    I prefer the first, from a selfish perspective, but then I dont have to foot the bill and I am unlikely to be able to keep pace with the state of the art for my hoby projects anyway…

      

    David Black

    17 Aug 10 at 11:25 pm

  9. If you download the 2.8.4 beta and have difficulty with samples not running using the local DLL, it’s because there was a bug in PhysXLoader. You’ll find a file “284_Loader_patch.rar” on the PhysX developer support download page 284, alongside the SDK installer. Replace the PhysXLoader dll’s in the SDK installation (e.g. \Program Files (x86)\NVIDIA Corporation\NVIDIA PhysX SDK\v2.8.4_win\Bin\win32\PhysXLoader.dll) with the appropriate file from the .rar.

      

    Mike Skolones

    19 Aug 10 at 3:03 am

  10. Maybe you could add some info to the relase notes about using the checked builds and how they can help debugging? Since they look like they might be useable with this release.

      

    David Black

    19 Aug 10 at 2:44 pm

  11. Sure, I’ll put that on the list, thanks.

      

    Mike Skolones

    19 Aug 10 at 6:41 pm

  12. Sure, I’ll put that on the list, thanks
    Nice to see you’re paying more attention to the community ;)

    BTW, how exactly CPU cloth was optimized ? cause I’m noticing significant performance gain over 2.8.3 – won’t that result in less stability or quality of simulation ?

      

    Zogrim

    19 Aug 10 at 7:09 pm

  13. How were you measuring the cloth performance?

      

    David Black

    19 Aug 10 at 7:12 pm

  14. How were you measuring the cloth performance?
    Using the only way available to me – running SampleCloth with disabled vsync

      

    Zogrim

    19 Aug 10 at 7:22 pm

  15. Hmm, I get the impression that the workloads in the samples are too small to measure in at all a realistic way. (ie thousands of fps, with fixed overheads dominating).

    What would be great is if there was a cloth sample with a more intensive workload(eg clothing), in particular something demonstraiting the new(ish) constraint mechanism.

      

    David Black

    19 Aug 10 at 8:50 pm

  16. Awesome news, I’ll have to get started adding these changes into PhysX.Net :)

      

    StillDesign

    21 Aug 10 at 3:13 am

  17. StillDesign
    Would be great, cause you haven’t updated it even with 2.8.3 ;)

      

    Zogrim

    21 Aug 10 at 8:04 pm

  18. Works like a charm here..thanks a lot

      

    baune

    30 Aug 10 at 9:26 pm

  19. Hi, I need to work with the 2.8 branch ‘deformables’ (soft body) and would like to download the latest 2.8.4.3 SDK.

    I have google over an hour and I can’t find it on the Internet or as a registered developer.

    Where can I find it??

    Thanks!

      

    Daniel

    9 Sep 12 at 8:58 am


Leave a Reply

*
Copyright © 2009-2014. PhysXInfo.com | About PhysXInfo.com project | Privacy Policy
PhysX is trademark of NVIDIA Corporation