Nvidia RTX 5060

Beginners
1

The Nvidia RTX 5060 is incompatible with all image processing programs, such as Fooocus, RuinedFooocus, etc.
Don’t drive yourselves crazy; until future updates or new programs arrive, don’t waste your time.

2

Yeah. Quite a few projects still ship official builds with an older CUDA/PyTorch stack aimed at pre-Blackwell GPUs. In many cases, updating PyTorch may be enough to make the core app usable. If I were choosing a GUI for Blackwell today, I’d probably use Forge Neo or ComfyUI…

I would not generalize this to “the RTX 5060 is incompatible with image-generation software” as a whole.

There is a real compatibility problem with some older packaged environments. Fooocus is a good example: its current launcher still defaults to torch==2.1.0 and xformers==0.0.23, while RTX 5060 users have reported the bundled PyTorch rejecting the card’s sm_120 compute capability and then failing with no kernel image is available for execution on the device.

But that is different from the GPU itself being unusable. PyTorch added Blackwell support with CUDA 12.8 builds in PyTorch 2.7, and current image-generation environments can use much newer CUDA/PyTorch stacks.

So for a new RTX 5060 installation, my default route would be:

  1. Start with a clean current ComfyUI or Forge Neo installation.
  2. First test a basic generation without third-party custom nodes/extensions or optional attention packages.
  3. Only after that works, add xFormers / FlashAttention / SageAttention / ControlNet preprocessors / custom nodes one at a time.

That separates “does Blackwell work at all?” from “does this particular extension/kernel work on Blackwell?”

ComfyUI is especially straightforward as a baseline at the moment: its current Windows portable uses a modern PyTorch/CUDA stack, and its maintained stack manifest explicitly includes CUDA builds covering compute capability 12.0.

Forge Neo is also actively targeting current PyTorch/CUDA versions. One useful design choice there is that it can fall back to native PyTorch scaled-dot-product attention rather than requiring every optional acceleration library. Its own README specifically warns against blindly installing every attention backend.

Why this can be confusing on RTX 50-series

There are several separate compatibility layers which can all produce something that looks like “my RTX 5060 is unsupported”:

RTX 5060 / Blackwell
    ↓
NVIDIA driver
    ↓
the Python environment actually used by the application
    ↓
PyTorch + bundled CUDA runtime
    ↓
optional CUDA kernels
    ├─ xFormers
    ├─ FlashAttention
    ├─ SageAttention
    └─ Triton / compiled extensions
    ↓
application code
    ↓
third-party extension / custom node
    ↓
model / quantization format / workflow
    ↓
VRAM and memory-management behavior

Failure at one layer does not necessarily mean failure at the layers above or below it.

1. Fooocus is a particularly understandable case

The official Fooocus launcher still contains:

torch==2.1.0
torchvision==0.16.0
xformers==0.0.23

That stack predates RTX 50-series support.

The RTX 5060 report in issue #4053 is especially useful because Fooocus actually starts and sees the GPU, but its bundled PyTorch warns:

NVIDIA GeForce RTX 5060 with CUDA capability sm_120
is not compatible with the current PyTorch installation

and generation then fails.

That is much narrower than “RTX 5060 cannot run image generation”: the packaged runtime is the incompatible component.

It also explains why updating the NVIDIA driver alone may not fix an old portable package.

2. Check the Python environment the application actually uses

Portable applications often contain their own Python installation.

So installing a new PyTorch into your normal Python environment may change nothing if the application launches something like:

python_embeded\python.exe

instead.

A useful sanity check is to run the following with the same Python executable the GUI itself uses:

import torch

print("PyTorch:", torch.__version__)
print("CUDA runtime:", torch.version.cuda)

print("GPU:", torch.cuda.get_device_name(0))
print("capability:", torch.cuda.get_device_capability(0))
print("compiled arches:", torch.cuda.get_arch_list())

x = torch.randn((1024, 1024), device="cuda")
y = x @ x
print("CUDA matmul OK:", y.mean().item())

The last operation matters.

Seeing the RTX 5060 in torch.cuda is useful, but it is not by itself proof that the kernels needed for actual computation work.

There have even been Windows/PyTorch reports where sm_120 appears to be present in the binary but an actual CUDA operation still fails:

I would therefore use an actual CUDA operation as the cheap baseline rather than stopping at GPU detection.

3. Installing the CUDA Toolkit system-wide is a different question

For normal prebuilt PyTorch wheels, the relevant CUDA runtime is generally shipped with the PyTorch environment itself.

So:

"I installed CUDA 12.8/13.x on Windows"

does not necessarily mean:

"the PyTorch embedded inside Fooocus is now a CUDA 12.8/13.x build"

The system CUDA Toolkit becomes particularly relevant when compiling PyTorch or custom CUDA extensions. For packaged applications, checking the app’s own torch.__version__ and torch.version.cuda is more informative.

