Windows DirectML testing results: MDX and VR work, RoFormer and Demucs currently fail for different backend limitations

Following the recent addition of the DirectML documentation, multiple architectures were tested on a Windows machine with an AMD integrated GPU. Here are the results for tracking compatibility.

Environment
Windows 11
Python 3.12.8
torch-directml 0.2.5.dev240914
onnxruntime-directml 1.24.4
audio-separator 0.44.2

env_info reports:
DirectML is available in Torch, setting Torch device to DirectML
ONNXruntime has DmlExecutionProvider available, enabling acceleration

Results

MDX and VR
The MDX and VR models completed separation successfully using DirectML.

RoFormer
The new implementation first reports '>=' not supported between instances of 'torch.device' and 'int' before falling back to the legacy implementation.
Inference then fails with 'Invalid or unsupported data type ComplexFloat'. This appears to come from torch-directml not supporting ComplexFloat datatype used during FFT operations.

Demucs
The model loads correctly, but inference fails with 'aten::_thnn_fused_lstm_cell' which appears to indicate that the fused LSTM operator required by Demucs is not currently supported by torch-directml.

So, MDX and VR models are fully usable with DirectML. RoFormer currently depends on ComplexFloat support. And Demucs currently depends on fused LSTM support.

Hopefully these results help confirm and update the DirectML compatibility status in the README :)

Start with the DirectML documentation and the README compatibility section. Compare the reported Windows, Python, torch-directml, and ONNX Runtime environment with the MDX, VR, RoFormer, and Demucs results. Done means the README clearly records which architectures work and which remain blocked by ComplexFloat or fused LSTM support.