Multiple external eGPUs for 3D rendering

[Xenobius]

I know that there are some limitations in the support of external graphics cards on M processor Macs, but I wonder if it would be possible to use external graphics cards only for 3D computing and rendering – creating drivers using Metal only as accelerators for computing and an external chassis for several graphics cards.
In this case, the image display handling and other tasks requiring very fast memory access would be performed by the Apple processor, and the calculations (3D scene raytracing) could be sent to several external graphics cards. Ideally, this could even be a single enclosure with several Thunderbolt ports and a powerful power supply for several graphics cards.

 

[waloshin]

Unlikely

 

[leman]

I know that there are some limitations in the support of external graphics cards on M processor Macs, but I wonder if it would be possible to use external graphics cards only for 3D computing and rendering – creating drivers using Metal only as accelerators for computing and an external chassis for several graphics cards.
In this case, the image display handling and other tasks requiring very fast memory access would be performed by the Apple processor, and the calculations (3D scene raytracing) could be sent to several external graphics cards. Ideally, this could even be a single enclosure with several Thunderbolt ports and a powerful power supply for several graphics cards.

Even if it were possible to write third-party Metal drivers (it is not), the approach you describe would not have the desired effect. Calculation speed is important, but data transfer is the ultimate bottleneck. Even with the fastest raytracing hardware in the world, the need to continuously transfer the data between the devices would remove any performance advantage you hope for. You can try to change the architecture of your raytracer (for example, defer shading until much later and transfer ray bounce information between the devices), but the performance would be very poor.

 

[Xenobius]

Even if it were possible to write third-party Metal drivers (it is not), the approach you describe would not have the desired effect. Calculation speed is important, but data transfer is the ultimate bottleneck. Even with the fastest raytracing hardware in the world, the need to continuously transfer the data between the devices would remove any performance advantage you hope for. You can try to change the architecture of your raytracer (for example, defer shading until much later and transfer ray bounce information between the devices), but the performance would be very poor.

I'm not talking about raytracing in games or ‘realtime’ applications. I'm talking about 3D rendering in Blender, for example. In that case, data transfer speed is not the key issue. What is more important is the speed of the calculation and the transmission of the result in the form of a render fragment (tile). Thunderbolt enclosures have been and continue to be used successfully for this purpose.

There used to be an approach to this topic for two graphics cards:

ANIMAIONIC – turns your Mac Mini into a Workstation

A docking station for extra graphic cards and SSD drives – long awaited compact alternative to a Mac Pro giant

www.kickstarter.com

and for three graphics cards:

https://www.kickstarter.com/projects/animaionic/animaionic-maximus-brings-three-pcie-slots-to-apple-mac

There are also many enclosures for one graphics card. Unfortunately, there are no drivers for M-series processors. Such external Thunderbolt enclosures work, but only with, for example, PCIe SSDs or PCIe video cards.

I do not know why it is not possible to create a driver for the 'Metal raytracing only accelerator'. Perhaps there is a developer here who can explain this?

 

[Gnattu]

I do not know why it is not possible to create a driver for the 'Metal raytracing only accelerator'. Perhaps there is a developer here who can explain this?

Apple does not allow 3rd party GPU drivers anymore in macOS and the Apple Silicon PCIe implementation is not compatible with most if not all external GPUs

 

[crazy dave]

I'm not talking about raytracing in games or ‘realtime’ applications. I'm talking about 3D rendering in Blender, for example. In that case, data transfer speed is not the key issue. What is more important is the speed of the calculation and the transmission of the result in the form of a render fragment (tile). Thunderbolt enclosures have been and continue to be used successfully for this purpose.

There used to be an approach to this topic for two graphics cards:

ANIMAIONIC – turns your Mac Mini into a Workstation

A docking station for extra graphic cards and SSD drives – long awaited compact alternative to a Mac Pro giant

www.kickstarter.com

and for three graphics cards:

https://www.kickstarter.com/projects/animaionic/animaionic-maximus-brings-three-pcie-slots-to-apple-mac

There are also many enclosures for one graphics card. Unfortunately, there are no drivers for M-series processors. Such external Thunderbolt enclosures work, but only with, for example, PCIe SSDs or PCIe video cards.

