You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A user may acquire a GPU connected over Thunderbolt 3 to speed up image generation. This is fully supported by macOS.
If an program doesn't support setting the GPU, Apple offers a UI element in "Get Info" for the app to prefer an externally connected GPU over the built-in integrated GPU or discrete GPU.
Because Diffusion Bee launches a subprocess to execute the actual image generation, something breaks here and the eGPU such as RX6900XT is not preferred over built in Pro 460.
There is no appropriate flag selectable on the Mach-O binary itself. I am not sure whether it's settable as an xattr on the filesystem or if it will be respected.
The only way to have macOS 12.6.x default to external GPU is to "move the menubar" in Displays preference pane to a make an external display the primary one, then relaunch the app. In my case, this speeds up from 6.8s/it to 0.5s/it -- but this requires having an external display connected.
Of course, often I will not have an external display plugged into my eGPU, or may prefer not to push WindowServer or other processes onto it (leaving its full power for use with DiffusionBee or similar). It would be ideal if DiffusionBee propagated whatever flag is required to the diffusionbee_backend process, or if it allowed picking the GPU to be used to compute.
This is what Final Cut Pro allows, and having the UI element available would make some sense; after all, the use case is different from, say, gaming and doesn't require painting the realtime-rendered image on-screen.
I am unaware of any possible changes in behavior in macOS 13, or how this would be affected in a prospective CoreML backend (#371, #344, #370), but it doesn't apply to me anyway, since I cannot install macOS 13 in a supported fashion onto my T1-based MacBook Pro 2016. For the same reason, I cannot test if the relevant GPU choice flag propagates correctly in macOS 13.
The text was updated successfully, but these errors were encountered:
A user may acquire a GPU connected over Thunderbolt 3 to speed up image generation. This is fully supported by macOS.
If an program doesn't support setting the GPU, Apple offers a UI element in "Get Info" for the app to prefer an externally connected GPU over the built-in integrated GPU or discrete GPU.
Because Diffusion Bee launches a subprocess to execute the actual image generation, something breaks here and the eGPU such as RX6900XT is not preferred over built in Pro 460.
There is no appropriate flag selectable on the Mach-O binary itself. I am not sure whether it's settable as an xattr on the filesystem or if it will be respected.
The only way to have macOS 12.6.x default to external GPU is to "move the menubar" in Displays preference pane to a make an external display the primary one, then relaunch the app. In my case, this speeds up from 6.8s/it to 0.5s/it -- but this requires having an external display connected.
Of course, often I will not have an external display plugged into my eGPU, or may prefer not to push
WindowServer
or other processes onto it (leaving its full power for use with DiffusionBee or similar). It would be ideal if DiffusionBee propagated whatever flag is required to thediffusionbee_backend
process, or if it allowed picking the GPU to be used to compute.This is what Final Cut Pro allows, and having the UI element available would make some sense; after all, the use case is different from, say, gaming and doesn't require painting the realtime-rendered image on-screen.
I am unaware of any possible changes in behavior in macOS 13, or how this would be affected in a prospective CoreML backend (#371, #344, #370), but it doesn't apply to me anyway, since I cannot install macOS 13 in a supported fashion onto my T1-based MacBook Pro 2016. For the same reason, I cannot test if the relevant GPU choice flag propagates correctly in macOS 13.
The text was updated successfully, but these errors were encountered: