[TÓPICO OFICIAL] SD - Stable Diffusion - Definição, Dúvidas, etc.

[猫同志]

O ESRGAN é o Highres do Automatic1111, ele tem diversos modos, até mesmo anime.

Curiosamente, eu já usava o Real ESRGAN antes mesmo de usar o Stable Diffusion, ele tem versão standalone que pode ser usado pra qualquer imagem.

Eu particularmente uso a versão nncn com backend Vulkan criada pelo Xinntao.

Olha só que coisinha mais cheirosa, salva muito anime e é melhor que o Waifu 2x: https://github.com/xinntao/Real-ESRGAN

Para fotos gerais, eu prefiro o Real SR, porque pelo menos não fica cagando a imagem toda com remoção de ruído, mas também não é tão milagrosa pra fotos realistas.

GitHub - Tencent/Real-SR: Real-World Super-Resolution via Kernel Estimation and Noise Injection

Real-World Super-Resolution via Kernel Estimation and Noise Injection - Tencent/Real-SR

github.com

--- Post duplo é unido automaticamente: 08/08/2023 ---

Eu vou dar uma olhada nesse novo ESRGAN em breve, esse do Automatic1111

 

[glass]

Curiosamente, eu já usava o Real ESRGAN antes mesmo de usar o Stable Diffusion, ele tem versão standalone que pode ser usado pra qualquer imagem.

Eu particularmente uso a versão nncn com backend Vulkan criada pelo Xinntao.

Olha só que coisinha mais cheirosa, salva muito anime e é melhor que o Waifu 2x: https://github.com/xinntao/Real-ESRGAN

Para fotos gerais, eu prefiro o Real SR, porque pelo menos não fica cagando a imagem toda com remoção de ruído, mas também não é tão milagrosa pra fotos realistas.

GitHub - Tencent/Real-SR: Real-World Super-Resolution via Kernel Estimation and Noise Injection

Real-World Super-Resolution via Kernel Estimation and Noise Injection - Tencent/Real-SR

github.com

Aqui eu não uso muito, só quando vou dar uns retoques na imagem mesmo, pra meme to satisfeito, tem o Real Esrgan, o normal e a versão anime, assim como outros fixes, aliás se quiser manter o automatic sempre atualizado e rodando sdxl eu uso esses argumentos

--xformers --autolaunch --theme dark --update-all-extensions --no-half-vae

Git pull

nessa configuração ele sempre ativa o xformers, verifica todas as extensões por atualizações e verifica o repositório do au1111 por mudanças.

 

[猫同志]

Lendo o repositório do ESRGAN, também criado pelo Xinntao, pude perceber que segundo ele, o Real ESRGAN é uma versão melhorada ou "extendida" do próprio ESRGAN.

Interessante notar, talvez eu deva acompanhar mais os repositórios deste chinês pra ver o que mais tem de interessante.

GitHub - xinntao/ESRGAN: ECCV18 Workshops - Enhanced SRGAN. Champion PIRM Challenge on Perceptual Super-Resolution. The training codes are in BasicSR.

ECCV18 Workshops - Enhanced SRGAN. Champion PIRM Challenge on Perceptual Super-Resolution. The training codes are in BasicSR. - GitHub - xinntao/ESRGAN: ECCV18 Workshops - Enhanced SRGAN. Champion ...

github.com

 

[solofpadawan]

Aqui eu não uso muito, só quando vou dar uns retoques na imagem mesmo, pra meme to satisfeito, tem o Real Esrgan, o normal e a versão anime, assim como outros fixes, aliás se quiser manter o automatic sempre atualizado e rodando sdxl eu uso esses argumentos

--xformers --autolaunch --theme dark --update-all-extensions --no-half-vae

Git pull

nessa configuração ele sempre ativa o xformers, verifica todas as extensões por atualizações e verifica o repositório do au1111 por mudanças.

Eu costumo usar o 4x-ultrasharp, acho muito bom e leve.
E tem alguns upscalers que deixam as cores meio desbotadas, não lembro qual é..

--- Post duplo é unido automaticamente: 09/08/2023 ---

Spoiler: 18 & Kuririn

--- Post duplo é unido automaticamente: 09/08/2023 ---

Spoiler: Jill Sanduich - entendedores entenderão..

 

[猫同志]

Uma coisa que eu percebi, é que no Stable Diffusion as vezes me forçam a negar os pontos flutuante de meia precisão, dependendo de qual modelo eu tento usar.

