DAZ via AMD
cheefstick
Posts: 29
Hello,
Apologies in advance if this is a rinsed topic, but with the lack of availability of Nvidia GPUs atm it might come up more and more.
I've had Nvidia cards for the last 10 or so years and started using Daz shortly after that.
I recently had to upgrade my 2080ti which was showing its age for my requirements and as there was physically no way to get one (and as the prices are exorbitant) I grabbed a 9070xt when they released recently. I'm very happy with it, but I had no idea (or completely forgot) that Daz apparently doesnt support AMD cards at all, and falls back on the CPU. Its not a huge problem as I've got a 9800x3d CPU which is still good, but it would be much better with the GPU support obviously.
So the question - is there any way around this these days that's not a massive pain? or is Daz just finally done for me in the main?
Cheers.
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
To be clear, it isn't Daz Studio that calls for the Nvidia card but rather the Iray render engine used by DS. But yes, if you're primarily using Iray, you'll be stuck on CPU. Given that Iray is developed by Nvidia, it's unlikely there would ever be a supported way to use a non-Nvidia GPU.
Iray will not run on an AMD GPU - It's proprietary to NVidia and your system will only be able to render Iray on the CPU. You could add a second graphics card to your system for Iray rendering. That would have to be an NVidia card. Keep in mind, too, that Daz is not compatible with 50xx cards. So, your options would be to find a 30xx or 40xx card that suits you or accept that Iray is restricted to CPU on your system. As a third option, you can export your Daz assets and scenes to another software such as Blender, 3DS Max, Maya or even Unreal for rendering.
No 50 series cards either? yikes. Is that an Nvidia or Daz thing? I know Iray is proprietary, but 3Delight doesnt work either.
Seems like I might just finally be saying goodbye to Daz - I just can't see any benefit if I can't use Iray and the card isnt supported over just using blender/Maya etc instead.
Oh well, it was a good run.
Bit of both.New generations of card don't work with old versions of Iray, so DS has to be updated with new versions of Iray to support each new card series. Problem this time though is that the minimum version of Iray that hasn't got a major bug in it needs a newer compiler that isn't compatible with Daz Studio 4's code.
So people with 50 series cards are going to have to wait for Daz Studio 5 to arrive. (But it has hopefully been expedited with that in mind).
It's all bad news. Richard says the 50 cards won't run until DS5 is released. So, Daz problem. 3DL was always a CPU-only renderer. The bright spot there is, once the bitmaps for a scene are processed on the first frame, the renders can be be very fast. If you use a lot of SSS, environmental reflections, too many raytrace bounces, etc, renders become slow. It's the way of things! Unfortunately, 3DL engine hasn't been updated in a very long time. The language for the version used in DS is obsolete, and there is no way to update 3DL for DS without making people's existing scenes stop working. It's a problem! I think Daz is in a tough spot right now, at least as relates to DS.
Completely speculatiive! We are mushrooms and have no idea whatsoever when DS5 may arrive. As I said elsewhere, could be tomorrow, could be 2030.
I don't think it can be laid at Daz' feet - changing compiler version mid vresion (between 2024.0 and 2024.1) is an nVidia decision, given that 2024.0 had bugs (which is why we are not getting it) would sugest to me that it was a change forced on nVidia by circumstances, and certainly not soemthing daz could have anticipated (and not soemthing they can address without changes that would break all existing plug-ins, hence waiting for the next major version).
Richard, you are presenting as fact something that is pure speculation. What you are saying could not be further from the actual facts of software development. Here are some facts:
There is no where to lay this but at DAZ' feet. And it is 100% something that DAZ could have and should have anticipated because vendors updating their libraries to require a later ABI is absolutely commonplace. Library vendors have an interest in using the latest compiler, and sometimes the latest compiler requires a later ABI version in order to support, say, an important optimization. This is 100% normal, it happens all the time, continuously, and is to be expected, even. What is not normal is that an application developer, that knows this (or at least should know this), would make development decisions that disallow them from upgrading along with the vendor, creating a tremendous point of risk. If the vendor does not follow a major.minor.subminor versioning scheme (where versions with the same major version number are guaranteed to be binary compatible, i.e. what a major version number is supposed to tell its users), then they are not promising, and it should not be inferred, that there is any binary compatibility between those versions. NVidia did not do this, i.e. 2024.x is rather meaningless, and DAZ could/should have known how vulnerable they were.
But even multi-million dollar projects make this same mistake from time to time; I've seen fortune 100 companies do it twice in my career, i.e. they allow the project to become dependent on a proprietary library (in both instances, it was a toolset called RogueWave) that is beyond their control, and then the vendor, for whatever reason, doesn't update their library. And so the entire project can't use the newer compiler that one important library requires (say, iRay) because another important library requires the old one, and you can't have it both ways in the same application.
If DAZ is saying that it'll have to wait until DS5, they're saying that they've resolved that chicken-and-egg-like conundrum. Maybe Qt5/6 now provides the functionality that the offending library previously provided, but we can't know.
There are ways around the problem, like segregating the iRay dependent code in another application compiled witht the new compiler and ABI, have it communicate with the rest of the app compiled with the old compiler and ABI via some Inter-Process Communication method like an Anonymous Pipes (if Windows has those), but that's quite a bit of work if that was not the original architecture.
@TheMysteryIsThePoint thank you for your post. You've added a level of knowledge and insight that is far beyond what I could provide.
...one of the difficulties with going back to 3DL is most content today only includes Iray Shaders which requires having to convert everything to their 3DL equivalents A time consuming task. The other is it being CPU dependent the more cores you have the better and faster for rendering., That actually gives AMD a slight edge as all CPU cores are hyperthreaded whereas Intel's" new generation i7s and i9s split the core count between "Performance" (hyperthreaded) and "Efficiency" (single threads) cores So for example a 16 core Intel Core i9-12900KFCPU only has 24 actual threads instead of 32.
There are more powerful CPUs out like the newer Xeon and Threadripper CPUs but be prepared to have deep pockets. For example a 20 core/40 thread Xeon Silver 4416+ retails for between 1,200 and 1,300 USD while a 24 core/48 thread Threadripper PRO 7965WX retails for upwards of 2,500 to 3,000 USD depending on vendor.(not sure what Daz's core limit for 3DL rendering is (Carrara will handle pretty much whatever you throw at it).
For those thinking about switching, one almost essential plugin is Wowie's Awe Shader System which is makes 3DL capable of producing near photo/Iray quality which includes Global Illumination and Ambient Occlusion. It used to be here in the Daz Store years ago but no longer is.
There is also Pariss' IBL Master (which is still available in the store) which adds Image Based Lighting, is a lot easier to set up as well as faster than UE and works with all 3DL lights including AoA's Advanced Lighting System (Spot, Ambient and Distant lights). Before I had a capable GPU for Iray I tested the same scene same size in 3DL and a copy optimised for Iray and the 3DL render won hands down (about 14 min compared to about 2h:40m for Iray in CPU mode). The quality was also better than with UE.
There is also a thread here that dedicated to 3DL renders and one member there has been posting some really incredible images that use the Awe Shader system.
If it weren't for the necessary shader conversion, I'd go back because that means one less very expensive component as you always need a CPU.
It's late on Friday night here, so I'm in my whiny mode, please take that into account.
I'm not sure how well the "upgrading would break all existing plug-ins" excuse still flies at this point.
Four years ago (at least) they began transitioning to the new Qt libraries. At *that* time, just upgrading would break "all existing" plug-ins.
I assume – perhaps wrongly – that they would have warned all 3rd party plug-in makers of what would be happening as they started upgrading their Dev kits and their own plug-ins.
Assuming – maybe I'm wrong – that every time they upgraded their Dev tools they let 3rd party plug-in makers know and provided them with the upgraded tools as they updated DAZ plug-ins.
Rinse, repeat, maybe every 6 months or every year.
At this point – four years later – you're saying it's still the case that "all" the plug-ins still won't work. It would mean that with four years of development time neither DAZ nor 3rd party plug-in makers have updated their plug-ins to work.
If – unbelievably – this is in fact the case, then "all" the plug-ins will *never* be updated and if it's the plug-ins that are holding back the next big upgrade, then it's never going to come out.
On the other hand, I would think that it's safe to say that after four years of development time any plug-ins thare are ever going to be updated before a final release have been updated.
I understand that some 3rd party developers might not want to update their plug-ins until after a stable release is out, but if that's the case, again, it's a Catch-22 problem where DAZ won't release the next big version because the plug-ins won't work and the plug-ins won't work until the big DAZ Studio release comes out.
At any rate, I can no longer accept that the next major version of DAZ Studio isn't being released because "it will break all existing plug-ins".
I'd like to see the next major release come out and people will be able to see if they want to use it based on whatever plug-ins work or don't work; they may decide that using newer nVidia cards is more important than some plug-ins they may not own or use. Rip the frigging band-aid off already.
Unless there's something else, some other reason? I mean, they had a bare-bones version of DAZ Studio 5 working in August, 2021...
Daz Studio rendering on AMD hardware? Revisiting that topic, huh?
Well, AMD Radeon ProRender, a physically-based render engine has existed for some time (2017? 2018?), and plug-ins are available for Blender, Unreal Engine, 3DS Max, Autodesk Maya, and probably some other applications that I'm not aware of. Works on AMD CPUs and GPUs, and works on processors made by other companies. Can work on Windows, Linux, or Apple machines.
As far as I know, no plug-in for ProRender has ever been developed. We aren't privy to Daz's arragements with nVidia, so we don't know if an exclusivity agreement exists. But, if I were nVidia, I would've insisted on it.
Over the years, Daz/Tafi has made a number of decisions which place unnecessary practical limits on the size of the Daz Studio user base. That's a topic too wide for extensive discussion in this thread.
(That being said, I really like Iray. Switching to Iray as the primary render engine for Daz Studio is the best development that has occurred in the time I've been using Daz Studio.)
...indeed, if they adopted ProRender we would all have to spend time converting shaders like we did for old LuxRender.
Yeah until I can afford to upgrade my system (slow going savings wise) I won't be able to use the next version of Daz, whatever it is called, anyway.
I only called it that this time because that's what it was called back when it was announced and described as a pre-beta.
I'm wondering if the issues are related to this-
https://nvidia.custhelp.com/app/answers/detail/a_id/5615/
It will break all existing plug-ins (and at least some scripts) doesn't mean it will be impossible, where the developer is still alive and active, to update - possibly for free, possibly as a paid-for upgrade - and produce a version compatible with the next major version. I have no idea how much information, beyond what is in the change log, developers who work with Daz have been given but I find it hard to believe that sole-developers, which I believe most are, needing to keep working on new products to maintain their income will feel able to dedicate the time to thoroughly updating until they are fairly confident they have a close to final version.
Daz used to let the ABI change with most incremental updates (in DS 1 and earlier DS 2) and people hated and complained about having to install, or worse wait for, updated plug-ins (to the point where it kept being a source of complaint throughout the later stages of DS 2, through DS 3, and into DS 4) so I don't think it is at all surprising that Daz has delayed breaking the ABI for as long as possible. I have no idea whether nVidia gave them advance notice that this particular breakage was going to occur - though given that they supplied 2024.0 with support for 50x0 cards I suspect it was not planned (unfortunately that release was found to have issues and so it makes only a brief appearance in the chnage log before being removed). I am sure Daz is acutely aware of the problem, and I am sure they were aware of it as a future issue at some point, but it seems that the actual timing was unexpected and/or unhelpful.
The tools to develop render plug-ins are there - two plug-ins were made to support LuxRender, as well as one for Octane. I would not be remotely surprised to find that Daz had to agree not to directly provide a plug-in for rival engines but there is certainly no obstacle to a third-party providing an AMD Pro Render plug-in (which would need to be reworked for the next major version of DS).
I am not entirely folowing - you seem to take exception to my aside saying that nVidia may have had to change the Iray plug-in due to circumstances, then seem to say the same yourself. My aside was just an "it may be just one of those things, not a deliberate choice" to try to avoid any finger pointing, and I don't see anything in your reply that actually conflicts with that. The comment on versioning (2024.0 to 2024.1) was purely me, and may or may not be beside the point.
Changing the ABI inconveniences users, and daz has tried to avoid doing it. That doesn't mean they cannot make chnages to update the ABI, and indeed the next major version will (as did DS 3 and DS 4) but, as noted in my previous reply, such changes are a pain for end users and also for the small or single-person teams that develop most third-party add-ons (Daz always updates its plug-ins, even for minor versions, so clearly they will have no great trouble). Over the Daz Studio life-time this policy has been friendly towards users and add-on developers, rather than the reverse. Now we have a significant breakage (though I have to say that as yet the wait for 50x0 support seems to have been shorter than the wait for some previous generations); however, based on the limited evidence available to us it does look as if the timing was something of a surprise (again, nVidia did release a version of Iray that would have supported 50x0 architecture in 4.x.x.x so this situation developed in a very short period).
I was planning to upgrade or build anew this year myself (this PC has had oddities for a while, and I have had a freeze and a crash while rendering over the last couple of weeks) so, gien that higher capacity models of the older cards seem to have largely vanished, I too am waiting for 50x0 support and hoping that my system doesn't outright fail before it appears. I am sure that Daz is very aware that voluntary and involuntary system upgrades (or new users with new hardware) will be an increasing problem for DS Iray, and will be working as they can to address the issue - but I am also confident that they were aware of this as a potential issue, but cannot simply do a handbrake turn when there are so may other parties that need to be carried along now that it the potential has become actual.
Okay, then if it was going to break all existing plug-ins 3.5 years ago, and it's still going to break all existing plug-ins today... then I don't see any time in the future when it won't break all existing plug-ins, so I have to ask what the benefit is -- if all existing plug-ins are going to break whenever "The Future DAZ Studio beyond version 4.x" is released anyway? Waiting another year, for example, isn't going to make the problem go away, there'll just be more plug-ins that will break. The problem is slowly getting worse, not better by waiting.
That said... 3.5 years ago DAZ was willing to release a bare-bones, almost-nothing-worked version to allow Mac users to use DAZ Studio with the then-year-old OS. Since then, you've said that DAZ has been adding new features to that version whenever one was added to the released version of DAZ Studio. That means that by now much, if not most of the missing features in the pre-Beta should be working 3.5 years later (most, that is, if not all) and all *new* features that were added to the releae version of DAZ Studio 4.x.
I propose that they release a DAZ MAC-ONLY FILAMENT VERSION OF DAZ "NEXT GEN", so that Mac users can work with Filament and Filitoon while DAZ continues work on a version that works with newer nVidia cards. I'd be willing to pay for that.
and the enxt major version will, as has been stated, break plug-ins - I am not sure where the debate is? They have been trying not to do so before it is required, hopefully both allowing them to refine their work on the next major version and delaying the moment when people will have to juggle which version they use for what unless/until all their tools are updated.
True, though one may hope that the next major vrsion will also have new stuff to get people (other than the captive audiencs like 50x0 owners of Mac users wanting Fialement) to use it to give the (likely) Public betas a good going-over.
No debate, and my apologies, it's totally my misunderstanding.
I have wrongly thought that not releasing the next major version because broken plug-ins was a problem they were trying to fix, but you're explained clearly that this is not the case, that no matter when the next major release comes out plug-ins will all break. That's totally on me, and again, my misunderstanding, my apologies.
For years, giving Mac users improved performance, the use of Apple's Metal in the user interface and Filament and Filitoon hasn't been important enough to release a version that will break plug-ins, even if people could still use DAZ Studio 4.x too.
Hopefully giving owners of newer nVidia cards faster rendering will be enough of a reason.
After having spent over $65k here at DAZ over the years, I started holding myself back after a few years without the next major update having come out and it wasn't until this month that – for no good reason – I felt a bit of optimism and fell back into my old spending habits and dropped over $500 this month, mainly on Filatoon items and licences. I think I'm cured now, and I'm going to try hold back on any purchases until the next major version comes out and only if it proves worth waiting all these years for. I'm going to hold off on griping on the forums as well; as cathartic as it sometimes is for me personally, I recognize that it's not all that helpful for everyone else.
As always, Richard, thanks for your patience and help explaining things, you're easily one of the best and most reliable assets DAZ has.
Off to more creative endeavours...
You're very welcome, I just wish that us knowing somehow contributed to resolving the problem.
Wow, that's interesting. I am not Windows savy enough to tell if DAZ Studio is using 32 bit code while it runs, for iRay. I sincerely hope you are wrong :) but it does seem to track the evidence you found...
Correction from previous comment aboive. .
...for those who may still be interested in 3DL, The Awe Shader System plugin is not on ShareCG but on Renderosity's Freebie page.
If I took exception it was because you failed to explicitly recognize that a library vendor upgrading their compiler, and that occasionally means their ABI, is not some Black Swan event, but rather the constant heartbeat of progress in Computer Science. It is to be expected and must be accounted for.
And thinking that "2024.0 to 2024.1" may be "beside the point" is indicative. It is not beside, the point, it is the point. It is NVidia reserving the right to break the ABI at any time. A guarantee of stability would have taken the form of iRAY version x.y.z where as long as the major version is x, the ABI is guaranteed not to have changed.
No. A thousand times, no. Changing the ABI makes literally everything better. It's how software evolves to take advantage of all the advances in the evolution of Computer Science as a field. The apologetics that I objected to is that DAZ isn't trying to avoid doing it for the benefit of their users, it is that DAZ has created an ecosystem with policies that make it impossible to do it. This is not speculation. Exhibit #1: an SDK that exposes static header files to link directly against, guaranteeing that plugins break. As a plugin developer myself, this is awesome in certain ways (you just #include the headers, link the provided libraries and you're off to the races), but that requires the plugin developer to recompile his code against the new SDK whenever cerain changes are made to them that change the order of the symbols in them. That is why the SDK lags behind DAZ Studio development and plugin devs wonder why certain things are in the scripting but not the SDK: the scripting language, being an interpreted language, has a dynamic interface and so moving things around doesn't break anything. DAZ doesn't want to force plugin developers to have to recompile their code as some of them aren't able to do so. The solution on Windows would have been a Component Object Model like Microsoft's COM, but that would have raised the bar of technical expertise necessary to write a plugin. I admit that it's kind of nice to just compile, link, and go.
Changing the ABI is not something that end users should ever even be aware of. If the manufacturer of the car you drive decides to change the fuel injectors, should you know or care? If it is a pain for end users, it is the result of poor technical choices, one of which I've described above.
Sorry to hear that. I hope your system hangs on, and that DS5 ultimately addresses these issues.
It is beside the point because it was me inserting a passing thought, not any kind of official Daz line. It is, however, somewhat relevant that nVidia did, manifestly, intend to support the 50x0 series in a version of iray that would work with DS. This is an abrupt change, not something announced in advance (as nVidia usaully do, for example when announcing that a line of GPUs is deprecated and will not be supported in future versions of Iray).
I will assume you joned too late to recall the days I mentioned earlier, when the SDK did get updated and people did have to reinstall plug-ins? Daz has learned the hard way that real end-users want stability and so they pursue a development strategy that delivers it. Remember, too, that plug-in developers are mostly single-person teams (or at least, single-coder).
And do third-party components survive such updates? Do simpler products than cars, which allow end-uer maintenance, use custom parts that chnage with each model? Some do but I suspect they are not well-regarded as a result (think ink cartridges - and think how the public views the ink-catrridge manufacturers). Daz Studio needs to support, and maintain compatibility with in as far as I can, a very wide variety of content of various types - cars just need to be sticker-friendly.
What we really need is an unsanctioned driver that makes the AMD card appear to be an nVidia graphics card.
To what end? Your computer thinking that an AMD card is actually an NVidia card won't magically give your AMD card the proprietary technologies that make Iray acceleration possible.
Richard, I'm going to say this as directly as I can, OK? Because instead of understanding the facts of software development, you keep defending objectively bad technical decisions. So, here we go: If DAZ wanted to give end users the stability they crave, the last thing they should have done was to publish header files in the SDK. Why? Because it guarantees that certain changes to the API will break the plugins that are compiled against them. If you peruse the SDK forum, you'll have noticed that there is no C++ API for some of the latest goodness in DAZ Studio. This is the reason why.
The point I raised that you seem to be ignoring is that this poroblem has already been solved, DAZ just didn't utilize it. The technique is called Component Object Model, and Microsoft has had their flavor of it for decades. They call it COM. With it, client apps can query the component for the interfaces it wants to use, and build them dynamically at run time, much like DAZ Script does. Many other facilities, like DCE RPC, ONC RPC, CORBA, and Java Beans do this. DAZ Studio doesn't, and here we are.
You are (perhaps) inadvertently further proving my point. Having "to support and maintain compatibility with in as far as I can, a very wide variety of content of various types" is pretty much how every book on Component Architecture begins, verbatim, by stating the problem that Component Architecture is meant to solve. If that was DAZ's aim, then they chose the absolute worst way to try to implement it that I can think of, the technique that would make that absolutely impossible to achieve: making public the header files that describe C++ code's static interfaces.