[Question] How to get NVIDIA's "Supersonic Sled" PhysX tech-demo working with DXVK-NVAPI on Linux?

[PhysXtest]

Hello everyone!

As the title already implies, I've been trying to get the above mentioned tech-demo working on Linux via WINE-Staging & Proton to no avail.

Looking at the release notes, I saw it being mentioned once:

Fix a crash when querying NVIDIA PhysX capabilities in certain conditions. This affected e.g. the NVIDIA Supersonic Sled Demo.

Therefore, I assumed getting this thing up & running should be quite straightforward...

Anyway, has anybody around here managed to successfully run it on Linux and if so, how?

I would really appreciate a step-by-step tutorial, if possible.

Thanks in advance!

PS:

I tried with the latest DXVK-NVAPI 0.6.3 on a 1650 GPU with the latest driver from the 530 series, since the release notes mentioned that the NVAPI headers had been updated up to that version only, which I presume means that it doesn't work yet with the 535 driver series, right?

[Saancreed]

which I presume means that it doesn't work yet with the 535 driver series, right?

No, that only means that before f2e8ed9c8d193bbb8b1c516cd30287bf69516011 we were unable to implement any new functionality that came with NVAPI in 535 driver release, everything we already implemented works on 535 drivers and it should work with any future driver as well.

Otherwise, from what I can tell this demo:

1. Loads NVAPI
2. Calls NvAPI_DISP_GetGDIPrimaryDisplayId
3. Tries to call NvAPI_Mosaic_GetDisplayViewportsByResolution but Mosaic is not active
4. Loads CUDA, a few times for good measure
5. Calls NvAPI_SYS_GetDriverAndBranchVersion
6. Tries to call NvAPI_GPU_CudaEnumComputeCapableGpus which we reject with Incompatible struct version for reasons mentioned in #127 and apparently this matches Windows behavior
7. Tries to call function with ID 0x36e39e6b which afaik is NvAPI_CUDA_EnumComputeCapableByTopology which is not implemented in dxvk-nvapi and it's unlikely it will ever be :slightly_frowning_face:
8. Proceeds to create a CUDA context and attempts to load a fat cubin using cuModuleLoadFatBinary which (at least on my machine) segfaults in native libcuda.so

The process boils down to: get Wine and Winetricks, make a Wine prefix, install DXVK, install DXVK-NVAPI, install nvcuda from nvidia-libs, winetricks -q d3dcompiler_43 physx, install demo, try to launch demo. Unless CUDA calls succeed on your machine, this probably isn't something I can help you with, sorry. But maybe @SveSop has a better idea about what's going on.

[SveSop]

@PhysXtest I actually had this demo running with nvapi/nvcuda a while back (atleast 1+ years), but have not tried it quite a long time. I will take a dig at what might be happening and see if i can come up with something clever, but i somewhat MAY fear that it could be driver related of sorts (eg. too new driver perhaps?), as this demo is quite old... but will do a windows/wine comparison and see what comes up.

Please have some patience tho, as i will most likely be away this whole week and have no way to do testing... just so you know 😄

[SveSop]

Well, i think i might need to thrown an CUDA_ERROR_NO_BINARY_FOR_GPU or something for this cuModuleLoadFatBinary function.

The documentation is not really helping:

> There is currently no documented API for constructing and using fat binary objects by programmers, and therefore this function is an internal function in this version of CUDA

It might very well be that using this under Wine, the Linux lib (that we relay to) would expect some sort of ELF "fat binary" (ie. when compiled as such with NVCC), and that i cant just relay the call untouched, since Sonic Sled would most likely have these "fat binaries" compiled as something else. I will look around and see if i can find some sort of sample that uses this thingy perhaps.

EDIT:

The pointer represents a fat binary object, which is a collection of different cubin and/or PTX files, all representing the same device code, but compiled and optimized for different architectures.

The "architectures" here is not ELF/PE, but rather "compute architecture" (eg. --gpu-architecture=compute_50) from what i gather... so this should to my knowledge not really depend on anything but the GPU architecture....

Changing this to CUDA_ERROR_NO_BINARY_FOR_GPU makes the demo load a lot further, but eventually crashes anyway, but i am not really able to figure out on what. (Seemingly in the middle of some tls_callback process or whatnot). Now.. i have had longer/shorter runs depending on wine version - 7.12 vs. 8.12 and such, so i do not immediately trust that this final crash is NVAPI/CUDA related.

I did however notice that revering the above mentioned commit to NvAPI_GPU_CudaEnumComputeCapableGpus will make it crash almost immediately for some reason 😮

Will do some more fiddling around with it and see what comes up...

[SveSop]

@PhysXtest So.. with all things wine, its a bit of a tweak experience. Disabled the call to cuModuleLoadFatBinary in nvcuda for now (nvidia-libs is updated with this - you can grab the latest pre-compile here https://github.com/SveSop/nvidia-libs/actions) since this causes a crash. Not sure why, because this is a very old function that i have not touched and i think it did used to work.. but well. Will see if something broke by doing this, or maybe find a different workaround in the future.

So.. tested with wine-staging-8.13 (Ubuntu WineHQ precompiled binaries) with the following setup in a fresh WINEPREFIX:

DXVK (from GIT) DXVK-NVAPI (from GIT) nvcuda (from nvidia-libs repo) winetricks physx directshow wmp11

This will make the demo run, although running using wine-8 vs. wine-7 i got a popup saying "supersonicsled.exe" is not respondning Just be patient and let it continue. Seems to be some sort of timeout causing Linux to think the app is hanging. I also noticed i got a pagefault, but did not investigate more to where. I did not test the audio as i do not have any speakers on my testing rig, so if you do not have audio, some additional winetricks verbs may be needed. It could be MFPlat related perhaps, but as i said - i have not verified audio.

Good luck 👍

[jp7677]

I guess this has been answered. @PhysXtest feel free to continue here if you still can't get the demo to run.