Isso é um fato que limita o desempenho da placa de video para um pouco mais de 20 teraflops, em "condições perfeitas" .

 

[igormp]

Uma coisa que eu percebi, é que o Stable Diffusion as vezes me forçam a negar os pontos flutuante de meia precisão, dependendo de qual modelo eu tento usar.

Isso é um fato que limita o desempenho da placa de video para um pouco mais de 20 teraflops, em "condições perfeitas" .

Creio que isso possa ser problema do ROCm :/

 

[glass]

Uma coisa que eu percebi, é que no Stable Diffusion as vezes me forçam a negar os pontos flutuante de meia precisão, dependendo de qual modelo eu tento usar.

Isso é um fato que limita o desempenho da placa de video para um pouco mais de 20 teraflops, em "condições perfeitas" .

Dependendo do cliente que você estiver utilizando, insira um script para mantê-lo sempre atualizado, toda vez que eu inicio o SD o comando aqui puxa alguma novidade da biblioteca.

 

[猫同志]

Creio que isso possa ser problema do ROCm :/

Talvez eu esteja exigindo muito, mas eu torço para que um dia criem uma versão do Stable Diffusion baseado em Vulkan ou em outra API livre que não seja baseada em Cuda, porque isso acabaria com a necessidade de usar o ROCm e também acabaria até com a lógica que tornou as Vega 10 "obsoletas" para este driver.

Só torço pra que não seja baseado em OpenCL, porque os desenvolvedores de software livre praticamente não conseguem criar um driver de OpenCL que simplesmente funcione.

 

[glass]

Talvez eu esteja exigindo muito, mas eu torço para que um dia criem uma versão do Stable Diffusion baseado em Vulkan ou em outra API livre que não seja baseada em Cuda, porque isso acabaria com a necessidade de usar o ROCm e também acabaria até com a lógica que tornou as Vega 10 "obsoletas" para este driver.

Só torço pra que não seja baseado em OpenCL, porque os desenvolvedores de software livre praticamente não conseguem criar um driver de OpenCL que simplesmente funcione.

Ai você está sonhando. Eu concordo que precisa aumentar o investimento no ROCm principalmente porque estão rolando muitas vendas de placas AMD pra pequenas empresas pra trabalhar com DL, agora não tem nem como comparar com CUDA, difícil alguém criar um fork baseado em vulkan enquando CUDA é suportado desde séculos atrás =\, nesse caso a AMD demorou muito tempo pra entrar nessa corrida, principalmente porque em drivers, nvidia é rei.

 

[igormp]

Talvez eu esteja exigindo muito, mas eu torço para que um dia criem uma versão do Stable Diffusion baseado em Vulkan ou em outra API livre que não seja baseada em Cuda, porque isso acabaria com a necessidade de usar o ROCm e também acabaria até com a lógica que tornou as Vega 10 "obsoletas" para este driver.

Só torço pra que não seja baseado em OpenCL, porque os desenvolvedores de software livre praticamente não conseguem criar um driver de OpenCL que simplesmente funcione.

Vulkan pra compute é desnecessariamente complicado (até mais que OpenCL), e não é muito prático de usar. As frameworks que funcionam em vulkan (tipo a ncnn) tem performance inferior às baseadas em Cuda :/

A única API que daria pra concorrer com o CUDA é o SyCL, mas tem um longo caminho pela frente.

 

[猫同志]

O ROCm é praticamente um driver com um compilador LLVM embutido, que converte alguns programas baseados em Cuda em uma línguagem compatível com as GPUs da AMD.

Em termos leigos, eu diria que traduz Cuda para "OpenCL" (não é exatamente nestes termos), desde que o binário de Cuda tenha sido compilado com LLVM, não é uma coisa API nova.

 

[glass]

Vulkan pra compute é desnecessariamente complicado (até mais que OpenCL), e não é muito prático de usar. As frameworks que funcionam em vulkan (tipo a ncnn) tem performance inferior às baseadas em Cuda :/

A única API que daria pra concorrer com o CUDA é o SyCL, mas tem um longo caminho pela frente.

SyCL? Fale mais você quem sabe : P

 

[igormp]

O ROCm é praticamente um driver com um compilador LLVM embutido, que converte alguns programas baseados em Cuda em uma línguagem compatível com as GPUs da AMD.

