Daz Studio lacks some NvAPI methods for iRay rendering #64
Comments
|
Could you please describe what do you mean with “broke”? Do you get an actual error message or anything that might hint what that application is missing? Did you also tried to spoof an AMD card in DXVK? The DXVK logs should tell you the effective setting. Looking at the logs itself, I would say the application handles the missing methods just fine and the actual issue is somewhere else. |
|
Hello, It may be better with some logs After re-reading the logs, I’m not as sure as before… There is a cuda error. |
|
Looking at those logs, I think this is the actual error:
|
|
Yeah, that seems more like it. Although, that’s strange how it finds only a "0.0" version, and not an actual version of cuda. |
|
Yeah, I agree, also looking at https://github.com/SveSop/nvidia-libs/blob/master/dlls/nvcuda/nvcuda.c#L1031 (not the actual wine staging source, that is here https://github.com/wine-staging/wine-staging/tree/master/patches/nvcuda-CUDA_Support), the driver version call is just passed through, so the question is indeed how that application determines the cuda version. |
|
Could you take a look at wine logs with enabled nvcuda channel (and loaddll? This should give an indication if cuda is loaded at all. |
|
Yep, I’ve tried looking at the actual version, but I’ve a hard time reading C++ + patch notes + I don’t understand how it works. Here is the log. I found an error while importing nvcuda and nvcuvid: But I need to make sure there isn’t any dll from all my tries and retries! |
|
Mmh, may be it is an idea to stub EnumTCCPhysicalGPUs in dxvk-nvapi, since this is related to cuda, I can take a look tomorrow. |
Thanks. Do you actually have nvcuda in your wine environment? I think you can use GPU Caps Viewer in you prefix to get some info about cuda. |
|
Sorry, I think I need to do a clean setup of Daz, because I might have a bit messed-up my environment 😅 Just a few minutes |
|
Ok, got it! Now it loads, also I looked into the Daz log and found this: Obviously, I had fucked up my wine prefix 😬 I guess it showed "0.0" because there was some formatting around the get version function. But it still won’t work, sadly :( |
|
Ok, maybe we did all this just to be stuck at the same point we were before. According to Cuda-z, the runtime dll version is 6.5, which means a dinosaur.
Well, still, thank you very much! It was really kind of you to help me. |
|
@PetitMote That 6.50 you see in your screenshot is just the version of the library CUDA-Z was linked to (obtained using Fwiw this is what CUDA-Z says on my machine, on the left is the Linux version and on the right is the Windows one running in Wine.
|
|
Hello again, |
Actually there is, which is why we can see the following in the log: But it's not enough to tell if Wine has all the stuff Daz Studio needs. I think implementing |
|
Ok, thank you. There isn’t, by any chance, a nvapi channel ? (here is a log with only nvcuda) Also, I tried installing Nvidia Runtime and replacing cudart dll from Daz Studio by the one from nvidia (well, I tried something), but it changed absolutely nothing. |
There is, but it will only function with Wine Staging's nvapi implementation. When it comes to DXVK-NVAPI, I think we have all the logs we need for now. As the last resort, you could try reporting this as a Wine Staging bug to WineHQ, but when doing so, make sure you are not using DXVK nor DXVK-NVAPI and your build of Wine has no custom patches other than Staging itself (so nvapi comes from Wine Staging), but if the application really needs nvapi to work then I expect it to give up even earlier than it does now. Just something to consider if we can't figure out what exactly does it need, maybe Wine wizards will be able to help in this case. |
|
I’ve tried, and I do think it’s worse. According the logs, my GPU is reported as an AMD GPU, therefore it doesn’t event try to load Cuda on it, and it doesn’t appear in the render settings. (didn’t say it before, but my GPU appears as "CUDA 4294967295" in Daz, even if I’m not sure that the number doesn’t change) As we can see in wine logs, it reports the GPU as AMD, and in DazStudio at 2022-01-05 11:18:33.584 there isn’t any GPU: Does this mean it could be caused by the nvapi? Also, I’ve already filed a bug report on Wine, they told there is a new cuda version coming in the next wine-staging release. |
|
@PetitMote Could you please test with the binaries from #65 ? Edit: The build container for building on GitHub don't want to come up (probably upstream arch issue, will certainly be fixed soon). Let me know if I should provide binaries here. |
|
Hello, I’ve tried without and with the patch. Here are the dxnvk-nvapi logs. We still get problems about unimplemented methods. |
|
I’ve checked the Daz logs, and it doesn’t impact the issue, still get the: At least with dxvk-nvapi it tries, because it won’t bother with wine-staging nvapi. |
|
Thanks, I've added implementations with hard-coded values for the still missing methods. Lets hope that the app wanting more entry points stops at some point :) |
|
Hello again! Do you know if these 2 errors might cause an issue? |
|
As far as I know those two are entry points for debugging, it would be very weird if the app depends on it. I also don’t think that the last missing entry point is an actual issue. So bottom line I guess is, that the cuda issue is unfortunately not related to dxvk-nvapi*. I guess waiting for the updated cuda wine-staging patch set is probably your best bet for now. Please let me know if that makes a difference.
|
|
I can’t find any information on this 2 method indexes, nvapi doc is either absent or very poorly referenced. I’ve already tried the patched wine-staging, and it changed nothing. I’ll try to get more information. I’ll keep you updated, if you want :) Well, anyway, thank you very very much. I greatly appreciated your help! I don’t think I can be very useful, but if I can be of any help, I’m available! (Well, to be precise, there is still this weird issue. Your last updates did improve the information in this, but some are still lacking.) |
|
Yeah, CUDA device ID and compute capabilities doesn’t look correct. Though unfortunately dunno where those are coming from. Likely this is the result of a failed cuda initialization for the application. That said, as Saancreed already said above, looking at you nvcuda wine trace from above. this looks actually good: Edit: looking again at the DAZ logs, Edit2: Is |
|
Hello, The theory we have on the wine issue is that cudart, the Cuda Runtime library, is only a toolkit to be used by developpers, and makes calls to nvcuda. That seems logical given the fact that installing cuda on Linux gives only the libcuda.so, and you need to install cuda-toolkit to have a cudart version, but not in /usr/lib, only in /opt/cuda. Also, by watching the logs, I saw this: What’s interesting is that the Dllmain have a (nil) instead of the device id (should be 0). But mostly, we can see the calls to nvcuda, and the fact that it tries multiple times to call cuInit before saying there is an error. I’m investigating this. Edit: So, I tried a little modification that did nothing (the parameter wasn’t name after the documentation) Now that I think of it, this message is concerning: But I can’t make sens of the code it implies. |
I think we better off by discussing here rather than on bugzilla, cos the wine devs are not really too interested in off-projects like dxvk-nvapi. The function you ask about here is somewhat of a "mystery" when looking at the code, and is named "Unknown1" for a reason. I have experimented a bit with this before without getting much wiser about it.. but my guess is that this is ALSO some unknown stuff (nVidia NDA) in Cuda in the same manner loads of stuff is in nvapi. nvcuda does not log calls "that does not exist" in the same manner as nvapi will throw a "unknown function" in the logs if an app tries to use something not there, hence the latest addition to staging nvcuda made DAZ crash on the two functions i added in my posted patch. I think it MAY be more stuff needing to be added, so i will look into seeing if i can add some stub's from Cuda 11 maybe, and see if it crashes on something more. Adding stubs has its drawbacks, since just adding a lot of them WILL make things crash (as we proved it did)... but the upside is that we can figure out what function it crashes on. Adding MOST of the "relay" functions (i like to call them that) is kinda trivial, even tho it takes some time to do it. Some relay functions requires additional stuff tho, especially if the case is different uuid's between dxvk's DXGI vs. Linux native -> Linux libcuda. This requires some additional testing i guess. So, in the meantime we can keep testing and suggesting patches here instead of cluttering bugzilla, since the issue will be dropped rather fast by the winehq dev's once we start commenting dxvk-nvapi there i think. If we get this solved i will consider suggesting a staging patch for nvapi, since it lacks a couple of the calls needed for this to work with staging version of nvapi. |
|
Thank you, As you say, it is very long (and boring). I’m still looking over cuda.h |
|
I think the current status of nvapi seems "ok", but the problem is that staging implementation of nvapi will not get us this far when it comes to using DAZ. So, if we keep posting new issues with nvcuda on bugzilla without any reliable "this works", there is no way for the WineHQ devs to test perhaps. @jp7677 |
|
Oki, i have submitted what i believe would cover some licensing in my working branch here https://github.com/SveSop/wine-nvoptix/tree/working-version @Saancreed @PetitMote Can you check it out and see if anything seems missing or should be changed? The .c source files i kinda feel should be appropriate to just use the MIT license, however the header files - even though they are not a copy of the nVidia SDK files should be "licensed" under the NVIDIA license What do you think? |
|
Just for a precision : The headers are under this license, except for the opix_stubs.h which is under a more permissive licence: https://raytracing-docs.nvidia.com/optix7/api/optix__stubs_8h_source.html I think our I would develop a little bit on the the goal of the program. Something like this, maybe?
(Point me my english errors / approximations 😉 ) |
|
I also see on that particular license that if we were to provide binaries (pre-compiled dll's), the notice must be included. So, add something that prints this license on the installscript you have to "agree" before it continues perhaps? |
|
Or just a |
I'd remove the |
My bad, I had put it there so I could open it in my IDE to work on the |
|
Feel free to create some PR's on that Both in terms of License text and suggestions to maybe a file that can be copied with the build-script - eg. LICENSE.txt or NVIDIA.LICENSE or something, as i think that is a good suggestion to include this when building (and also in release binaries). I do not have a clue about setting up Github Actions for automatically building stuff tho. Do you @Saancreed and @PetitMote want me to add you as "Collaborators" if that means you can/want to set stuff like that up? |
Sure, but I won't be able to do that in the next few hours. On the other hand, GitHub Actions is quite easy to setup, just place a workflow YAML in |
No rush.. 😄 Will take a look at the artifact thingy when i get home and see if i can adapt yours to generate stuff 👍 |
|
Welp, I made an attempt at GitHub Actions and the runner refused to pull some almost basic libraries which I'm sure Ubuntu 20.04 GH uses as base image ships in its repos because locally everything builds just fine. Not in mood right now to try and figure out what's broken in those images so I'll probably retry tomorrow at the earliest, most likely after switching build environment to something like Arch. |
|
When i build the packages for myself locally, i build with Arch in a docker image as it usually takes care of outdated headers or whatnot. I had to make a custom Ubuntu docker image for building wine > 6.22 as multilib requirements from wine made it a bit hackish for me to dare building it on the live system (force-installing packages and whatnot). So yeah, 20.04 is starting to be a bit dated unless you have loads of PPA's set up, and i have no idea if you can even do such a thing in GitHub Actions. |
|
Hello, Yesterday, SveSop corrected the OpenCL bug, and it worked fine. I’d say that might be because of the driver update, but I think I rebooted before having dforce working. Also, since you hardcode to return 0 TCC GPU, it shouldn’t appear at all? |
|
Well.. it is the TCC/WDDM thingy that seems wrong and should be fixed by dxvk-nvapi, so maybe check those logs to see if something seems fishy there? EDIT: missed the attached log 😮 Yeah, it seems oki. Weird... |
|
So, I’ve been doing some tests. Yesterday, I rebuilt a new Wineprefix, so this one didn’t work. I reused my backup, and now it’s ok. I don’t know why, though. |
|
When I install Daz Studio via Daz Central, I get this error, although it doesn’t stop anything: Did anyone try installing Daz in a new prefix, using wine-staging 7.0.5? |
|
I had an crash-error from Daz Central while it was installing Studio... but i just chose to ignore it, and the install seemed to work just fine, so i dunno if it was just some strangeness. This was with distro staging-7.0-rc5 |
|
So, I rebuilt my wine with the new commits. I didn’t get an error when installing Daz Studio this time. I get this error while launching Daz: 050c:trace:seh:dispatch_exception code=40010006 flags=0 addr=000000007B0123AE ip=000000007B0123AE tid=050c
050c:warn:seh:dispatch_exception "WARNING: ..\\..\\..\\..\\..\\src\\pluginsource\\DzIrayRender\\dzneuraymgr.cpp(359): Iray [ERROR] - GPU:RENDER :: 0.0 GPU rend error: NvAPI call NvAPI_GPU_GetVbiosVersionString returned an error:\n"
0550:trace:seh:call_vectored_handlers calling handler at 000000021B41D530 code=40010006 flags=0
0550:trace:seh:call_vectored_handlers handler at 000000021B41D530 returned 0
0550:trace:seh:call_vectored_handlers calling handler at 00000002EDF8EBD0 code=40010006 flags=0
0550:trace:seh:call_vectored_handlers handler at 00000002EDF8EBD0 returned 0
0550:trace:seh:call_stack_handlers found wine frame 000000000101DDA0 rsp 000000000101DF00 handler 000000007B631FD0
0550:trace:seh:call_teb_handler calling TEB handler 000000007B631FD0 (rec=000000000101DB70, frame=000000000101DDA0 context=000000000101D090, dispatch=000000000101CF60)
0550:trace:seh:RtlRestoreContext returning to 000000007B631F6A stack 000000000101DC30
0550:trace:seh:dispatch_exception code=40010006 flags=0 addr=000000007B0123AE ip=000000007B0123AE tid=0550
0550:warn:seh:dispatch_exception "WARNING: ..\\..\\..\\..\\..\\src\\pluginsource\\DzIrayRender\\dzneuraymgr.cpp(359): Iray [ERROR] - GPU:RENDER :: 0.0 GPU rend error: NVAPI_NO_IMPLEMENTATION\n"And the dxvk-nvapi logs: As you can see, it somehow reclaims a |
|
@PetitMote Your old prefix had |
|
Ok, that’s because Lutris puts nvml inside dxvk-nvapi. Since I launched this new wineprefix straight with my compiled version of dxvk, lutris didn’t create the symlink to nvml. Good to know ^^ Edit: also, I first built wine-nvml, but couldn’t get it to work, mostly because I’m not sure which file I’m supposed to copy in my prefix. @jp7677 do you plan on pushing the daz fixes in the main branch of dxvk-nvapi? It would really make the installation easy if most of it would be inside wine / staging / Lutris |
|
@jp7677 I wonder what makes DAZ list two cuda devices when we are not using nvml.. Need to check what nvapi instructions being used that uses nvml when available 🤔 |
|
First I would like to know whats really needed of that branch. I would prefer not to push the three GPU* methods to master since they contain hardcoded values I can't extract from anywhere else. The two others might be fine. If you could sort which methods are really needed by excluding them one by one, that would be cool! |
I tried that a couple of hundred posts up.. but can try again just to ease your mind. On the nvml method in use i suspect it is this one |
|
@jp7677 Joking aside: The other patches did not really seem needed to render. |
|
Are you sure it renders on GPU? TCC should be for GPU with no display attached, if I understood correctly. |
|
The DXVK-NVAPI branch should be good now, I've found a hint in the CUDA documentation what the slot ID is, so I could implement this properly. Please let me know if the version from the branch still works, then I can merge this. |
I verified this by looking at nvidia-smi gpu load when rendering, and it was loading the GPU 98-100% at times.
Nice 👍 I will verify working condition once i get home. From the little i understand of c++ code, it looks good and a lot better than just "hard-coded values" 😄 |
Works for me |
|
Merged, thanks a lot. DAZ-Studio should also now be fine without NVML with DXVK-NVAPI from master. |
wine-staging/wine-staging@e1c496b Got some pending OpenCL changes (DAZ dForce usage) for wine-devel i think Zeb have some ideas about: Thank you @jp7677 @Saancreed @PetitMote For making this work! Awesome 👍 PS. I have sent a request to nVidia about the use of snippits from OptiX SDK for our wine-nvoptix relay library, so hopefully i will get some feedback to that. |
Hello there,
It’s been a while, but some update (from Daz Studio) broke iRay rendering on nvidia GPU through Wine. I’m only a recent user, so I don’t know how it used to work or if dxvk_nvapi was needed, but I think it used to work before the first releases of dxvk, when wine-staging was needed. Rendering works fine on CPU, but it’s much slower.
I’ve checked the logs and tried with and without dxvk_nvapi. Here are the logs from dxvk_nvapi:
I’ve started by reading the logs from Daz Studio, and there isn’t more, but I can still provide the log file if needed. Also, when dxvk_nvapi is disabled, I get the error on the
NvAPI_Initializemethod (3 times), and not on these 3 methods.I believe the issue is due to these methods not being implemented on dxvk_nvapi. I would sincerely love to help and try to add them, but I’m merely a python beginner and c++ looks like sorcery to me (and, well, we’re talking about some low level coding). But I’d be happy to help or try if someone can point me in the right direction.
Also, DazStudio physic simulation, dforce, used to work, but now it only says "no OpenCL 1.2 compatible device found". I have absolutely no idea if it’s related, there is no information in the logs about it, but well, maybe if we fix the NvAPI issue we’ll get something.
Thank you guys for your work, it’s still pretty amazing.
The text was updated successfully, but these errors were encountered: