#Installing v3.0.1rc1 on Macbook M1 using automatic installer uses wrong platform (Darwin-arm64)

6 messages · Page 1 of 1 (latest)

delicate kindle
#

Hello all, I hope this finds the right person on the InvokeAI team.

So I have been trying to install the new 3.0.1 RC1 on my Macbook M1. Ran into an issue where the venv was picking up the /opt/homebrew install of my python3, which was at 3.11.4_1 and so it wouldn't install. Even though my shell was running a manually installed python 3.10.9, which is what you recommend in your install documentation that we use. Anyway, I resolved that by uninstalling 3.11 from /opt/homebrew and installing 3.10. And it actually managed to seemingly fully install the new InvokeAI!

But, all was not roses. While SD 1.5 worked, and 2.1 gave weird results, SDXL 1.0 gave an error indicating that it was trying to use float64, so I did some investigation, and reran the installer. That was when I noticed it say:

'Your platform Darwin-arm64 only supports the "cpu" driver.' Proceeding with that. So it seems to be picking the wrong type of platform. Not sure why. I'm on a Macbook Pro M1 16" with 32GB memory.

Any ideas?

Thanks in advance

#

Here's the output in the console when I try to generate an image with the SDXL 1.0 model:

[2023-07-27 22:16:36,145]::[InvokeAI]::INFO --> Loading model /Users/---/invokeai-v3-isolated/models/sdxl/main/stable-diffusion-xl-base-1-0, type sdxl:main:unet
0%| | 0/50 [00:00<?, ?it/s]
[2023-07-27 22:16:56,817]::[InvokeAI]::ERROR --> Traceback (most recent call last):
File "/Users/---/invokeai-v3-isolated/.venv/lib/python3.10/site-packages/invokeai/app/services/processor.py", line 86, in __process
outputs = invocation.invoke(
File "/Users/---/invokeai-v3-isolated/.venv/lib/python3.10/site-packages/torch/utils/_contextlib.py", line 115, in decorate_context
return func(*args, **kwargs)
File "/Users/---/invokeai-v3-isolated/.venv/lib/python3.10/site-packages/invokeai/app/invocations/sdxl.py", line 340, in invoke
noise_pred = unet(
File "/Users/---/invokeai-v3-isolated/.venv/lib/python3.10/site-packages/torch/nn/modules/module.py", line 1501, in _call_impl
return forward_call(*args, **kwargs)
File "/Users/---/invokeai-v3-isolated/.venv/lib/python3.10/site-packages/diffusers/models/unet_2d_condition.py", line 793, in forward
timesteps = timesteps[None].to(sample.device)
TypeError: Cannot convert a MPS Tensor to float64 dtype as the MPS framework doesn't support float64. Please use float32 instead.

[2023-07-27 22:16:56,823]::[InvokeAI]::ERROR --> Error while invoking:
Cannot convert a MPS Tensor to float64 dtype as the MPS framework doesn't support float64. Please use float32 instead.

delicate kindle
#

Ok, I think I found the workaround in this bugfix!! Hopefully it gets into the next release candidate:

https://github.com/invoke-ai/InvokeAI/pull/4040/files

I manually edited the file in question in the .venv/ directory within my invokeai root directory, and restarted invokeai and was able to use SDXL on Mac M1! Woot!

GitHub

What type of PR is this? (check all applicable)

Refactor
Feature
Bug Fix
Optimization
Documentation Update
Community Node Submission

Have you discussed this change with the InvokeAI team?

...

#

Ok so while the SDXL 1.0 model works, the refiner now fails with:

[2023-07-27 23:36:04,584]::[InvokeAI]::ERROR --> Traceback (most recent call last):
File "/Users/---/invokeai-v3-isolated/.venv/lib/python3.10/site-packages/invokeai/app/services/processor.py", line 86, in __process
outputs = invocation.invoke(
File "/Users/---/invokeai-v3-isolated/.venv/lib/python3.10/site-packages/torch/utils/_contextlib.py", line 115, in decorate_context
return func(*args, **kwargs)
File "/Users/---/invokeai-v3-isolated/.venv/lib/python3.10/site-packages/invokeai/app/invocations/sdxl.py", line 552, in invoke
scheduler.set_timesteps(num_inference_steps, device=self.scheduler.device)
AttributeError: 'str' object has no attribute 'device'

[2023-07-27 23:36:04,587]::[InvokeAI]::ERROR --> Error while invoking:
'str' object has no attribute 'device'

full gazelle
#

there's a PR open for this that should fix this issue

delicate kindle
#

thanks for letting me know. I've been hacking away at it and I think I got it working. That fix above resolved it for the model, but for the refiner, I had to update the unet_2d_condition.py file to change:

timesteps = timesteps[None].to(sample.device)

to

timesteps = timesteps[None].to(dtype=torch.float32).to(sample.device)

so basically hardcoded the device type to torch.float32 there and it now works, with the refiner.