Inpainting Issues

[lightningstrike2010]

I'm running into an issue with inpainting in SD.Next running an 5700XT. Everything else is running fine, and faster than the traditional dml implementation by a good bit, but inpainting creates a similar problem as default settings would in a dml implementation. In there we'd use the following flags.

--disable-nan-check --no-half --precision full --no-half-vae --opt-sub-quad-attention --opt-split-attention-v1 --medvram --use-cpu interrogate

Now in SD.Next I'm pretty sure we don't need the medvram, or to offload the interrogate to CPU, but the problem we run into is we can't set --opt-sub-quad-attention AND --opt-split--attention-v1 both to on at the same time. Is there a way around this? A different solution we can use? I've been in the settings system, and so far I'm at a loss on how to reproduce those two flags inside settings.

Without the fix, inpainting creates a blurred area, and makes no changes to it, as I said, an issue we fix in sddml with flags, but SD.Next I'm not sure how to either implement the fix, or if this is just a "no fix" situation.

[vladmandic]

but....having multiple cross-attention optimizations active at the same time was never intended, this is first i'm hearing of it.
looking at code logic, if you set --opt-sub-quad-attention --opt-split-attention-v1, you're mostly running with split-attention-v1 as it pretty much overwrittes any forward functions that sub-quad has defined.

now, if you're getting blurred area with one or the other, but not when both are active, that doesn't make much sense.
this would need a LOT more investigation to figure out what you're seeing vs what's in the code.

[lightningstrike2010]

Right, and I tried setting Split-attention-v1 on its own, still got the blur. It's some quark of the underlying sd code. I'm not a coder (not these days) I know enough to find solutions, and give detailed rundowns of problems, as well as show where other solutions worked. I can tell you in directml if you don't use -no-half --precision full --no-half-vae --opt-sub-quad-attention --opt-split-attention-v1 inpainting blurs out and fails to render properly on RX5000, and RX6000 cards, at least according to various users on redit and other sources. I know also that the RX5000 and RX6000 use almost the same underlying hardware, and that on RCOM for Linux there's a work around to use RCOM for the RX5000 series of cards.

That's the depth of my knowledge.

Updated While Typing:

I have however done a reinstall one more time, and set the following setting which seems to have fixed it, though why it was failing before I have no idea.
--no-half, --no-half-vae, and autocast is set to on, with sub-quadratic as the cross-attention optomizer.

Maybe something in the recent code pull was fixed, or I had a random file error that many times in a row. My apologies if I wasted time. I left the previous text as I was writing and testing on another new install as a just in case this crops back up or someone else is running into a similar issue.

[vladmandic]

its not time wasted and glad it works, i was just surpised to see two cross-optimizations applied together and results being anything but a full crash :)

[Fvnguyen]

Commenting to add that I have the exact same issue with a version I pulled from the repo at 13/11/2023.

I have tried the settings @lightningstrike2010 recommended but I run into the same issue. Inpainting only "blurs" the masked area, creating a weird discoloration similar to an image without VAE. However no matter how many variations and samples I create there is no change to the masked area at all.

Is there anything that could cause this or any settings I might have missed? Using the normal automatic1111 webui inpainting does not produce this at all but is of course very slow due to using only CPU.