Success: LTX-2 Video+Audio Generation on Strix Halo (gfx1151) with TheROCk 7.11

[bkpaine1]

Just wanted to share a success story and say thanks to the TheROCk team.

Hardware: GMTEK NUC EVO 2, Strix Halo APU (gfx1151), 128GB unified memory, Ubuntu 25.10

What's Working:

• LTX-2 (Lightricks' new audio-video model) - full video + synchronized audio generation
• Flux, SDXL, Hunyuan Video
• SimpleTuner for local LoRA training
• Z Turbo

Performance:
10-second video with audio in ~10 minutes. Not H100 speed, but absolutely usable for daily content production.

The Difference TheROCk Makes:
Stock ROCm 7.2 was slow. TheROCk 7.11 nightlies are dramatically faster on gfx1151. Night and day difference. This is what makes the hardware actually usable for AI workloads.

I wrote a complete guide:

• GitHub: https://github.com/bkpaine1/AMD-Strix-Halo-AI-Guide
• Medium article: https://medium.com/@bkpaine1/i-use-amd-strix-halo-for-ai-video-inference-and-lora-daily-you-can-too-8b359b97e08c?postPublishedType=repub
  Includes startup scripts, environment variables (HSA_ENABLE_SDMA=0, HSA_USE_SVM=0), and a patch for a ComfyUI audio bug on AMD.

Looking forward to March 2026 when TheROCk becomes ROCm 8.0. Keep up the great work.

[stellaraccident]

Thank you for taking the time to work this out and to push us with specifics.

We're discussing your feedback internally, but in the meantime, I did want to share that we are working right now on setting up weekly releases and this is what we can signal boost more for people on the bleeding edge.

The weeklies will be the feed stock that gets promoted to 7.11, 7.12, 8.0. Right now, the nightlies are cut from main each night (and 7.9/7.10 were cut manually and subjected to offline QA), inheriting the unit test coverage from there. The weeklies will involve promoting a nightly and running our more extensive QA processes against it to qualify it for actual use, attach proper test reports to the release, document, etc. These processes are a combination of automation and manual testing and presently take several days to run on each candidate for all GPU architectures. By focusing on getting the weeklies well tested and into user's hands, I think we'll be in a position to address your point of feedback about advertising this path more and getting more people onto it without waiting for march/8.0 (which is still an estimate and can change based on how things unfold).

We expect to have this weekly release process stabilized this month, and it will be used for selecting a 7.11 (and later) candidate at the beginning of February. And this is the last process milestone we need to pass to make TheRock "official" and fully integrated with our QA, documentation, and other release channels (for drivers, etc).

Thank you for taking the time and struggling through this change with us. I started TheRock a year ago this month because I wanted to be able to use my AMD GPUs just like I had come to expect I could use my NVIDIA GPUs. It seemed like an impossible goal then to get everything straightened. There is still much to do, but I really appreciate you taking the time to give us a fresh try and to help us get this stuff dialed in with good feedback. It really does help -- and not just in the "tell us what to do" way -- but on the human level by validating the extreme amount of work that many of us have put in to this over the last year.

[bkpaine1]

Your welcome! I enjoyed working with it but I think the world needs to grasp AMD is way ahead.. This is why the Halo Strix isn't getting a lot of vendors but MAN the stuff I can do with this APU and unified memory if it runs right. And things like ComfyUI, Simple Tuner, Ollama on GPU etc this is THE way!!!! Keep up the great work. TheROCK is light years ahead of where people realize from rocm!

[astrelsky]

It really does help -- and not just in the "tell us what to do" way -- but on the human level by validating the extreme amount of work that many of us have put in to this over the last year.

FWIW, the more "yelling" and complaining you hear, means that the extreme amount of work being put into it is getting somewhere. Most people wouldn't bother to complain or open issues and all that stuff if they didn't feel like it was worth it or if they felt that they wouldn't be heard. Otherwise you would just end up with more things like zluda (no offense intended to the zluda authors).

[powderluv]

Thanks for the writeup @bkpaine1 . I don't have your x.com handle but I posted it on X. Thank you for making your work accessible to the community. We are listening to your feedback.

[harkgill-amd]

Hey @bkpaine1, thanks for sharing! I wanted to ask you about some of the issues you highlighted in the Troubleshooting section so we can get a better idea of what work needs to be done our end.

APU running slow -> Install CoreCtl, set Performance mode

With CoreCtrl, are you setting both the GPU to performance mode = high and CPU to frequency governor = Performance or just the latter? Also, which workflows do you see a performance uplift in after tweaking these settings and by how much %. I gave this a try on my end following the steps in your guide and saw mixed results. With LTX-2 (video_ltx2_t2v) and SDXL workflows, there was a ~2-4% speed up after applying performance settings whereas with Flux, there was little to no change. If we do come to the conclusion that altering the power profiles for the CPU/GPU results in significant performance uplift, we can file an issue and look into providing some solutions, whether that's better guidelines in the form of documentation or performance tuning.

No audio in video -> Apply the sed fix in step 6

Is this something you're still experiencing pulling in the latest ComfyUI and TheRock nightlies? Following the steps in your guide, I was able to get audio working in the aforementioned LTX-2 workflow without having to apply the patch. The videos are also being saved by default into the outputs folder with audio which I believe should hit the faulty line you're referencing but I might be wrong.

[bkpaine1]

I updated my comfui and ran the fix. I will update tomorrow and answer I suspect they 'fixed it'. IN CoreCtl I set the actual sliders to what I want I do not save a profile I use global and save that it is what works. and fyi I Moved from flux to Z turbo for that reason. Agreed tweaking is not getting the great results the other have...Z turbo with these settings fly!

[harkgill-amd]

Yup, Z-Image Turbo on Strix Halo is running great, ~10s per prompt generating some neat images. As a side note, you shouldn't need the HSA_ENABLE_SDMA=0 and HSA_USE_SVM=0 with the latest 7.11 TheRock nightlies. If you do see any issues (hangs, crashes.etc) after removing these, please file an issue and we'll take a deeper look at what's going on.

[fjankovi]

@bkpaine1 The issue with crashes is explained here: #2991

In addition to the 7.11 nightlies you will need the kernel fix which is available in Ubuntu oem kernel (1018 and newer). The OEM kernel is recommended for 'legacy' releases, i.e. the upcoming ROCm 7.2.

@harkgill-amd is correct, you won't need to use HSA_ENABLE_SDMA=0 anymore with this issue fixed.

[vinsunfeng]

Thanks for this thread — it got us to an LTX-2.3 A2V (video+audio, lip-synced talking head) pipeline working on Strix Halo too. Adding two env vars we found that give a significant speedup for mid-length video sequences, in case they help others:

-e HIP_FORCE_DEV_KERNARG=1
-e PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True

Frame-count bisection on our workload (LTX-2.3 22B bf16, 544x960, 8-step distilled, 3-LoRA stack, PromptRelay; ComfyUI 0.33 + TheRock rocm10.1 preview nightly, torch 2.15.0a0+rocm10.1.0a20260821):

frames	seq tokens	per-step (stock env)	per-step (+both vars)
73	~5.2k	35.3 s	(linear region)
97	~7.1k	72.8 s	49.0 s (-33%)

• HIP_FORCE_DEV_KERNARG=1 alone: -17.5% (kernel args in device memory instead of host-pinned — that fetch path gets amplified once GTT is heavily populated)
• PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True adds the rest (avoids allocator map/unmap churn against a large GTT working set)
• HSA_ENABLE_SDMA=0: no measurable gain on top (tested)

Caveat: at long sequences (~15.8k tokens, 233 frames) we still hit a super-linear collapse that none of these (nor fp8 weights, nor fp16, nor SDMA/SVM toggles) fix — full bisection data tracked in #7569.

Also for anyone hitting Input type (float) and bias type (c10::BFloat16) in LTXVAudioVAEEncode: that's the --bf16-vae launch flag conflicting with the audio VAE on ComfyUI 0.33 (Comfy-Org/ComfyUI#13550) — dropping the flag fixes it; the video VAE stays bf16 via its own loader anyway.