Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 3 additions & 0 deletions Inc/DirectXMath.h
Original file line number Diff line number Diff line change
Expand Up @@ -86,6 +86,9 @@
#define _XM_SSE_INTRINSICS_
#elif defined(_M_ARM) || defined(_M_ARM64) || defined(_M_HYBRID_X86_ARM64) || defined(_M_ARM64EC) || __arm__ || __aarch64__
#define _XM_ARM_NEON_INTRINSICS_
#elif defined(__riscv)

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do you need to update the library instead of just defining -D_XM_NO_INTRINSICS_ in your build?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right that defining _XM_NO_INTRINSICS_ is sufficient, so this change is not required to make a RISC-V consumer build.

The narrower rationale for handling __riscv in the header is to give a recognized target a consistent default. DirectXMath is header-only and is often included transitively, so otherwise every consumer build must know about and propagate a DirectXMath-specific macro to every translation unit. Selecting the existing scalar implementation avoids that integration requirement; it does not claim RISC-V intrinsics, RVV optimization, or comprehensive platform validation.

I have narrowed the PR accordingly: it now contains only the target-selection change and a short documentation note. I removed the CMake message and the RISC-V-specific changes to the x86 extension headers.

If the project's policy is that scalar-only targets should explicitly opt in with _XM_NO_INTRINSICS_, then the build define is the appropriate solution and the library change is not strictly necessary.

// RISC-V currently uses the existing scalar no-intrinsics implementation.
#define _XM_NO_INTRINSICS_
#elif !defined(_XM_NO_INTRINSICS_)
#error DirectX Math does not support this target
#endif
Expand Down
2 changes: 2 additions & 0 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -77,6 +77,8 @@ copilot

Officially the library is supported with Microsoft Visual C++ 2019 (16.11) or later, clang/LLVM v12 or later, and GCC 10 or later. It should also compile with the Intel C++ and MinGW compilers.

On RISC-V targets, DirectXMath selects its existing scalar `_XM_NO_INTRINSICS_` implementation by default. This does not provide any RISC-V vector or assembly optimizations.

When building with clang/LLVM or other GNU C compilers, the ``_XM_NO_XMVECTOR_OVERLOADS_`` control define is set because these compilers do not support creating operator overloads for the ``XMVECTOR`` type. You can choose to enable this preprocessor define explicitly to do the same thing with Visual C++ for improved portability.

To build for non-Windows platforms, you need to provide a ``sal.h`` header in your include path. You can obtain an open source version from [GitHub](https://raw.githubusercontent.com/dotnet/runtime/main/src/coreclr/pal/inc/rt/sal.h).
Expand Down