[Question] How to get NVIDIA's "Supersonic Sled" PhysX tech-demo working with DXVK-NVAPI on Linux? about dxvk-nvapi HOT 5 CLOSED

@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 👍

from dxvk-nvapi.

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...

from dxvk-nvapi.

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

No, that only means that before f2e8ed9 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 🙁
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.

from dxvk-nvapi.

@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 😄

from dxvk-nvapi.

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

from dxvk-nvapi.