“Gaming card” ? really? 
on windows site its studio drivers and I would not call RTX 3090 just a gaming card. I use it everyday with DaVinci Resolve/ Fusion and Softimage XSI - looking into learning more about Flame to see if I can integrate it into my pipeline -
why can’t you provide more details on the issue? why can’t you be more transparent about information like this. If there are “very good reasons”, don’t you think you should share this with us?
It’s incredibly important information and its frustrating that users have to go out of their way and spend their money and time to find things out themselves.
2 Likes
Oooorrrr, you can just go with approved cards.
I too would be interested in hearing the negatives of the 3090 and cards like it. From the community benchmarks it looks like the 3090 (and presumably the 3090 ti) might be the fastest card for flame even beating the A6000 (prob due to faster memory??). The lines seem to be blurring between gaming and professional cards these days.
1 Like
I don’t know about Flame because I am just starting to gather all the info and to try demo version - but I think there could be a benchmark that tests all aspects of Flame function to see if certain driver/card combo passes this test. I don’t know if something like this could be cooked up by the community here especially now that Flame looks to be more open to smaller studios and individuals. I have a feeling that Flame can follow the path of what Resolve became open and easy to access by most.
1 Like
It works now but I dont get a proper “icon” for Blender… how did you installed it?
Since a new install of Rocky Linux 8.5 Autodesk ISO Revision2 I am not able to use the method above to update the driver. Maybe Autodesk OS ISO have changed something on the kernel unloading in Revision2 of the RL8.5? Revision 1 of the same RL8.5 few months ago did not have this issue as I was able to use the method above to install new drivers. Anyone know of other methods to make it work? Look at the original thread I have posted there some screen shots
Hmm, that’s not good. I had to use this method to get my system to work a few months back when the DKU driver install failed and trashed the system. Definitely hoping we can sort this out.
On the original question of the 3090 being a gamer card, I did a lot of looking into that question two years ago when testing cards for Mistika, and SGO is quite knowledgeable and willing to share in that space. Back then it was the 2080 vs. the Quadro 6000. And I asked them when choosing between a 3090 and the A5000.
Back in the days of the 2080 vs. Quadro, there was a single hard difference on the hardware level, which is that the 2080 had a single copy engine vs. the Quadro cards had two copy engines enabled. In our use cases that matters, because the software has to copy textures onto the card, process, and then offload to send them to DeckLink or AJA (assuming you use that). Which is different than regular UI/Gamer setups where the texture stays on the card and goes out direct to display port. So can make a significant performance difference when you work with RED 8K footage, etc. As of the 3090/A5000 that difference has disappeared and on a hardware function level the cards are equivalent.
So the difference is mostly with how the boards are made, clocking, heat, etc. Many 3090 cards may have mods that favor performance over stability. The Quadro/A-series always being considered to be more reliable in terms of MTBF.
And the biggest difference is the drivers and what they do. The gaming drivers turn over much more frequently and don’t go through the same QC cycles as the workstation drivers which go through MSFT’s qualification cycles. I think this is the part that ADSK maybe most concerned about, that a different driver may turn up that has some feature changed or enabled that Flame isn’t prepared for and then causes issues that invariably turn into time-consuming goose chases and tickets. Understandable to a degree.
But if you lock it down, then the install process has to be ironclad, and also it means DKU on reference system or your SOL. I think there are still quite a few of us that use slight deviations of configs for various reasons. In hindsight I may opt for a certified config on my next system, even though I have a long history with Puget.
System availability continues to be an issue if you need something on short notice. And Apple’s roadmap is a mess at the moment both in terms of availability and good investment ROI. The M1/2 GPU side is not fully mature yet to bet the farm on, and nobody in their right mind would buy an Intel MacPro right now unless you can write it off in a year or less. Plus there are ML and other benefits to NVidia cards which Mac continues to lock you out from. If you try to do CopyCat/Nuke on the same system, you need an NVidia card. That limits your choices.
So if ADSK want to be tight with their DKU, then they should make it easier to have a broader certified config list. I would be quite happy to lobby to get Puget on the certified config list if that’s feasible, as they build high quality systems that have a slightly different take than your stock Dell/Levono systems which tend to be space efficient but loud and not always optimal from a slot config for other additions.
Or give us Windows as an OS choice. That would solve a lot of the install problems and be independent of Apple madness. Though I completely understand why this has a negative probability of ever happening. Even though ADSK is one the last hold-outs of the Linux turn-key providers and other major video apps that hasn’t sorted this, even among apps that have background processes and other Unix affinity in their architecture. The M1 native exercise should have yielded a very usable inventory of dependencies and work item list if that were ever considered. So the timing would be optimal, though it would set us far back on other features in terms of dev cycle time on infrastructure vs. features.
1 Like
What I did I went back and installed Autodesk Rocky Linux Rev1 ISO and then updated after DKU but did not use the latest drivers used 510.73.05 instead of 515.76 and it did not complain. So I am not sure if the driver or Rev2 distro was the problem.
He’s referring to the ancient NVIDIA driver not working using optix in blender [doesn’t work on Maya/Redshift either - never mind all kind of glitches on rocky Linux using autodesk flame driver with dku17.3] – not the hardware. I have an A5000 installed–