Making the most of a 30-day trial of Autodesk’s Flame.

Flame is really the ultimate badass in finishing work, where all the elements of a TV show or commercial, or even FX shots on a feature film come together and get baked out in all the different resolutions and formats required to deliver it to a client for broadcast, stream, or theatrical release, or whatever else they can think of.

To that end, Autodesk lets you drive it around for 30 days before they hit you up for a subscription, which is substantial, so if you’re attempting to learn it, best not to fuck around and waste valuable days while the 30-day death clock is ticking.

That said, unless you’re using a workstation that matches the spec from Autodesk, you WILL fuck around, and that will consist of getting it to run right on a PC designed and configure for something else, or as a general-purpose machine, and that is where the tears begin. A game dev PC is not the same as a CAD PC, or a 3D VFX PC, although they may share some components.

This isn’t meant to be a tutorial on how to bring up and install the Flame Trial version; the internet is full of those. This is just my adventure in getting it to run when I want to run it.

The Machine

Flame runs on Linux or MacOS, assuming you have strong enough hardware to support it, and there are some steps to configuration and setup that I found both through the ADSK Knowledge Base, the Logik.tv forum, and the Internet in general.

My workstation is a game dev box that I spec’d and built for working with Houdini and Unreal Engine 4. It was not a godbox, but it held its own in terms of speed and capacity. These are the highlights, and this machine is now 2 years old:

• AMD Ryzen 9 3800 12-core
• 128GB DDR4 RAM
• Nvidia RTX 2070 Super
• Samsung 980 M.2 NvMe 1TB SSD
• Samsung 850 SATA 500GB SSD
• Seagate Ironwolf 4TB Enterprise HDD

This is a modest rig, but it’s got more than enough juice to push HD video around, which is fine for learning Flame. If you try to do production shot work with a trial version and a mid-range PC, there is a strong chance it will not end well.

Setup

The Autodesk site has good info about how to download and install the trial version, but this is where the pain begins. If you’re not terribly tech- or linux-savvy, this is going to sting a bit. Plan on having a completely dedicated PC for this exercise, even if it’s not Flame-spec, because that’s the safest option.

Of course, because I’m a complete masochist, I had to do it the hard way. This is what I wanted at the end of the day:

• Windows on one SDD
• Flame/Linux on the other
• Dual-boot configuration
• Flame running on a single GPU and one monitor
• Wacom tablet supported

The first red flag here is the AMD Ryzen CPU: It’s not supported or tested with Flame, and sometimes Linuxes require kernel and other low-level patches for stable operation. That’s rare, but it’s worth mentioning.

Linux

TL;DR

• Choose the Manual partition installation option in the boot menu, or else.
• Create new user with admin permissions
• Configure networking and hostname
• In the storage configuration,
  • uncheck all drives except the one you intend to install on
  • allow automatic configuration of partitions

Making a dual-boot Linux/Windows configuration is not a big deal. You get one of the CentOS disk images that ADSK links to and make a bootable USB drive with it. Make sure your USB drive is USB 3.0, or you’ll be waiting a long, long time for the install to finish. I’m not going to go into making a bootable USB drive or setting up dual boot, that’s only a google search away.

What I will warn you about is this: when you boot off the USB drive to install CentOS, there’s a 3-second timeout before it goes for the default option, which is “Install Autodesk Flame Workstation” and by the time you’ve read through the options, time’s up.

This is the border checkpoint for the Land of Pain.

The first thing the default “Install Autodesk Flame Workstation” option does is find the NVME SDD and overwrite the boot partition. If that’s where you already put Windows, see you later alligator, in a while crocodile, don’t forget to write.

So it is of MAJOR IMPORTANCE that you choose the ‘manual partitioning’ option if you want to have a prayer of preserving an existing OS install, especially if you want to choose the drive it installs on. If you catch it fast enough (you probably won’t), maybe you can rescue the Windows install by booting into a Windows Live USB drive. If you have one.

In the manual config option, it’s not just the partitioning that’s manual. You also need to create a user with admin privileges, and you need to set up networking and a hostname for the machine, otherwise you won’t be able to log in after the install (dumb UX and workflow).

DKU

“DKU” means ‘driver and kernel updates,’ and this is a .tar file which is obtained from Autodesk. Plenty of docs on their site about it, but the point is, the DKU contains all of the additions to Linux that will enable Flame to run. Some are proprietary, some are not, including the Nvidia drivers known to work with Flame and CentOS.

The DKU installer looks for some specific hardware configurations, and those are the ones that Autodesk has tested and will support. If your hardware isn’t one of those, you’ll get the generic configuration.

You’re supposed to reboot after installing the DKU and set up all the display settings before moving on to the next step and configure your display settings and verify that the display driver is working.

Once you reboot after the DKU install, in a terminal, type nvidia-smi and you should be rewarded with diagnostics about the graphics card and the status of the driver. From here, you can use nvidia-settings to configure your display resolution, refresh rates, and color space.