I do not know why it is not possible to create a driver for the 'Metal raytracing only accelerator'. Perhaps there is a developer here who can explain this?

Depending on the size of the workload, games make actually perform better on the eGPU than Blender - games are used to having to fit into small VRAM sizes and while latency would be poor, they take up less bandwidth than most professional workloads. Now obviously a desktop 4090 eGPU attached to a new mini will still outperform the base M4, but the point is you won't get the full performance of that 4090, especially for large rendering scenes where the data has to be transferred in and out of the GPU over Thunderbolt.

Writing 3rd party Metal drivers for macOS is maybe not impossible, but it is impractical. Nvidia hasn't been supported on macOs for a very long time and AMD doesn't want to support eGPUs for a fraction of a fraction of users who would use them on Apple Silicon. Further, Apple has made the security model on macOS such that a developer has to jump through significant hurdles to release 3rd party drivers that are beyond the capability of DriverKit (which an eGPU driver almost certainly would be). Basically, Apple has moved towards a unified SOC architecture and wants to focus on that so it has no interest in developing such a driver itself while AMD/Nvidia have no interest in supporting such a small use case. If I remember correctly, plugging an eGPU into an Apple Silicon machine results in ... nothing. It doesn't even recognize that something is pugged in.

There is one possible workaround for this however: the Asahi Linux project (Linux for Apple Silicon). Thunderbolt is still an ongoing project and something like CUDA is not going to be directly supported by the team ... BUT there it is more possible that eGPU drivers written for ARM-Linux will work on top of the drivers the Asahi project has written. But as far as I know, that future is not yet today.

Apple does not allow 3rd party GPU drivers anymore in macOS and the Apple Silicon PCIe implementation is not compatible with most if not all external GPUs

There was considerable debate about this awhile back - about Apple's PCIe implementation wrt normal vs device mapping memory over the BAR as well as Linus vs macOS. I don't know if it was ever resolved. But yes it is possible that even once full thunderbolt support gets here for Asahi Linux, Linux eGPU support (especially for graphics) would be limited or impossible even beyond writing the necessary drivers. And of course, if accurate that could likewise rule out eGPUs on macOS as well depending on the situation there.

 

[Boil]

I know that there are some limitations in the support of external graphics cards on M processor Macs, but I wonder if it would be possible to use external graphics cards only for 3D computing and rendering – creating drivers using Metal only as accelerators for computing and an external chassis for several graphics cards.
In this case, the image display handling and other tasks requiring very fast memory access would be performed by the Apple processor, and the calculations (3D scene raytracing) could be sent to several external graphics cards. Ideally, this could even be a single enclosure with several Thunderbolt ports and a powerful power supply for several graphics cards.

I get where you are coming from, you want to use eGPUs for compute/render tasks, not for display output...

I also would like to see Apple release an ASi-powered PCIe (Gen5 x16, please...) card to be used for such tasks...

One could be working away in Blender on the system SoC, while batching compute/render jobs to the PCIe compute/render card(s)...

 

[Xenobius]

I get where you are coming from, you want to use eGPUs for compute/render tasks, not for display output...

I also would like to see Apple release an ASi-powered PCIe (Gen5 x16, please...) card to be used for such tasks...

One could be working away in Blender on the system SoC, while batching compute/render jobs to the PCIe compute/render card(s)...

This is exactly what I have in mind. To have in Blender, for example, something like this:

 

[mi7chy]

GPU drivers on Apple Silicon MacOS are non-existent and will be the biggest obstacle. Your best bet is trying Asahi Linux on Apple Silicon with Nvidia aarch64 GPU drivers but you'll also need PCIe to Thunderbolt interface and research if Linux aarch64 drivers for that exist.

Blender has built-in support for network rendering so much easier path is acquiring a bunch of M4 Mac Minis and creating a render farm.

Nvidia RTX4000 supported OS

 

[Xenobius]

Your best bet is trying Asahi Linux on Apple Silicon with Nvidia aarch64 GPU drivers

Thanks, but that's not why I bought and use a Mac to install Linux on it - it's a bit absurd. Well ok, it might be interesting as part of some crazy hobbyist project, but not in the context of everyday work.