[xrt] update to 2.23#14225
Conversation
Bump to the XRT the AMD XDNA (RyzenAI NPU) stack pins -- 202610.2.23.0, the commit the xdna-driver submodule tracks -- whose xclbinutil packages the AIE_PARTITION/PDI sections mlir-aie's aiecc emits for AIE2p (npu2) and whose runtime (libxrt_coreutil) a Python-free host drives. - Fetch submodules recursively: 2.23 pulls xdp, aiebu, aie-rt, gsl, elf (etc.) in as submodules GitSource does not fetch, so configure otherwise fails on the missing CMakeLists in runtime_src/xdp and core/common/aiebu. - fix-install-dir.patch dropped: 2.23 sets XRT_INSTALL_DIR to "." upstream. - Windows mingw patches triaged against the 2.23 source: config_reader (__linux__), fix_xclbinutil_cmake/xbutil (mingw winsock links) and unistd (<shlobj.h>) / remove_duplicate_type_defs were upstreamed by PR JuliaPackaging#8387 and follow-ups, so they are dropped (left unused in ./bundled). The BinaryBuilder-specific ones are re-ported to 2.23: no_static_boost (the mingw boost_jll is shared-only) and disable_trace (mingw lacks TraceLoggingProvider.h, now stubbed behind a __MINGW32__ guard), alongside aligned_malloc which still applies as-is. - Products: dropped xbutil (removed upstream, replaced by xrt-smi); libxrt++ kept. Linux configure passes here; the Windows build is unverified -- any remaining still-needed mingw patch would surface as a specific CI error. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The aiebu submodule requires CMake >= 3.24 on Windows, but the builder image
ships 3.21. Drop the system cmake (apk del cmake) and add
HostBuildDependency("CMake_jll") so the newer host CMake is used, mirroring the
mlir_aie recipe.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The typedefs in core/include/xrt/detail/windows/types.h clash with mingw's own ssize_t/pid_t. Upstream added a guard but wrote __GNU__ (GNU Hurd), which mingw never defines, so it never fired. Guard on __GNUC__ instead (this is a Windows-only header, so the only non-MSVC compiler is mingw gcc). The file moved from core/include/windows/ since 2.17, so the old patch had stopped applying. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Windows configures and compiles part way, but the mingw build hits XRT's MSVC-isms -- __declspec(dllimport) on inline definitions across the many XRT_API_EXPORT headers -- which needs a Windows CI loop to work through. The re-ported mingw patches (no_static_boost, disable_trace, remove_duplicate_type_defs, aligned_malloc) stay applied in the script, so re-enabling Windows is just adding the platform back. Also simplify the platform spec to a plain x86_64-linux-gnu list instead of filtering supported_platforms(). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
Doesn't quite work standalone yet, marking as a draft until I figure it out |
The xdna userspace driver plugin (libxrt_driver_xdna.so) is what XRT's driver_plugin_paths() scans for next to the shim; XRT.git does not build it, so build it from the xdna-driver source alongside XRT and co-locate it in lib/. Two build fixes on top of the existing workarounds: - drop src/shim/virtio/*.cpp: the virtio-gpu (VM-guest) backend needs recent VIRTGPU blob/context UAPI the libdrm headers lack, and a native NPU host never uses it (each pci backend self-registers, so nothing dangles). - link libdl (dladdr) and libpthread (pthread_create), which the shim's CMakeLists omits and BB's split glibc + -Wl,-z,defs make fatal.
Condense the A-F workaround comments to 1-2 lines each, and correct D's rationale: libdrm is needed for <drm/drm.h> in host/platform_host.cpp (the native path), not just the now-removed virtio backend. No commands changed.
|
OK, it works! I added an XDNA shim exposed as |
|
Since you are removing Windows, please document what is broken on that platform. |
I managed to fix the windows build in the end. I will look into upstreaming at least some of these tomorrow
I wasn't aware of that PR actually, very cool! Maybe we can collaborate on some parts of this. My goal is being able to program AMD Ryzen AI NPUs directly from within Julia, similar to https://github.com/amd/IRON for Python. Right now it's still kind of sloppy, but it works, I am working on cleaning it up. Since that PR targets an older version though, I don't think there would be any harm in merging this and the two versions coexisting in parallel |
That PR was going to introduce a side-by-side versioning scheme, with 2.16 and 2.17 build scripts side-by-side (I hadn't looked closely why it was side-by-side, but IMO it is fine to do), so maybe you can do something similar here and put the NPU-capable version side-by-side the current? I have been also wanting to get XRT bindings put together, but for FPGA kernel launches, not NPUs. Just need to find the spare cycles to actually work on that... |
Do you mean just moving this to a folder |
Yep, just making a side-by-side folder would be enough, that would also help to avoid merge conflicts with the other open PR. If there are parts that could be shared, then we can abstract out a common file (does the common file in the other PR look useful?) |
I don't see a common file? |
🤦♂️ Thought I saw one when I scanned it again today, but there isn't one right now. |
2 participants
Unfortunately, this removes the windows platform. I had claude try to fix the windows build as well, but it eventually got too unwieldy, so for now only build for linux. I still kept the windows patches with the partial fixes applied, but if desired, I can also remove those.