Don’t spend a lot of time noodling your settings: the next step is going to pack your configs full of stuff that essentially trashes your display configuration, prevents you from graphical login, and hangs you up on shutdown if you don’t have an Autodesk-approved workstation.

At least that’s what it did for me.

On this page, there’s a description of how the DKU modifies xorg.conf to suit Flame’s needs. I added a lot more trouble for myself by choosing the –forcexorg option, which stomps everything the generic configuration has into the xorg.conf file. As a result, I had a bunch of entries in xorg.conf that I didn’t need, most of them having to do with generic devices and monitors.

Don’t do that. Use xorg.conf sparingly.

So before the next step: Back up /etc/X11/xorg.conf so you can restore it later. There might be bits you need. The xorg.conf file is becoming less and less the hub of configuration of all things graphics, but it’s still the law on a Linux system. That means it’s important to keep the cruft out, as well as only having correct configurations for the hardware available.

Now take a look at xorg.conf and make sure your hardware is there and ready. I had entries for Tangent controllers, a Wacom tablet, generic monitors, dummy GPU’s, and multiple GPUs. It was truly a mess.

Also, the Screens 0 section was pointing at a nonexistent display and graphics device. Post-install, I’ve made my xorg.conf file look like this:

Section “InputClass”

# Option “Rotate” “HALF”
# Option “ScreenNo” “0”
# Option “TwinView” “horizontal”
Identifier “touch”
MatchDriver “wacom”
Option “Touch” “off”
EndSection

Section “Monitor”
Identifier “Monitor0”
VendorName “Unknown”
ModelName “KJT4K2K60DP”
HorizSync 135.0 – 135.0
VertRefresh 30.0 – 60.0
EndSection

Section “Device”
Identifier “Device0”
Driver “nvidia”
VendorName “NVIDIA Corporation”
BoardName “GeForce RTX 2070 SUPER”
EndSection

Section “Screen”

Identifier “Screen0”
Device “Device0”
Monitor “Monitor0”
DefaultDepth 24
Option “Stereo” “0”
Option “nvidiaXineramaInfoOrder” “DFP-0”
Option “metamodes” “3840×2160 +0+0”
Option “SLI” “Off”
Option “MultiGPU” “Off”

This configuration appears to work, and persist through reboots. Bottom line: Linux uses the drivers it has on the hardware available and doesn’t go looking for other stuff.

Installer

This actually installs Flame on your system and configures all the components in a way that lets you launch Flame from either a terminal or the Activities launcher in CentOS. Supposedly.

The CentOS desktop experience is garbage, by the way, and because Autodesk did whatever they could to ensure that Flame runs right, none of the external repositories are available so you can get the tools to tweak your desktop the way you like it. There is a ‘Tweak’ tool available, but the T is silent. It will be very difficult to get close to the UX of MacOS or even Windows.

Once you run the installer, you should be able to light up Flame via the Activities menu or from a terminal window, which is less annoying. Either way, you’ll be able to launch Flame and you should be able to begin using it.

Once.

When you reboot, there’s a good chance you might not see your desktop again, for various reasons. The Flame configuration page at Autodesk has a whole lot of good info on how to configure your storage and configuration, but there are some pieces missing that would have been nice to know.

Case in point: When the window manager can’t start, you can’t use the graphical tools Autodesk points you to for configuring both Linux and Flame. So you go hunting, and you operate through a command line terminal.

Of course Autodesk chose one of the more obtuse and no-fun linux variants out there. It’s not like Ubuntu, where the community support is wide-ranging and pervasive, but it has its advantages. I just don’t know what they are.

This just meant that on-the-fly debugging and learning the ins and outs of a linux system in order to troubleshoot a free trial install was far more than I had bargained for. Not only that, the custom CentOS Linux distribution locks down the system so you can’t install updates or extra packages. Smart, I guess, but it leaves just-slightly-beyond-casual Linux users high and dry.

This is the capital city of the Land of Pain. I had to figure out an unfamiliar Linux variant, then all of the changes added by the DKU and then by the installer. By the time I had completed the installation instructions to this point, I had a system that would not boot into graphical mode and hung up for multiple minutes prior to shutting down or restarting. I also had a Windows 11 installation lost as collateral damage.

I’m not a sysadmin, not even remotely, and it’s only because I grew up in the days of Silicon Graphics workstations that I have at least the substrate of knowledge required to do this, albeit badly.

BIOS

• Disable CSM in boot menu
• Enable “Decode above 4G” for PCI devices
• Disable “Resizable BAR” support for PCI devices.

I’m not really sure if this helped, but as soon as I disabled CSM in the BIOS, stuff started working better. Unscientific at best, but the only reason to have CSM enabled is if you

• Have more than one Windows installation
• Have any OS installations that don’t boot from an EFI partition.

I suspect, but I can’t confirm, that prior to disabling CSM, the window manager was attempting to initiate at a resolution lower than any mode available in the xorg.conf file. In reality, you should only need CSM enabled in your BIOS if you want to run an old, non-EFI version of Windows alongside a newish, 10+ version.

