Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix image upcasting #7858

Merged
merged 2 commits into from
May 8, 2024
Merged

Conversation

tolgacangoz
Copy link
Contributor

@tolgacangoz tolgacangoz commented May 4, 2024

Thanks for the opportunity to fix #7854

What does this PR do?

This PR proposes to fix image upcasting before vae.encode() when using fp16 and vae.config.force_upcast==True with xformers or torch>=2.0 installed. Casting with .to(next(iter(self.vae.post_quant_conv.parameters())).dtype) is supposed to be preferred before vae.decode() not vae.encode().

Before submitting

Who can review?

Anyone in the community is free to review the PR once the tests have passed. Feel free to tag members/contributors who may be interested in your PR.
@yiyixuxu @kadirnar

@tolgacangoz tolgacangoz changed the title Fix image upcasting before vae.encode() when using fp16 Fix image upcasting before vae.encode() when using fp16 May 4, 2024
@tolgacangoz tolgacangoz changed the title Fix image upcasting before vae.encode() when using fp16 Fix image upcasting before vae.encode() when using fp16 with xformers or torch==2.0 installed May 4, 2024
@tolgacangoz tolgacangoz changed the title Fix image upcasting before vae.encode() when using fp16 with xformers or torch==2.0 installed Fix image upcasting before vae.encode() when using fp16 with xformers or torch>=2.0 installed May 4, 2024
@tolgacangoz tolgacangoz changed the title Fix image upcasting before vae.encode() when using fp16 with xformers or torch>=2.0 installed Fix image upcasting May 4, 2024
@bghira
Copy link
Contributor

bghira commented May 6, 2024

the same issue exists in the StableDiffusionPipeline :) would you like to tackle that one too? latents must be cast to vae dtype during decode

@tolgacangoz
Copy link
Contributor Author

I need to understand. Wouldn't this throw an error:

import torch
from diffusers import StableDiffusionPipeline

pipe = StableDiffusionPipeline.from_pretrained("runwayml/stable-diffusion-v1-5",
                           torch_dtype=torch.float16, variant='fp16').to("cuda")
image = pipe("a photo of an astronaut riding a horse on mars").images[0]

Or, is it a case in MPS?

@bghira
Copy link
Contributor

bghira commented May 6, 2024

it's actually something that occurs on ROCm which masquerades as CUDA

@HuggingFaceDocBuilderDev

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

Copy link
Collaborator

@yiyixuxu yiyixuxu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks!

@yiyixuxu yiyixuxu merged commit d50baf0 into huggingface:main May 8, 2024
15 checks passed
@tolgacangoz
Copy link
Contributor Author

Thanks for merging!

@tolgacangoz tolgacangoz deleted the fix-dtype-leditspp branch May 8, 2024 06:43
lawrence-cj pushed a commit to lawrence-cj/diffusers that referenced this pull request May 8, 2024
Fix image's upcasting before `vae.encode()` when using `fp16`

Co-authored-by: YiYi Xu <[email protected]>
@kadirnar
Copy link
Contributor

kadirnar commented May 8, 2024

Thanks @StandardAI ❤️

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

RuntimeError: Input type (c10::Half) and bias type (float) should be the same
5 participants