Em termos leigos, eu diria que traduz Cuda para OpenCL, desde que o binário de Cuda tenha sido compilado com LLVM, não é uma coisa API nova.

Não usa OpenCL por baixo, vai direto pra o assembly lá dá AMD através do HIP.

SyCL? Fale mais você quem sabe : P

É uma linguagem/framework que abstraí o OpenCL, sendo mais versátil que lidar com OpenCL direto e também tão agnóstico quanto:

SYCL - C++ Single-source Heterogeneous Programming for Acceleration Offload

www.khronos.org

 

[猫同志]

Vulkan pra compute é desnecessariamente complicado (até mais que OpenCL), e não é muito prático de usar. As frameworks que funcionam em vulkan (tipo a ncnn) tem performance inferior às baseadas em Cuda :/

Verdade, mas vale considerar que estou falando disso pensando no suporte para placas que não são da NVIDIA, como essas GPU da Intel, da Apple e de outras fabricantes que eu nunca nem ouvi falar por exemplo.

Sendo assim, essas placas e GPUs na maioria das vezes nem tem "Cuda" para comparar.

Até o momento, parece que só a AMD investiu em tradução de Cuda para uma linguagem de máquina compatível.

--- Post duplo é unido automaticamente: 09/08/2023 ---

Não usa OpenCL por baixo, vai direto pra o assembly lá dá AMD através do HIP.

Claro, até porque o ROCm é um driver de OpenCL, mas ele tem todo um conjunto de bibliotecas e também um compilador LLVM.

A compatibilidade com Cuda existe, mas é baseada em compilação.


Vale ressaltar ainda, que quando eu digo que é baseado em compilação, isso significa que não é qualquer binário de Cuda funcione, mas tem que ser um binário compatível com o software usado pra compilação, inclusive com o próprio LLVM.

 

[igormp]

Até o momento, parece que só a AMD investiu em tradução de Cuda para uma linguagem de máquina compatível.

A intel tem o DPC++, que faz justamente isso de CUDA->SyCL.

Verdade, mas vale considerar que estou falando disso pensando no suporte para placas que não são da NVIDIA, como essas GPU da Intel, da Apple e de outras fabricantes que eu nunca nem ouvi falar por exemplo.

Intel tem o OpenAPI, Apple tem o Metal e abstrações por cima.

 

[glass]

Verdade, mas vale considerar que estou falando disso pensando no suporte para placas que não são da NVIDIA, como essas GPU da Intel, da Apple e de outras fabricantes que eu nunca nem ouvi falar por exemplo.

Sendo assim, essas placas e GPUs na maioria das vezes nem tem "Cuda" para comparar.

Até o momento, parece que só a AMD investiu em tradução de Cuda para uma linguagem de máquina compatível.

--- Post duplo é unido automaticamente: 09/08/2023 ---

Claro, até porque o ROCm é um driver de OpenCL, mas ele tem todo um conjunto de bibliotecas e também um compilador LLVM.

A compatibilidade com Cuda existe, mas é baseada em compilação.

É exatamente por isso que as pessoas que usam computação baseada em CUDA um padrão existente desde 2006 e com Hardware próprio para isso usam nvidia, a esperança da AMD são os novos compradores investirem já que é open-source.

Não usa OpenCL por baixo, vai direto pra o assembly lá dá AMD através do HIP.

É uma linguagem/framework que abstraí o OpenCL, sendo mais versátil que lidar com OpenCL direto e também tão agnóstico quanto:

SYCL - C++ Single-source Heterogeneous Programming for Acceleration Offload

www.khronos.org

Putz, to lendo aqui, mas é uma empresa privada independente dos grandes players? Eu tenho uma esperança no intel.

 

[igormp]

Claro, até porque o ROCm é um driver de OpenCL, mas ele tem todo um conjunto de bibliotecas e também um compilador LLVM.

A compatibilidade com Cuda existe, mas é baseada em compilação.

Ele também é um driver OpenCL, mas isso é só um componente dele e é independente do resto. O fork do LLVM da AMD inclusive é um nojo, as pessoas que conheço que trabalham nele só falam o quão ruim é.

É exatamente por isso que as pessoas que usam computação baseada em CUDA um padrão existente desde 2006 e com Hardware próprio para isso usam nvidia, a esperança da AMD são os novos compradores investirem já que é open-source.



Putz, to lendo aqui, mas é uma empresa privada independente dos grandes players? Eu tenho uma esperança no intel.