There were actually 3 BIOS misconfigurations causing the similar symptoms, and the other one was in the advanced PCI settings.

“Resizable BAR” is intended to optimize performance in Nvidia’s RTX 30+ series and up graphics cars. I have a RTX2070 Super, so that needed to be turned off. It’s enabled by default in my BIOS. “Decode above 4G” needed to be enabled also. I don’t know what it was, but until I changed both of those settings, the Nvidia driver couldn’t initialize during the boot process.

You won’t see that from the screen output. I found it by ssh’ing into the stuck machine and using the “dmesg” command to see what was happening. Anything that looks like “NVRM: RmInitAdatpter failed!” means the above settings are probably not right.

Xorg.conf

My native res is 3840×2160 with a refresh rate of 60 (59.98)Hz, and in /etc/X11/xorg.conf, the device, monitor, and screen sections are configured to that spec. I don’t even have a 1920×1080 mode available, although I should add one, just in case I score a second monitor and run it off the HDMI port or one of the other DisplayPorts.

As explained in the previous step, the xorg.conf file should only contain the minimum necessary.

Monitors

The Flame installer generic configuration assumes you have two monitors. Doesn’t everybody? The typical configuration for Flame ops seems to be a workspace monitor, alongside a 4k+ HDR, wide-gamut, calibrated monitor that’s supposed to be the reference view for what will ship to the client.

I don’t have one of those. I have a single, massive, 43-inch 4k (UHD) monitor that I got because I didn’t want to work across 4 separate HD monitors or use one of those idiotic curved ultra-wide gamer monitors for real work.

In /opt/Autodesk/flame_2022/cfg/init.cfg I set the SingleMonitor keyword to “Yes.” I don’t know how or why, but this change allowed the Linux window manager to show up on the single monitor in front of me.

I don’t know if this change modifies xorg.conf or not, but I do know that when this was changed, the system didn’t start the window manager on a nonexistent display.

NFS

Flame likes to be in an ecosystem where there is some kind of network-shared storage, like a NAS or other Flame workstation, sharing out the contents of its filesystem over the network. It uses the Linux NFS daemon to look for and share network volumes.

The problem here is the problem that has always made NFS a pain in the ass: If a shared network drive is not available to mount or unmount, the NFS client and service will wait a default or configured amount of time before giving up.

In my last few install attempts with Flame, as soon as the installer is run and the machine is rebooted, NFS causes the system to hang until all the timeouts are expired. On shutdown, this was about 3 minutes. Depowering a machine in the middle of NFS ops is generally not a great idea, as you might imagine.

In a Flame installation, the file /etc/exports has two entries that look like this:

# To improve performance in archiving using NFS, use the parameter ,async, instead of ,sync,
# DO NOT use async parameter on the /opt/Autodesk path to avoid potential corruption.
# Please, refer to the man page on exports, for more details on the async parameter.
/opt/Autodesk *(rw,sync)
/mnt/StorageMedia *(rw,no_subtree_check,async)

The last two lines are local directories that NFS is making available as shared volumes.

/mnt/StorageMedia is the default mount point for where Flame looks for images, movie clips, stuff like that. This is set by the installer, but the installer can’t know where you intend to keep that stuff, so it’s just a dangling mount point, which causes the system to hang until the timeouts expire. Not only that, you can’t configure it if the system won’t boot into graphical mode.

In my configuration, I commented those two lines out of /etc/exports after the installation. I also disabled the NFS service via systemctl disable nfs-server.service and that pretty much put a spike in any NFS-related hangs. Yes, I know, changing more than one thing at a time is bad debug practice, but now I can start turning things on again and see which thing is actually the problem.

Conclusion

This shit is definitely not for the faint of heart. I am neither a professional Linux sysadmin or a professional Flame operator, but I can only imagine that sinking-stomach, totally-fucked feeling someone might get if they’re freelancing remotely, alone in the middle of nowhere (because we can do that now) and the workstation packs up in a spectacular and catastrophic way. I have had that feeling before, and it sucks.

I now know enough to (kind of) troubleshoot a Flame installation, at least enough to recover from said catastrophic failure and hand off the work. Still, if I was using Flame to earn a living, I’d opt for a configuration closer to the Autodesk-blessed spec, because the whole point of high-speed compositing and finishing is to keep things moving, quickly, without fussy tech issues interrupting the workflow.

So what did I learn? In no particular order, and by ‘learn’ I mean ‘understand well enough to debug or make intelligent Google searches’ —

• UEFI BIOS configuration for different types of operating systems
• GPT vs MBR disk partition types
• Xorg.conf entries
• NFS exports
• GRUB boot sequences, commands, and troubleshooting
• CentOS 8.2 installation and manual disk partitioning
• Creating and moving logical disk volumes with command line tools like parted and lvm tools

Now it’s time to actually learn Flame with my 28 days left of trial.