Daz 3D is part of 
Connect
DAZ Productions, Inc.
7533 S Center View Ct #4664
West Jordan, UT 84084
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2025 Daz Productions Inc. All Rights Reserved.
Comments
One way or the other - they need to get this sorted .. be that go down the route they planned a few years back with the Mac issue by bringing out a "bare bones" version of Daz 5.0 that's compatible with the new 5xxx GPUs or do it the way you suggest (I don't know enough about C+ to know if this will work) so it works with Daz 4.xx
With the money involved in new GPUs - these are major financial decisions people are having to make .. I'm sat with the money in the bank and I don't know whether to :
a) Save it incase 2 months down the line it get's sorted
b) Use it to feed my kids or
c) blow it on wild women and booze
People need some clarity on this .. Are we having to wait 2 months or 2 years?
Remember that Daz doesn't write the Iray plug-ins, just integrates them, so their options may well be limited.
Yes, it is in fact a method of which they are aware - and use, in some cases. If you notice (which I hadn't) DS does install multiple versions of the MS VC++ runtimes. See http://docs.daz3d.com/doku.php/public/software/dazstudio/4/change_log_4_20_0_17#4_20_0_10
which refers to the dzsdkmemory.dll file in the application folder. The "different C++ compilers" explanation is apparently an executive summary rather than the full technical breakdown (which I probably wouldn't have undrstood well enough to pass on)
You're conflating the ntion of the C++ standard certain code code is compiled against with the the notion of the ABI version the compiler supports. The problem is not compiler compatibility, it is ABI compatibility, which can't be fixed by a DLL. You can link code with different C++ standard support freely into the same app (as is often done in DS SDK development to be able to use advanced C++ features, when the ancient version of Qt DAZ uses requires a much older one, so you segregate the Qt code), but you cannot link code with different ABI versions into the same app because the ABI determines things as fundamental as how a caller calls a function i.e. do I push the parameters right to left, or left to right? Can I put some in registers? Which ones? Does the callee make room on the stack for the return value or do I? How do I catch an exception? How do I bubble one up? What register points to the callee's parameters? What register points to the callee's local variables? Caller and callee had better agree on all of that.
And that's probably why it hasn't been done. DLLs are all in the same process ("task" is Win32 parlance?) and it is much less of an undertaking than separating the app into different tasks and coming up with a means to circumvent all the OS's means of protecting tasks from each other... it is not called "protected mode" for no reason. Shared Memory, anonymous pipes, whatever win32 calls UNIX domain sockets, all mean that not only do your devs have to be good graphics programmers, now they've got to be good systems programmers, too, and your app has all sorts of complicated (read: buggy) data sharing facilities with silly sounding names like "mailbox" :)
Hey Richard,
Thanks for getting back to me with such detailed information.
Yeah I already figured they would know about it, it isn't exactly a super secret ninja coding trick. And it's cool to see they're already using it, or similar techiques in places. And yes if they don't use the iRay SDK directly but some form of plugin it might indeed complicate matters and/or limit their options.
Still hoping for a solution of course, either via Daz 5, or NVIDIA or the third-party coming up with something or creating a version for products that can't use the newest version of the plugin. *fingers crossed*
You’re totally right in your explanation, but I do think you may have misunderstood what I was suggesting. My suggestion was to use a DLL that used C++ internally but only exposes simple plain C-style functions with primitive types and use that to communicate across the boundary (so no C++ objects, std, or exceptions would actually cross that boundary). And since the developers would be in full control of both the DLL and the main application that would be calling it, they can also specify certain calling conventions (like __cdecl, __stdcall) for the exposed functions.
But I agree I did not specify it that explicitly in my earlier post, which I tried to keep relatively simple and had intended more as a simple idea balloon that the Daz-developers could either pick up and look into if it would work or not, if they hadn’t already considered a similar approach.
It’s also not really worth delving into deeper, since Richard has already stated that they know about the technique, and have used it in the past, which implies it’s not feasible for solving the current iRay situation. But I do appreciate the deep dive, and it’s always good to surface these nuances!
a bridge to Omniverse might be the best option for most
(not me, not enough VRAM for Omniverse but in future maybe)
Is Omniverse cloud based or does it run on the PC?
Just another in the long list of reasons not to get a 50 series card.
PC hence my 2080Ti being barely adequate
I mean it runs but really no point as DAZ iray runs better in my case
This is certainly venturing into beating a dead horse territory, as you say, but the calling convention can't fix an ABI mismatch, e.g. calling a __cdecl function on one ABI version can still be incompatible with a __cdecl callee on another ABI version. If that weren't the case, this problem would be an intern level fix. And how functions call each other is just one part of the ABI, a huge standard that few people really understand beyond the very basics; I certainly don't.
What you are proposing won't work. When the gcc team did it during the 2.97 to 3.0 transition days around 2001, it decimated the open source community. Million dollar projects were stalled, like the one I was on at Boeing during that time. It is not fixable in the way you are describing; the only way to fix it is to link all of your object code with the same ABI version, or segregate them in separate processes and somehow make them communicate with some sort of IPC method. Period.
The only technique that can fix this, the IPC method, is a lot of error prone work. For Hitchens, I'm learning more Win32 systems programming than I have ever wanted to know, and it is a horribly kludgey mess compared to the elegance, consistency, and maturity of POSIX. I wouldn't blame anyone for not taking on that challenge in Win32.
Has anybody tried a 5000 series card on an OLDER version of Daz Iray than the current ones? Like the version that shipped with Daz 4.16, or 4.20, or anything prior to 4.22/4.23?
Or start mixing a wonderful concoction with Blender.
Wouldn't work any better than the current version. The issue is with Iray itself, we'd need a newer version of Iray to use 5000 series.
5060 series are releasing soon
Any news on this front? Looking at the 5090 and curious if it will ever get proper support
We know that the 50x0 cards will be supported in the enxt major version of DS, and the last update to Install manager added a Daz Studio 2025 (6) option to the aplication list. So yes, but we don't have an ETA.
That's the thing! Iray has changed dramatically in the past few years, isn't it possible that with all the changes made, they broke the compatibility for new generations of hardware. There was a quote saying (at the time) that future generations of GPUs would work with Iray without needing an update at all. You may recall that the 4000 series worked with Iray right out of the box, no updates were needed to accomplish this. The 4000 series was quite different from 3000, so you cannot claim it is because the architectures are the same. Thus I am wondering if anybody has actually tried testing the version of Iray we had when the 4090 released with the 5000 series.
Maybe it doesn't work, but wouldn't it be wild if it did? I think it is worth a shot for the people who keep their old EXEs of DS. But I do not have a 5000 series to test. I think there is a chance it actually works.
After all...Iray development has broken a whole of things the past couple of years, right? If someone owns a 5000 series card, why not give it a try? You can't use your card anyway, there is no reason not to try.
Has anyone tried a 50xx series with Filament? I'm curious how much faster renders can get. I average about 1-2 seconds per frame with my 2060 even though viewport playback is nearly real-time, which is great but would a 50xx take ithe rendering down to a fraction of a second, or would there still be the bottleneck of just using Daz Studio itself and the time it takes to write each frame? What is the top speed for rendering Filament and is a newer card worth it?
I've tried on 4.20 with my 5080 and it's the same: cannot render anything!
.....a little off topic but also somewhat related,
Just saw notice Wednesday morning of the 5060 Ti being released. There are two versions. one with 8 GB VRAM and the other with 16 G./ The projected MSRP is seemingly affordable (for now) at 299 USD for base the 8 GB version, 379 USD for the 8 GB Ti model and 429 USD for the 16 GB one. The interesting both the Ti versions have the same core count: 4,608 (about one fifth of what the 5090 has) while the base model has 3,840 Compared to the massive size of the 5o90 (most are triple and some even quad slot) and high power draw, the 5060s are all dual slot cards which have a TDP of only 180W (20W more than my old 1 GB GTX 460 was rated at)
For those who don't have 2,500 - 3,700 USD burning a hole in their pocket (the latter for the liquid cooled version), this may be a reasonable alternative to still get the advanced performance and features of Blackwell technology (once of course Daz 5.0 is released).
Indeed, I remember when I installed the Iray Server standalone and used the 5090 ... out of 8 workers ( = older versions of Iray) only 1 (the latest after the 2025 update = worker 8) was working with it ... sadly when sending from DAZ to Iray Server via Bridge it automatically gets the worker 6 selected (= older version of Iray)
Nothing to do but wait for Daz 5
Can anyone confirm if DAZ Studio will render properly with a 5070? I know someone who is about to buy a rendering machine for DAZ Studio and he plans on buying a 5070 - just want to stop him if this is still a problem.
The version of Iray included in DS 4 can't use 50xx cards at all. No version of DS will be able to use them until the next major version of DS is released.
Thank you, I will let him know.
Are you sure about that? I thought there was a (perhaps mercifully short) wait for 40x0 support.
I remember there was a long wait to the 20x0 cards in DAZ, a shorter wait for the 30x0 cards, and no wait for the 40x0 cards. I've also read in these forums the iRay with the 50x0 cards dropped all support for the 10x0 cards whichh is why DAZ Studio 4 can't use those cards.
I was thinking of buying one so was watching closely. The first driver with 40 series support broke dforce for everyone but that was fixed fairly quickly and rendering wasn't affected. Iray was later updated to better support 40 series and when that was rolled into DS we got a speed bump of about 15%.
The broken dForce and initial weak-seeming performance certainly ring a bell.