Não, Khronos é o grupo sem fins lucrativos responsável pelo OpenCL, SyCL e Vulkan (entre vários outros projetos/padrões). A AMD, Intel, Nvidia, Apple e muitas outras empresas são membros e contribuem frequentemente com extensões nesses padrões.

 

[glass]

Ele também é um driver OpenCL, mas isso é só um componente dele e é independente do resto. O fork do LLVM da AMD inclusive é um nojo, as pessoas que conheço que trabalham nele só falam o quão ruim é.

Não, Khronos é o grupo sem fins lucrativos responsável pelo OpenCL, SyCL e Vulkan (entre vários outros projetos/padrões). A AMD, Intel, Nvidia, Apple e muitas outras empresas são membros e contribuem frequentemente com extensões nesses padrões.

Ela é responsável por tudo... o.o

 

[猫同志]

Não usa OpenCL por baixo, vai direto pra o assembly lá dá AMD através do HIP.

Agora eu li isso direito, e realmente, tem uns detalhes menores que eu preciso ver direito.

 

[igormp]

Aparentemente tem um fork do repo do automatic focado em AMD com resultados bem bons, talvez sirva bem pros que usam AMD aqui.

Stable Diffusion Performance - NVIDIA GeForce VS AMD Radeon

Stable Diffusion is seeing more use for professional content creation work. How do NVIDIA GeForce and AMD Radeon cards compare in this workflow?

www.pugetsystems.com

猫同志

 

[猫同志]

Aparentemente tem um fork do repo do automatic focado em AMD com resultados bem bons, talvez sirva bem pros que usam AMD aqui.

Stable Diffusion Performance - NVIDIA GeForce VS AMD Radeon

Stable Diffusion is seeing more use for professional content creation work. How do NVIDIA GeForce and AMD Radeon cards compare in this workflow?

www.pugetsystems.com

猫同志

A julgar por esta informação, eu diria que este repositório personalizado não será útil para mim, pois eu não uso Windows e por isso o DirectML não se aplica ao meu caso de uso.

No mais, agradeço mesmo assim, pois pode ser útil para outras pessoas.

 

[igormp]

A julgar por esta informação, eu diria que este repositório personalizado não será útil para mim, pois eu não uso Windows e por isso o DirectML não se aplica ao meu caso de uso.

No mais, agradeço mesmo assim, pois pode ser útil para outras pessoas.

Eita, nem tinha reparado nesse detalhe, acho que dá pra ignorar até os resultados desse bench inteiro já que são muito inferiores ao visto no linux, só reparei agora.

 

[glass]

Eita, nem tinha reparado nesse detalhe, acho que dá pra ignorar até os resultados desse bench inteiro já que são muito inferiores ao visto no linux, só reparei agora.

A verdade é que até hoje Cuda domina porque investiram desde o início, no início nunca tem lucro imediato, mas depois já viu né?

 

[Termal]

Acho que consegui usar o ComfyUI. Precisei fazer downgrade de Python para uma versão anterior.

1. Tem um 7z pronto pra usar que extrai uma pasta comfyUI portable para Nvidia GPU
2. Aparentemente ele vem sem modelos e sem modelos, sem imagens
3. Achei então o ComFyUI manager
4. Fechando e abrindo o ComfyUI de novo aparece um novo botão "Manager". Ali tem os modelos todos pra instalar.
5. Instalei o SD XL base model e o refiner

Agora consegui gerar uma imagem. Antes dava erro pq não tinha modelo nenhum.

O problema agora é aprender a usar esses nodes e ainda falta o upscaler.

 

[glass]

Acho que consegui usar o ComfyUI. Precisei fazer downgrade de Python para uma versão anterior.

1. Tem um 7z pronto pra usar que extrai uma pasta comfyUI portable para Nvidia GPU
2. Aparentemente ele vem sem modelos e sem modelos, sem imagens
3. Achei então o ComFyUI manager
4. Fechando e abrindo o ComfyUI de novo aparece um novo botão "Manager". Ali tem os modelos todos pra instalar.
5. Instalei o SD XL base model e o refiner

Agora consegui gerar uma imagem. Antes dava erro pq não tinha modelo nenhum.

O problema agora é aprender a usar esses nodes e ainda falta o upscaler.

Exatamente, ele é bem melhor no sentido de optimização que o automatic, mas eu prefiro minha Gui mastigadinha.