4. Core PyTorch support and optional-kernel support are different

Another easy trap is xFormers / FlashAttention / SageAttention.

A GUI can work perfectly well with native PyTorch attention while one optional CUDA operator fails.

Conversely, an old statement such as “xFormers does not support RTX 50-series” should not be treated as permanently true: xFormers later added Blackwell-specific CUTLASS FMHA support.

But support can still depend on the exact xFormers version, wheel, operator, dtype and calling extension.

For diagnosis, native PyTorch SDPA is therefore a useful control. Forge Neo explicitly recommends not blindly installing all the optional attention implementations and notes that native PyTorch SDPA is often both fast and stable.

If:

native PyTorch attention works

but:

xFormers / FlashAttention / SageAttention fails

then I would investigate that backend rather than concluding that the RTX 5060 or the whole GUI is unsupported.

5. The same applies to extensions and custom nodes

Suppose:

clean UI + stock workflow = works
ControlNet preprocessor/custom node = fails

That is already a much narrower problem.

The extension may bring its own CUDA extension, Triton code, package pins, or even install a different PyTorch dependency.

This is why a clean baseline is useful before installing a large extension set.

It is also worth re-checking:

torch.__version__
torch.version.cuda

after installing extensions if a previously working environment suddenly stops working.

6. VRAM failure is another separate branch

The RTX 5060 commonly has 8 GB of VRAM, so some modern image/video models can still fail even after Blackwell compatibility is completely solved.

That usually produces a different class of evidence: OOM, offloading problems, allocator failures, or success after changing resolution/model/VRAM strategy.

For example, there is a recent ComfyUI report from an RTX 5060 Laptop where the same workflow fails with DynamicVRAM enabled but succeeds with --disable-dynamic-vram:

That is useful mainly as a reminder that:

"fails on RTX 5060"

does not automatically imply:

"sm_120 is unsupported"

The first error message is important.

A simple decision tree

For this sort of case I would roughly use this order:

Does the application's own PyTorch report that sm_120 is unsupported?
|
+-- YES
|   |
|   +--> The packaged PyTorch/CUDA stack is too old.
|        Use a current application build/runtime, or carefully update
|        the application's own PyTorch environment.
|
+-- NO
    |
    +--> Does a simple CUDA tensor operation fail?
    |   |
    |   +-- YES
    |   |   |
    |   |   +--> Investigate PyTorch build / CUDA binary / driver /
    |   |        Windows-specific runtime compatibility.
    |   |
    |   +-- NO
    |       |
    |       +--> Does a clean stock generation work with native
    |            PyTorch attention and no third-party extensions?
    |           |
    |           +-- YES
    |           |   |
    |           |   +--> Core Blackwell support is probably fine.
    |           |        Add optional components one at a time.
    |           |
    |           +-- NO
    |               |
    |               +--> Look at the first real error:
    |                    model loading?
    |                    dtype/operator?
    |                    CUDA extension?
    |                    memory allocation?
    |                    VRAM?
    |
    +--> If stock generation works but a feature fails:
        |
        +--> Treat that feature/backend/extension as the problem
             until evidence points back to the core runtime.

That usually gives more information than repeatedly reinstalling drivers, CUDA Toolkits and random PyTorch versions together.

What about RuinedFooocus?

I would also separate RuinedFooocus from the original Fooocus package here.

It started from Fooocus, but its current launcher now has its own runtime-management logic using torchruntime, including handling for newer NVIDIA CUDA/PyTorch platforms. Its September 2026 update log also explicitly mentions an NVIDIA PyTorch update.

So I would not assume that a failure in the original Fooocus portable automatically applies to current RuinedFooocus.

I have not seen enough clean evidence to claim that every RuinedFooocus configuration is trouble-free on every RTX 5060, though. Its current runtime direction looks appropriate for Blackwell, but extensions/models can still introduce separate constraints.

So I think the practical picture is closer to:

RTX 5060 itself:
    usable for current PyTorch/image-generation stacks

old packaged PyTorch:
    can definitely be a problem

current ComfyUI / Forge Neo:
    good places to establish a clean Blackwell baseline

Fooocus official portable:
    old bundled runtime is a known problem

RuinedFooocus:
    newer runtime management; should be evaluated separately

xFormers / Flash / Sage / custom nodes:
    test separately from core GPU support

8 GB VRAM:
    still a real constraint, but a different problem

For someone who just wants to generate images rather than debug Python packaging, I would probably start with a clean current ComfyUI or Forge Neo installation, verify one ordinary generation, and only then recreate the desired Fooocus/extensions workflow.

That should tell you very quickly whether you are dealing with the RTX 5060 itself, an old packaged runtime, or one particular optional component.