Ah. That makes sense. Thanks, Christian!
On 2024-04-04 04:30, Christian Kastner wrote:
I just rebuilt rocfft to 6.0.2 but the issue is still present. But that
was naive, there are other < 6.0 components in the stack that could
affect this.
The problem appeared in rocfft 5.5.1 when rocm-hipamd
On 2024-04-04 09:05, Christian Kastner wrote:
> The issue is already visible with AMD_LOG_LEVEL=1, it's the lack of PCIe
> atomics:
>
>> [ RUN ] rocfft_UnitTest.default_load_callback_complex_single
>> :1:rocvirtual.cpp :2949: 1796815625 us: [pid:1917
>> tid:0x7f4a2102c980] Pcie
On 2024-04-02 00:35, Cordell Bloor wrote:
> I tried to reproduce the rocfft callback bug with a W6800 (gfx1030). I
> used a Debian Unstable docker container on an Ubuntu Noble host, but the
> tests all passed. This made me realize that the test failure pattern on
> the CI is that all the
Hey Cory,
thank you for the analysis. I'll try to reproduce and lock this down on
my end, too.
Best,
Christian
On 2024-04-02 00:35, Cordell Bloor wrote:
> I tried to reproduce the rocfft callback bug with a W6800 (gfx1030). I
> used a Debian Unstable docker container on an Ubuntu Noble host,
I tried to reproduce the rocfft callback bug with a W6800 (gfx1030). I
used a Debian Unstable docker container on an Ubuntu Noble host, but the
tests all passed. This made me realize that the test failure pattern on
the CI is that all the qemu-based workers are failing and all the
podman-based
Package: librocfft0
Version: 5.7.1-1
Severity: normal
X-Debbugs-Cc: c...@slerp.xyz
Dear Maintainer,
The rocfft callback tests were passing with rocfft 5.5.1 on hip 5.2.3,
but began failing when hip was updated to 5.7.1. These failures are
specific to gfx900 and gfx1030 to gfx1036. The failures
6 matches
Mail list logo
