Andrea Arcangeli

> Please update and test, the `gptel-rewrite-directive-hook` should now be evaluated in the request buffer, and not in a temporary buffer. Perfect, the fix works. Is there now a way...

> The only way I can think of is based on gptel's version, which is not a runtime check. I can add a `gptel-version` defconst, but it won't change between...

> I meant that it won't change between two releases. The fix for this issue is in a commit in between gptel 0.9.9.3 and 0.9.9.5, and `gptel-version` will only change...

That I would prefer too indeed. It didn't appear possible, but I didn't spend much time trying.

Thanks for the quick feedback. Yes, if I'd build for fewer targets it would succeed, but I already removed gfx1103 as I've been building for a older codebase where gfx1103...

Would it be possible to split the librocblas.so.4.0 in librocblas-gfx900.so.4.0 librocblas-gfx90a.so.4.0 librocblas-gfxXYZ.so.4.0... so each individual gfx target lands in a different shared library, and then have the main librocblas.so.4.0 dynamically...

I appreciate your suggestion above. I agree that's the least bad solution for the time being and I already gave it. If there's other ways to fix it, would you...

https://src.fedoraproject.org/rpms/python-torch/blob/rawhide/f/python-torch.spec#_998 https://src.fedoraproject.org/rpms/python-torch/blob/rawhide/f/python-torch.spec#_37 https://src.fedoraproject.org/rpms/rocm-rpm-macros/blob/rawhide/f/default https://src.fedoraproject.org/rpms/rocm-rpm-macros/blob/rawhide/f/gfx9 https://src.fedoraproject.org/rpms/rocm-rpm-macros/blob/rawhide/f/gfx90a https://src.fedoraproject.org/rpms/rocblas/blob/rawhide/f/rocblas.spec#_117 https://src.fedoraproject.org/rpms/rocblas/blob/rawhide/f/rocblas.spec#_142 https://src.fedoraproject.org/rpms/rocsolver/blob/rawhide/f/rocsolver.spec#_136 rocsolver has also the loop, but because it depends on rocblas it's not possible to tell if rocsolver is like yet another...

About the possible solutions mentioned, I agree that your -mcmodel= (I suppose "medium") suggestion for the short term appears the most attractive solution. In fact, wishful thinking, I wonder if...

@IMbackK agreed: running different gfxN in the same app has become impossible as result of the 5 rocm builds with the finegrined split. That is on top of having to...