Daz Studio and Linux

1414244464753

Comments

  • Try running clinfo (on linux) to check that it finds an available opencl device. You could also install clinfo (to the windows directory) on your prefix and run it from there to compare output to see if wine can also see the same devices. If both those check out, then it's studio which isn't detecting.

    Although it could be "winebottle windows" that isn't finding the opencl device, it definitely isn't the linux system itself, since both wine bottles (the one seeing Open CL and the one not seeing Open CL) are on the same system.  

     

    A lot of weird things have been happening with studio on wine recently. I used to use a bash script to run clinfo (to 'wake' opencl otherwise it wouldn't get found by studio) and then run studio. Lately, the script doesn't launch studio anymore (no error), but the line in the script 'WINEARCH=win64 WINEPREFIX=[pathtoprefix] wine [pathtoexe)' works fine from the terminal.

    I have very big bugs since last update. The most annoying one is that sometimes DAZ decides it doesn't want to render anymore. This shows in two possible ways: you get immidiately an empty render that finished within seconds or it goes on forever without doing anything, just counting time and not actually rendering. Fixable only by multiple restarts of DAZ and sometimes it doesn't help to do it once.  Also sometimes I have to close DAZ in htop, because just closing it won't actually close it and then it won't start again, since an instance is running already. 

     

    Not sure, but I highly doubt it. APIC (Advanced Programmable Interrupt Controller) seems a ver low level setting, not something that should be fiddled with. Are these two bottles on the same hardware or on different machines? If it's different hardware, it makes sense that'd the physical ids might be different, like motherboard Bus addresses.

    Same hardware, same OS. Everything is the same but the actual content of the wine bottles.  

  • Chanteur-de-Vent said:

    Try running clinfo (on linux) to check that it finds an available opencl device. You could also install clinfo (to the windows directory) on your prefix and run it from there to compare output to see if wine can also see the same devices. If both those check out, then it's studio which isn't detecting.

    Although it could be "winebottle windows" that isn't finding the opencl device, it definitely isn't the linux system itself, since both wine bottles (the one seeing Open CL and the one not seeing Open CL) are on the same system.  

    Ah, now I see. That is weird. I've never copied over entire wine prefixes. I've renamed my main Daz prefix and created a new main in order to preserve the current version when I'm expecting DIM to replace the current with a new release, but usually it's easier to d/l the installer from the site before it's replaced. I wish they'd keep a repo of recent versions though.

    Something in the wine prefix settings then.

     

    You aren't using PlayonLinux or some other helper that allows you to keep multiple versions of Wine/staging are you?

    A lot of weird things have been happening with studio on wine recently. I used to use a bash script to run clinfo (to 'wake' opencl otherwise it wouldn't get found by studio) and then run studio. Lately, the script doesn't launch studio anymore (no error), but the line in the script 'WINEARCH=win64 WINEPREFIX=[pathtoprefix] wine [pathtoexe)' works fine from the terminal.

    I have very big bugs since last update. The most annoying one is that sometimes DAZ decides it doesn't want to render anymore. This shows in two possible ways: you get immidiately an empty render that finished within seconds or it goes on forever without doing anything, just counting time and not actually rendering. Fixable only by multiple restarts of DAZ and sometimes it doesn't help to do it once.  Also sometimes I have to close DAZ in htop, because just closing it won't actually close it and then it won't start again, since an instance is running already. 

    I got something like those. Renders would come up blank or churn away 'optimising images'* processing image 400 of 28. This was 3Delight, iray as well was crashing on renders often (and it's been stable since 2017). Hasn't done either in half a week, and iray seems ok now too (although I've not done a lot of iray renders, and I usually render to rib and use the linux 3delight version).

     

    * I use gamma correction (2.2) on 3Delight

    Not sure, but I highly doubt it. APIC (Advanced Programmable Interrupt Controller) seems a ver low level setting, not something that should be fiddled with. Are these two bottles on the same hardware or on different machines? If it's different hardware, it makes sense that'd the physical ids might be different, like motherboard Bus addresses.

    Same hardware, same OS. Everything is the same but the actual content of the wine bottles.  

    So is one of the prefixes copied over and the other created natively or are both copied? 

    What about the copied files permissions set to. Might be worth comparing file/folder ownership wine prefixes should be owned by the user owner/group. Are there username differences between your old and new systems?

  • You aren't using PlayonLinux or some other helper that allows you to keep multiple versions of Wine/staging are you?

    No, just pure wine-bottles.

     

    I got something like those. Renders would come up blank or churn away 'optimising images'* processing image 400 of 28. This was 3Delight, iray as well was crashing on renders often (and it's been stable since 2017). Hasn't done either in half a week, and iray seems ok now too (although I've not done a lot of iray renders, and I usually render to rib and use the linux 3delight version).

     I had to restart DAZ like five times today before it agreed to render something. Instead it would start the counter without putting any load on the processor. It does seem to load the render into RAM though, since it increases.

     

    So is one of the prefixes copied over and the other created natively or are both copied? 

    What about the copied files permissions set to. Might be worth comparing file/folder ownership wine prefixes should be owned by the user owner/group. Are there username differences between your old and new systems?

    One is copied over from the old system, the other freshly installed on the new system. And the usernames are different, which was my original problem with CMS on the copied winebottle - DAZ connect linked to the "old" name folder. 

  • Chanteur-de-Vent said:

    You aren't using PlayonLinux or some other helper that allows you to keep multiple versions of Wine/staging are you?

    No, just pure wine-bottles.

    I miss the ability to have multiple versions of wine to run against, but I didn't like  the new Java based ui brought in on Playonlinux 4.

    I got something like those. Renders would come up blank or churn away 'optimising images'* processing image 400 of 28. This was 3Delight, iray as well was crashing on renders often (and it's been stable since 2017). Hasn't done either in half a week, and iray seems ok now too (although I've not done a lot of iray renders, and I usually render to rib and use the linux 3delight version).

     I had to restart DAZ like five times today before it agreed to render something. Instead it would start the counter without putting any load on the processor. It does seem to load the render into RAM though, since it increases.

    I've had maybe two scenes crash the render engine over the last four days (iray), I've not had problems at all with 3Delight in that period.

    So is one of the prefixes copied over and the other created natively or are both copied? 

    What about the copied files permissions set to. Might be worth comparing file/folder ownership wine prefixes should be owned by the user owner/group. Are there username differences between your old and new systems?

    One is copied over from the old system, the other freshly installed on the new system. And the usernames are different, which was my original problem with CMS on the copied winebottle - DAZ connect linked to the "old" name folder. 

    You need to use chown to change file ownership, I always user the same username, but when I last made a fresh install (I kept the home folder but used chown anyway).

    That was pre-daz usage. When my last machine went caput, I built a new machine and dropped the HDD and SDD from the old into the new, edited the boot setup* to point to the right partition, changed the graphics driver setup and carried on - I don't think I rebuilt my wine bottles, so they'd have been created on the same install, but while on different hardware.

    * I cocked that up actually, my new build has one of those new UEFI BIOS, and my Grub is now on legacy mode (I needed to create a BOOT partition, but I've no space)

    Make sure user and group for your wine bottles all match your home folder.

  • chris_9413c754chris_9413c754 Posts: 8
    edited October 2021

    Apparently Smart Content works out of the box in the Pop-OS distro (no messing around with setting up a Postgresql db on linux needed). I expect it's how Pop-OS has it's Wine setup. This is according to a Pop-OS user, who questioned the need for the Postgresql step, saying it wasn't required.

    I organise my content by using soft links (e.g. a folder structure that contains links to props products categorised by topic, e.g sci-fi, fantasy, outdoors), this works on both recent DS and Poser runtime content.

    I'm running Pop_OS... and using the included/built-in database software that comes with Daz. I have never had a need to do this crazy Postgres stuff you all talk about. It just works.   Also, I had a lot of trouble early on with manually installed content that I place under the "My Library" directory.  Linux is case-sensitive, and lots of products out there mix the case of directory names.  This works fine on Windows because case-sensitivity seems to just be a cosmetic thing (directories like "Runtime" and "runtime" are considered the same on Windows).  My fix was to make sure the "My Library" directory was mounted on a LVM logical volume that was formatted to VFAT.  This seems to keep things happy under Daz no matter what the case is of the files/directories. 

    Post edited by chris_9413c754 on
  • chris_9413c754 said:

    Apparently Smart Content works out of the box in the Pop-OS distro (no messing around with setting up a Postgresql db on linux needed). I expect it's how Pop-OS has it's Wine setup. This is according to a Pop-OS user, who questioned the need for the Postgresql step, saying it wasn't required.

    I organise my content by using soft links (e.g. a folder structure that contains links to props products categorised by topic, e.g sci-fi, fantasy, outdoors), this works on both recent DS and Poser runtime content.

    I'm running Pop_OS... and using the included/built-in database software that comes with Daz. I have never had a need to do this crazy Postgres stuff you all talk about. It just works.   Also, I had a lot of trouble early on with manually installed content that I place under the "My Library" directory.  Linux is case-sensitive, and lots of products out there mix the case of directory names.  This works fine on Windows because case-sensitivity seems to just be a cosmetic thing (directories like "Runtime" and "runtime" are considered the same on Windows).  My fix was to make sure the "My Library" directory was mounted on a LVM logical volume that was formatted to VFAT.  This seems to keep things happy under Daz no matter what the case is of the files/directories. 

    Cheers for the confirmation on Pop-OS and Smart Content...

    About your Content, I did consider going that route, storing my content on a Windows format partition, but I had issues in the past when I had my music stored on an NTFS, VFAT isn't a great option as it's inefficient for large partition sizes, and your content may start off meagre and mangeable, but give it a year or two. I've 23 Content libraries for free items, in all must be nearly 4TB by now.

    I believe DIM manages to iron out most the case issues, (I think it's possible to add another repo folder additional to the Daz \Downloads).

    I reorganise content when installing to tidy up, and make it easier to locate I don't find it too onerous to check case while I'm sorting. Without case concerns, I'd probably lazily dump unzipped archives into content dirs without checking, and end up with items I can't find or miscategorised items.

  • Oddest thing, just got round to running update and a reboot (first time in a couple of weeks running update and a reboot).

    Noticed some status feedback I don't usually see (in the terminal) when launching Studio, to do with postgresql. Then when the UI launched I was presented with a login dialog, and it worked.

    Well, Smart Content is now working (without the linux postgres backend setup). Just like it does on Pop-OS....

    Wine 6.21-1 on Archlinux (and I launched Studio 4.12)

  • bingchilling43bingchilling43 Posts: 1
    edited November 2021

    GafftheHorse said:

    Oddest thing, just got round to running update and a reboot (first time in a couple of weeks running update and a reboot).

    Noticed some status feedback I don't usually see (in the terminal) when launching Studio, to do with postgresql. Then when the UI launched I was presented with a login dialog, and it worked.

    Well, Smart Content is now working (without the linux postgres backend setup). Just like it does on Pop-OS....

    Wine 6.21-1 on Archlinux (and I launched Studio 4.12)

    Never posted on here before but came here just to confirm, just installed Daz Studio on Manjaro KDE without any Postgresql setup and it just worked out of the box when it never used to. I'm using Daz Studio 4.15 installed through Daz Central with Wine-Staging 6.16. I'm not really an advanced Linux user so this is pretty nice.

     

    Edit: Just moved to EndeavourOS, using Daz 4.15 installed with Daz Central as before, with Wine-Staging 6.21. CMS is just working out of the box now it seems. NIce.

    Post edited by bingchilling43 on
  • bingchilling43 said:

    GafftheHorse said:

    Oddest thing, just got round to running update and a reboot (first time in a couple of weeks running update and a reboot).

    Noticed some status feedback I don't usually see (in the terminal) when launching Studio, to do with postgresql. Then when the UI launched I was presented with a login dialog, and it worked.

    Well, Smart Content is now working (without the linux postgres backend setup). Just like it does on Pop-OS....

    Wine 6.21-1 on Archlinux (and I launched Studio 4.12)

    Never posted on here before but came here just to confirm, just installed Daz Studio on Manjaro KDE without any Postgresql setup and it just worked out of the box when it never used to. I'm using Daz Studio 4.15 installed through Daz Central with Wine-Staging 6.16. I'm not really an advanced Linux user so this is pretty nice.

     

    Edit: Just moved to EndeavourOS, using Daz 4.15 installed with Daz Central as before, with Wine-Staging 6.21. CMS is just working out of the box now it seems. NIce.

    Nice to have some confirmation that it's not just my system or Archlinux in general.

    I've been using Linux since 1999, but even I found it a nice surprise. Still not exactly sure what changes have happened that it now works, I'd just assumed it was better Wine integration with the OS in Pop-OS.

    Still don't use Smart Content much though, I'm too used to and know where everything is in the Content Library.

  • KitsumoKitsumo Posts: 1,212
    edited November 2021

    Is the DS general release out now or is it still in beta? I've been away for awhile.

    Edit: Nevermind. I was thinking of DS 5. It's good to know that Postgresql is working though.

    Post edited by Kitsumo on
  • I know this is an old thread but I believe WINE is now avalable as 64 BIT.  I have read elsewhere that ppl have been successful with Daz 64 in WINE.

    As for development the code, if I am correct, is written in C++ which is also often used for Linux and Mac programming. It's in the compiler that they are made into OS specific versions. Mac is an linux as it's core already so in principle DS is already written for at least one version of "linux" that being the Apple variant.

    So far as developing assets for sale I don't see that as making a difference. Other than perhaps installers the actual assets should not care what the OS is as long as DS is up and running.  a DUF file is a DUF file on any platform.

    Perhaps there is some anti-open source bias at work?

    Heck, if I could ditch Microsoft and pay Daz a few bucks extra for a linux variant I'd do it.

    I am prevented so far by only two applications...DS and VSDC Video editor and the video editor has a linux release in the pipeline though no date yet.

     

  • paul_ae567ab9 said:

    As for development the code, if I am correct, is written in C++ which is also often used for Linux and Mac programming. It's in the compiler that they are made into OS specific versions. Mac is an linux as it's core already so in principle DS is already written for at least one version of "linux" that being the Apple variant.

    The compiler has little to do with it; ANSI C/C++ will compile with clang++ or g++ on either platform. The differences occur in the platform specific libraries that govern higher level functions like how to draw GUIs, etc.

    Mac OS, or whatever it is called today, is not a variant of Linux. Rather they both ultimately descend from a common UNIX ancestor, so they're like second cousins. But they are both (largely) POSIX compatible and therefore share a common low-level interfaces that mostly hides the differences in the two kernels from application programmers. Incidentally, disregarding specialized embedded systems, the world of desktop computing is divided into just two families: Microsoft (Win32), and literally everyone else (POSIX).

    But the twist is that the Qt framework, upon which many cross-platform app are based (DS included), does an admirable job of hiding the remaining higher level details that are not accounted for by the POSIX.1 standard, i.e. how does one display a file selection dialog, or how does one create an application's main window? I suspect that the only reason DS doesn't run across Windows, Mac, and Linux with just a recompile is because the Qt framework doesn't yet encapsulate the high performance rendering that DS needs.

    So far as developing assets for sale I don't see that as making a difference. Other than perhaps installers the actual assets should not care what the OS is as long as DS is up and running.  a DUF file is a DUF file on any platform.

    You're absolutely correct about this. JSON is JSON is JSON.

    Perhaps there is some anti-open source bias at work?

    Not necessarily bias, but rather incompatible licenses. The most popular Open Source license is the GPL v2. It requires that any app that GPL code is linked into also be Open Source. You may have heard of the "viral" nature of Open Source that Steve Balmer coined back in the day. That is what he was referring to. Using GPL software in Daz Studio would require Daz Studio to itself be Open Source. I am sure that Daz doesn't want that because within days, some enterprising nerd would make Strand Based Hair and HD details available to everyone.

    There are other Open Source licenses that do not have this restricting, e.g. BSD, and there is the classic workaround of not actually linking the two softwares into the same executable but rather have them remain separate and instead communicate over some interprocess communication method (of which there are many to choose from), but this is a hassle and is slower at runtime.

    Heck, if I could ditch Microsoft and pay Daz a few bucks extra for a linux variant I'd do it.

    So would I, but unfortunately, it wouldn't be a "few" bucks extra.

    I am prevented so far by only two applications...DS and VSDC Video editor and the video editor has a linux release in the pipeline though no date yet.

    I hear you. For me it's down to DS, Marvelous designer, Quixel Bridge, and Axis Neuron. Blender, Maya, Motionbuilder, Houdini, and Cascadeur all run on some version of Linux.

  • Well, guys... After saw all thread, I just give up set up DAZ to my business. The extra effort fail to compensate the features.

    Have Windows just for run DAZ, dual boot or not, also doesn't worth. The content of website looks amazing, but I know that all reality have a bias to be disappointing.  

    Some day, IF DAZ3d make official Linux support, I can consider it. For now I keep doing what I do.

  • chris_9413c754 said:

    Use Lutris.  For all Wine-related stuff you do in Linux. Any of you doing Wine manually, installing deb/rpm/flatpak versions, manually compiling vulkan, etc..etc.. and then double-clicking .EXE files to run them... that's so 2000's way of doing things.  Seriously, just get Lutris, and use the custom Lutris builds of wine which have pretty much the same tweaks to them that Proton does. I've run DAZ from day 1 under Lutris-managed WINE runners and it's been flawless for me (except for the lack of GPU rendering of course).  Not only that, almost all older games I've thrown at this thing work.  Every CoD up to the early 2010 games, GTA1-4, Crysis 1 / 2, and lots more. They all just WORK. DAZ works amazing. Even the Windows-based Postgres DB it installs... works.  I've never had to do the "workaround" by installing Postgres under Linux and pointing DAZ to it.  Just make sure your wine-prefix directories are on a vfat filesystem (or at least your library directory). I've run into so many problems with installing 3rd party / free content from outside of the DAZ store that doesn't have any consisitencey with upper/lowercase names in files/directories. It's a mess on an EXT4 filesystem which is case-sensitve.  VFAT isn't, so all the mismatched case stuff just works.

     

    "just use Lutris" great....HOW? Where are the instructions on how to install Daz3d via Lutris?
    (I'm very familiar with Lutris as I've got games installed with it)

  • It just really sucks that this software seems so incredibly picky about drivers and them having to be on the bleeding edge for GPU rendering support. Recently I tried CUDA Z for Windows under Wine and it correctly reported CUDA 11.x and also did the speed test just fine. Of course 4.11 also still works with GPU and I wish you could just take its iray over to the new version but even that is not working anymore. If Daz keeps insisting on the absolutely latest drivers and the drivers for Linux keep lagging behind a couple months I guess it doesn't look good for GPU render support again any time soon.

  • So who has Iray, GPU acceleration working on Linux --- which distro and wine config ?

    Let's get this going people... why isn't it working, why does Windows have the foothold...

  • MotéMoté Posts: 29

    Hello guys,

    I’ve been reading the last pages, but it doesn’t seem like anyone came with a solution to Daz not detecting OpenCL devices. Does anyone found one? I can’t even use clinfo since there has been no binaries for windows for months.

    Could it be due to the fact that there is now OpenCL 3.0? Maybe the wine patch wouldn’t work? (Juste make me realise how dforce technology is old and outdated, no?)

    By the way, I’m running wine staging 7.0, on Archlinux, with an Nvidia RTX 3060, if it can be useful.

    Thank you all

  • MotéMoté Posts: 29
    edited January 2022

    Hello guys,

    I’ve been investigating. Do you have the same errors in your logfile when you open a project?

    2022-01-04 17:11:00.861 Initializing NVIDIA Iray...
    2022-01-04 17:11:00.862 Iray [INFO] - API:DATABASE ::   0.0   API    db   info : Loaded "C:\Daz 3D\Applications\64-bit\DAZ 3D\DAZStudio4\libs\iray\libneuray.dll"
    2022-01-04 17:11:00.862 Iray [INFO] - API:MISC ::   0.0   API    misc info : Iray RTX 2020.1.6, build 334300.9558, 27 Mar 2021, nt-x86-64
    2022-01-04 17:11:00.862 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(480): Could not add path: "C:/users/timothee/AppData/Roaming/DAZ 3D/Studio4/shaders/iray". Due to unknown error -2
    2022-01-04 17:11:00.862 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(480): Could not add path: "C:/users/timothee/AppData/Roaming/DAZ 3D/Studio4/temp/shaders/iray". Due to unknown error -2
    2022-01-04 17:11:00.880 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(359): Iray [ERROR] - GPU:RENDER ::   0.0   GPU    rend error: NvAPI call NvAPI_GetAssociatedNvidiaDisplayName returned an error:
    2022-01-04 17:11:00.880 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(359): Iray [ERROR] - GPU:RENDER ::   0.0   GPU    rend error:   NVAPI_NO_IMPLEMENTATION
    2022-01-04 17:11:00.881 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(359): Iray [ERROR] - GPU:RENDER ::   0.0   GPU    rend error: NvAPI call NvAPI_GPU_GetBusType returned an error:
    2022-01-04 17:11:00.881 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(359): Iray [ERROR] - GPU:RENDER ::   0.0   GPU    rend error:   NVAPI_NO_IMPLEMENTATION
    2022-01-04 17:11:00.881 Iray [INFO] - GPU:RENDER ::   0.0   GPU    rend info : Found 1 GPU with vendor's API.
    2022-01-04 17:11:00.903 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(359): Iray [WARNING] - CUDA:RENDER ::   0.0   CUDA   rend warn : CUDA module initialization failed.
    2022-01-04 17:11:00.903 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(359): Iray [WARNING] - CUDA:RENDER ::   0.0   CUDA   rend warn : cudaRuntimeGetVersion returned with error 'initialization error'

    […]

    2022-01-04 17:11:01.101 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(359): Iray [WARNING] - IRAY:RENDER ::   1.1   IRAY   rend warn : CUDA module initialization failed with error 'initialization error' (0x3); iray photoreal can only run in CPU mode. Please update your NVIDIA driver (www.nvidia.com).
    2022-01-04 17:11:01.101 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(359): Iray [ERROR] - IRAY:RENDER ::   1.1   IRAY   rend error: NvAPI call NvAPI_EnumTCCPhysicalGPUs returned an error:
    2022-01-04 17:11:01.102 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(359): Iray [ERROR] - IRAY:RENDER ::   1.1   IRAY   rend error:   NVAPI_NO_IMPLEMENTATION
    2022-01-04 17:11:01.102 Iray [INFO] - IRAY:RENDER ::   1.1   IRAY   rend info : Using iray plugin version 5.1, build 334300.9558 n, 27 Mar 2021, nt-x86-64-vc14.
    2022-01-04 17:11:01.102 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(359): Iray [WARNING] - IRAY:RENDER ::   1.1   IRAY   rend warn : There is no CUDA-capable GPU available to the iray photoreal renderer.
    2022-01-04 17:11:01.102 Iray [VERBOSE] - IRAY:RENDER ::   1.1   IRAY   rend stat : Environment cache size capacity: 5.
    2022-01-04 17:11:01.102 Iray [INFO] - BLEND:RENDER ::   1.1   BLEND  rend info : Plugin "blend render" (build 334300.9558, 27 Mar 2021) initialized
    2022-01-04 17:11:01.102 Iray [INFO] - IRAY_CLOUD_CLIENT:NETWORK ::   1.1   IRAY_C net  info : Plugin "iray_cloud" (build 334300.9558, 27 Mar 2021) initialized
    2022-01-04 17:11:01.102 Iray [INFO] - IRAY_CLOUD_CLIENT:NETWORK ::   1.1   IRAY_C net  info : Plugin "irt_cloud" (build 334300.9558, 27 Mar 2021) initialized
    2022-01-04 17:11:01.102 Iray [INFO] - IRAY_CLOUD_CLIENT:NETWORK ::   1.1   IRAY_C net  info : Plugin "nitro_cloud" (build 334300.9558, 27 Mar 2021) initialized
    2022-01-04 17:11:01.102 Iray [INFO] - IRAY_CLOUD_CLIENT:NETWORK ::   1.1   IRAY_C net  info : Plugin "iq_irt_cloud" (build 334300.9558, 27 Mar 2021) initialized
    2022-01-04 17:11:01.102 Iray [INFO] - IRT:RENDER ::   1.1   IRT    rend info : Plugin "irt" (build 334300.9558, 27 Mar 2021) initialized
    2022-01-04 17:11:01.102 Iray [INFO] - EIAXF:IO ::   1.1   EIAXF  io   info : Plugin "axf importer" (build 334300.9558, 27 Mar 2021) initialized
    2022-01-04 17:11:01.103 Iray [INFO] - ICB:IO ::   1.1   ICB    io   info : Plugin "cb_importer" (build 334300.9558, 27 Mar 2021) initialized
    2022-01-04 17:11:01.103 Iray [INFO] - IRAY_CLOUD_CLIENT:NETWORK ::   1.1   IRAY_C net  info : Plugin "iray_bridge_snapshot" (build 334300.9558, 27 Mar 2021) initialized
    2022-01-04 17:11:01.103 Iray [INFO] - IRAY_CLOUD_SERVER:NETWORK ::   1.1   IRAY_C net  info : Plugin "iray_bridge_server" (build 334300.9558, 27 Mar 2021) initialized
    2022-01-04 17:11:01.103 Iray [INFO] - EEMI:IO ::   1.1   EEMI   io   info : Plugin ".mi exporter" (build 334300.9558, 27 Mar 2021) initialized
    2022-01-04 17:11:01.103 Iray [INFO] - EIMI:IO ::   1.1   EIMI   io   info : Plugin ".mi importer" (build 334300.9558, 27 Mar 2021) initialized
    2022-01-04 17:11:01.104 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(359): Iray [WARNING] - IRAY:RENDER ::   1.0   IRAY   rend warn : There is no CUDA-capable GPU available to the iray photoreal renderer.

    It looks like it’s an issue with the nvapi. According to this old page, Wine never expected to fully it. However, there are 2 projects aiming at a better support. A standalone version, and dxvk_nvapi. Since I’m using Lutris, I’m already using dxvk_nvapi. I might try the other standalone later. The good news is, there are people trying to give a better support to nvapi with wine.

    When I’m trying to render using only the GPU, I don’t get any significant error. My case is, it might be possible to solve the issue by adding support to these nvapi calls in dxvk_nvapi! Or in nvapi_standalone.

    I’ll investigate and see if these are implemented or not.

    I’ll give a look into dforce too. I tried installing mutiple OpenCL supports on my Archlinux, none was detected by Daz (tried PoCl and Intel CPU OpenCL).

    Post edited by Moté on
  • MotéMoté Posts: 29

    It’s me again,

    I’ve continued looking into all this. I’ve opened an issue on dxvk_nvapi. I have hope we can effectively fix the GPU rendering guys! Any help appreciated!

  • MotéMoté Posts: 29

    Hello guys,

    Quick update: we are making progress. Now, Daz Studio correctly detects the GPU and its Cuda compability. Well, on the other hand, it crashes at start. We are not sure, for now, to be able to fix this, but we are trying.

  • MotéMoté Posts: 29

    Hi,

    Quick update: We were able to launch Daz Studio with a proper detection and initialization of the Cuda GPU. However, we hit another problem, the OptiX library being not implemented by Wine.

  • IceCrMnIceCrMn Posts: 2,115

    Thank you and the others for your work on this.

  • Moté said:

    Hi,

    Quick update: We were able to launch Daz Studio with a proper detection and initialization of the Cuda GPU. However, we hit another problem, the OptiX library being not implemented by Wine.

    That is outstanding news. Thanks for your efforts.

  • Thank you so much Moté and all involved in this! That level of persistence and effort is what gets stuff done :D I wish I could help but I know next to nothing about programming, sadly. Anyways, amazing news!

  • MotéMoté Posts: 29
    edited January 2022

    Hello guys!

    WE DID IT!!!

    This render is ugly, but is using Iray render on GPU!

    Oh god, I’m so happy!

    We will now take a few days to think about copyright / legal issues. At least, we should be able to share the compiled library, however there are still questions about the source code. I will soon share with you how to install all this! (Spoiler: you need wine-staging and dxvk-nvapi. The easiest way to use the later is to build your wineprefix using Lutris.) I will make a proper post to thank the people who helped me (who are the real heroes, they are the one that built this, I had to watch them from my very limited knowledge. Also, they aren’t even user of Daz, it was pure passion and generosity.)

    Also, I didn’t receive mails as I thought I should for your replies, I’ll check that.

    (And we still got the OpenCL issue. Will work on that too, I definitely want physics to work.)

    Post edited by Moté on
  • MotéMoté Posts: 29
    edited January 2022

    Well then, I guess you’ll have to do with the second render. But at least a real character. Took about 10 minutes on my RTX 3060 and i5 11500, with quality at 3 and convergence ratio at 96%. It was around 1:15 before.

    And sorry about that, I didn’t know about this rule.

    iray-on-gpu.png
    1500 x 1500 - 2M
    Post edited by Moté on
  • MotéMoté Posts: 29
    edited January 2022

    Hello guys, me again,

    We are polishing our git repository, and then we’ll send a demand to nvidia to make sure everything is ok.

    In the same time, we’ve started working on the OpenCL issue. Does anyone know when the issue started ? Ideally, we’d need Daz Studio, graphic card driver, and wine versions so we can search for a bug that might have been introduced somewhere.

    Or if dforce is working for you, if you can also give us these informations, that would be great.

    EDIT: Well, we made it work! Also, some of our changes have already been included in the next versions of wine and wine-staging.

    Post edited by Moté on
  • MotéMoté Posts: 29

    Hello,

    Our fixes for Cuda have been added to wine-staging. They should be released in the next version, 7.0.rc5 (or maybe 7.0 or 7.1, I don’t know).

    We identified a bug in wine OpenCL. A fix has been included in wine upstream, so next release (7.0) will includes it. However, it was still missing some things, and since wine is in code freeze for the next update, they will be added to the following version, 7.11.

    Our changes to dxvk-nvapi are now pushed to the main branch. Next release will also include them.

    Concerning OptiX, required for GPU rendering, we are now waiting for an answer from nvidia. We’ll also look into a cross-compile version we can build and share. I’d like to ask Lutris if they would be ok to include it in their tool.

    Once we know about OptiX, I’ll write a little tutorial on how to install a complete working Daz Studio. Beware that, as long as the fixes aren’t released on compiled packages for your distro, it will include compiling wine. Release of compiled packages will be different for every linux distribution, as Archlinux releases wine-staging on the day it updates, but I think it’s longer for Ubuntu or Debian.

  • IceCrMnIceCrMn Posts: 2,115

    Moté said:

    Hello,

    Our fixes for Cuda have been added to wine-staging. They should be released in the next version, 7.0.rc5 (or maybe 7.0 or 7.1, I don’t know).

    We identified a bug in wine OpenCL. A fix has been included in wine upstream, so next release (7.0) will includes it. However, it was still missing some things, and since wine is in code freeze for the next update, they will be added to the following version, 7.11.

    Our changes to dxvk-nvapi are now pushed to the main branch. Next release will also include them.

    Concerning OptiX, required for GPU rendering, we are now waiting for an answer from nvidia. We’ll also look into a cross-compile version we can build and share. I’d like to ask Lutris if they would be ok to include it in their tool.

    Once we know about OptiX, I’ll write a little tutorial on how to install a complete working Daz Studio. Beware that, as long as the fixes aren’t released on compiled packages for your distro, it will include compiling wine. Release of compiled packages will be different for every linux distribution, as Archlinux releases wine-staging on the day it updates, but I think it’s longer for Ubuntu or Debian.

    Thank you 

Sign In or Register to comment.