Clarification on future support for gfx1100-class GPUs (e.g., RDNA3)

[tedliosu]

Hi there,

I've been experimenting with hipDF and managed to get it running successfully on an AMD Radeon RX 7600 XT 16GB (gfx1102), after applying a set of patches to propagate gfx1102 support across hipDF and its dependent libraries. I also noticed that the codebase includes references to gfx1100, which seems to suggest some intention to support RDNA3 or similar devices.

However, the current documentation (e.g., README and supported devices list) states that only gfx942 and gfx90a are officially supported — corresponding to CDNA-based MI200 and MI300 datacenter GPUs.

Could you clarify:

1. Whether gfx1100/RDNA3 support is intended to be maintained moving forward, or if its presence in the codebase is vestigial?

2. If support for devices like the 7600XT is likely to remain unofficial, or might be promoted to supported status in future releases?

3. Whether there are known limitations, testing gaps, or validation issues when running on consumer-grade RDNA3 GPUs. For example, when repeatedly running the same hipDF script workload on my RX 7600 XT, I occasionally encounter errors like:

Memory access fault by GPU node-1 (Agent handle: 0x55b02db3bc10) on address 0x7f5c3b400000. Reason: Page not present or supervisor privilege.
Fatal Python error: Aborted

• This kind of error surfaces intermittently — sometimes up to once every 4–5 runs — and may suggest that the ROCm/libcudf stack that hipDF builds upon hasn't been fully validated for RDNA3 hardware like the 7600 XT. I'd appreciate any insight on whether such behavior is expected on unsupported or unofficially supported hardware.

Thanks for your work on this project—I’d be happy to share patches or notes from my setup if it helps!

[mrvictory1]

Hello, I have Radeon RX 7700 XT (gfx1101) and here is my experience:

• RDNA3 is unofficially supported in some capacity: the build.sh script on root of the repository has a --warpsize32 switch. When this switch is used, only adding gfx1101 (or gfx1102 in your case) to CMakeLists.txt is needed for compilation to succeed.
• I get similar segmemtation faults when running on 7700 XT. The errors are more likely to happen if I abort a trial, leaving allocated VRAM, and start another trial. I don't have a definite solution.

[tedliosu]

Thanks for sharing your experience @mrvictory1, really appreciate it!

From your note about the segfault behavior you describe on your 7700 XT, it sounds like aborting mid-run and leaving VRAM allocated makes the problem more likely — have you also seen crashes when running multiple trials cleanly back-to-back with explicit memory cleanup in between like I have?

Also, I’m curious: were you testing with ROCm 6.3.x or 6.4.x? I previously filed an issue about driver timeouts with binaries compiled with ROCm 6.4.x that make use of the now deprecated __AMDGCN_WAVEFRONT_SIZE__ macro, so it’d be interesting to know if hipDF stability is different across the two versions on RDNA3 hardware in general.

Glad to see another RDNA3 user testing hipDF — hopefully we can help surface these edge cases for the devs.

[mrvictory1]

I'm using ROCm 6.4.2. I'm also using Python 3.12 and Ubuntu 24.04. As far as I understand, Python 3.10 is the only officially supported version, my configuration is unsupported. With explicit memory cleanups I still have crashes but they are much rare. I can run without crashes for 100+ runs, 2-3 hours.

Using .iloc on a cudf.Dataframe triggers an instant segfault.

[tedliosu]

Thanks @mrvictory1 for sharing your details! Here’s my setup and experience for comparison:

• GPU: Radeon RX 7600 XT (gfx1102)
• OS: Ubuntu 24.04 (officially supported by hipDF)
• Python: 3.10.17 (conda-forge build provided by Miniforge)
• ROCm: 6.3.4 (driver used is latest 6.4.3 ROCm driver at current time of writing, but that is OK since +/- 1 year version skew is now officially supported by ROCm kernel drivers)

On this configuration, .iloc works correctly. For example, I was able to reproduce the tips.csv dataset demo from the hipDF README (creating a new column and running a groupby/aggregate) as well as accessing a scalar via .iloc[1, 7] without segfaults.

That said, I did have to make several tweaks beyond the default hipDF build instructions to get things running reliably:

• Installed Python ROCm packages (e.g. numba-hip) pinned to ROCm 6.3.4 inside my conda environment.

• Built hipDF itself against ROCm 6.3.4. With ROCm 6.4.x, certain ops (like datetime calcs) would trigger ring gfx timeouts requiring a hard reset.

• Patched [conda env root]/lib/python3.10/site-packages/numba/hip/hipdrv/driver.py around line 585 to handle non-standard UUID lengths. My replacement looked like:

  fmt = None
  if len(uuid_vals) != 16:
      non_std_fmt_part = "".join(["%02x" for _ in uuid_vals])
      fmt = f"GPU-{non_std_fmt_part}"
  else:
      fmt = f"GPU-{b4}-{b2}-{b2}-{b2}-{b6}"

So in my case, with ROCm 6.3.4 + Python 3.10, the README demo runs end-to-end fine (including an extra .iloc) on RDNA3 hardware.

At this point I’m not planning to test ROCm 6.4.x myself, since those builds tend to hit ring GFX timeouts on my system. But my working 6.3.4 setup should provide a known-good baseline for RDNA3, which might help maintainers and testers triangulate whether your segfaults are tied to ROCm 6.4.x, Python 3.12, or their interaction rather than RDNA3 support alone.

Hopefully this gives maintainers a clearer picture: .iloc is functional on a supported config, while ROCm 6.4.x + Python 3.12 appears unstable even with explicit cleanup.

[mrvictory1]

Which libraries you use interact with cuDF? I'm training models using ROCM's fork of Xgboost and I had crashes when fitting Xgboost. I compiled a debug build of Xgboost by appending the following to cmake: -DCMAKE_BUILD_TYPE=Debug -DCMAKE_C_FLAGS_DEBUG="-g -O0" -DCMAKE_CXX_FLAGS_DEBUG="-g -O0". There are no crashes so far, still more testing is needed.