[API Proposal]: Add X86 and ARM hardware intrinsics for RDRAND/RDSEED/RNDR/RNDRRS and AMX/SME/APX

[ahmetenesay]

Background and motivation

We propose adding explicit low-level hardware intrinsics for high-performance CPU extensions that are currently missing from System.Runtime.Intrinsics.X86 and System.Runtime.Intrinsics.Arm.

This proposal targets three major CPU instruction domains:

1. Hardware Entropy / True Random Generation (RDRAND/RDSEED on x86, RNDR/RNDRRS on ARMv8.5-A FEAT_RNG):
   Currently, .NET developers requiring hardware entropy must fallback to RandomNumberGenerator (P/Invoke to BCryptGenRandom or getrandom), which introduces unacceptable syscall and interop overhead in tight simulation loops (e.g., ray tracing, Monte Carlo simulations, or game engine procedural generation). Exposing direct processor hardware entropy registers allows sub-nanosecond random UInt64 generation with zero allocation.

2. Hardware Matrix Acceleration (AMX on Intel/AMD, SME/SME2 on ARMv9-A):
   Modern high-performance compute workloads (on-device AI inference, 3D skeletal skinning, pathfinding, and physics) rely heavily on matrix multiplication ($A \times B + C$). While vector extensions (AVX-512, AVX10, SVE) process 1D vectors, AMX (x86 Tile registers) and SME (ARM Tile matrices) operate directly on 2D matrix tiles in hardware. Exposing these intrinsics gives C# game engines and native ML runtimes equal footing with C++/CUDA pipelines without native DllImport overhead.

3. Explicit APX API Exposure (Apx.IsSupported):
   While .NET 10 introduced implicit JIT codegen support for Intel APX, exposing an explicit intrinsic class allows low-level developers to query support (Apx.IsSupported) and perform conditional branching for high-performance data structures.

API Proposal

namespace System.Runtime.Intrinsics.X86
{
// ==========================================
// 1. Hardware Random Number Generation (x86)
// ==========================================
public abstract class Rdrand : X86Base
{
public static new bool IsSupported { get; }

    /// <summary>
    /// Executes the RDRAND instruction to retrieve a hardware-generated random 16-bit value.
    /// Returns false if hardware entropy pool was not ready (CF = 0).
    /// </summary>
    public static bool TryGetUInt16(out ushort result);

    /// <summary>
    /// Executes the RDRAND instruction to retrieve a hardware-generated random 32-bit value.
    /// </summary>
    public static bool TryGetUInt32(out uint result);

    /// <summary>
    /// Executes the RDRAND instruction to retrieve a hardware-generated random 64-bit value.
    /// </summary>
    public static bool TryGetUInt64(out ulong result);
}

public abstract class Rdseed : X86Base
{
    public static new bool IsSupported { get; }

    public static bool TryGetUInt16(out ushort result);
    public static bool TryGetUInt32(out uint result);
    public static bool TryGetUInt64(out ulong result);
}

// ==========================================
// 2. Advanced Matrix Extensions (AMX)
// ==========================================
public abstract class Amx : X86Base
{
    public static new bool IsSupported { get; }

    // Tile Configuration & Control
    public static void TileConfig(ReadOnlySpan<byte> tilecfg);
    public static void TileRelease();

    // Tile Matrix Operations
    public static void MultiplyAndAddBF16(byte dstTile, byte src1Tile, byte src2Tile);
    public static void MultiplyAndAddInt8(byte dstTile, byte src1Tile, byte src2Tile);

    // Tile Load & Store
    public static unsafe void TileLoad(byte tile, void* baseAddress, nint stride);
    public static unsafe void TileStore(byte tile, void* baseAddress, nint stride);
}

// ==========================================
// 3. Advanced Performance Extensions (APX)
// ==========================================
public abstract class Apx : X86Base
{
    /// <summary>
    /// Indicates whether Intel APX (Extended GPRs r16-r31, NDD 3-operand instructions) is supported.
    /// </summary>
    public static new bool IsSupported { get; }
}

}

namespace System.Runtime.Intrinsics.Arm
{
// ==========================================
// 1. Hardware Random Number Generation (ARMv8.5-A FEAT_RNG)
// ==========================================
public abstract class Rng : ArmBase
{
public static new bool IsSupported { get; }

    /// <summary>
    /// Executes 'MRS xt, RNDR' to read true hardware random number.
    /// Returns false if hardware entropy pool was underflowed.
    /// </summary>
    public static bool TryGetUInt64(out ulong result);

    /// <summary>
    /// Executes 'MRS xt, RNDRRS' to read reseeded hardware random entropy source.
    /// </summary>
    public static bool TryGetEntropyUInt64(out ulong result);
}

// ==========================================
// 2. Scalable Matrix Extension (SME / SME2 - ARMv9-A)
// ==========================================
public abstract class Sme : ArmBase
{
    public static new bool IsSupported { get; }

    // Streaming Mode Controls
    public static void EnterStreamingMode();
    public static void ExitStreamingMode();

    // Matrix Tile Operations (Outer Product & Accumulate)
    public static void OuterProductAccumulate(byte tile, Vector128<float> vector1, Vector128<float> vector2);
    public static void OuterProductSubtract(byte tile, Vector128<float> vector1, Vector128<float> vector2);
}

public abstract class Sme2 : Sme
{
    public static new bool IsSupported { get; }
}

}

API Usage

using System;
using System.Runtime.Intrinsics.X86;
using System.Runtime.Intrinsics.Arm;

public static class FastHardwareRandom
{
// Sub-nanosecond Random Generation with hardware cross-platform fallbacks
public static ulong GetNextUInt64()
{
if (Rdrand.IsSupported)
{
if (Rdrand.TryGetUInt64(out ulong val))
return val;
}
else if (Rng.IsSupported)
{
if (Rng.TryGetUInt64(out ulong val))
return val;
}

    // Software Fallback
    return (ulong)Random.Shared.Next64();
}

}

public static class MatrixComputeExample
{
public static void ExecuteMatrixMultiply()
{
if (Amx.IsSupported)
{
// Intel AMX tile multiplication path
// Amx.TileConfig(...);
// Amx.MultiplyAndAddBF16(0, 1, 2);
// Amx.TileRelease();
}
else if (Sme.IsSupported)
{
// ARM SME streaming mode matrix multiplication path
Sme.EnterStreamingMode();
// Sme.OuterProductAccumulate(...);
Sme.ExitStreamingMode();
}
}
}

Alternative Designs

1. RNG via System.Random / RandomNumberGenerator:
   An alternative is modifying System.Random or RandomNumberGenerator to internally use RDRAND/RNDR when available. However, high-performance engines require fine-grained control over execution failure checking (evaluating returned boolean flags for CF/underflow) without the allocation and abstraction overhead of managed random generators.

2. Hiding Matrix Extensions behind System.Numerics.Tensors:
   Another design is to only utilize AMX and SME inside high-level APIs like TensorPrimitives. While beneficial for high-level ML, game engine developers writing custom compute shaders, physics engines, or software rasterizers require direct hardware intrinsic access matching C++ intrinsics (<immintrin.h> / <arm_sme.h>).

Risks

1. Hardware / Microcode Quirks:
   Early hardware implementations of RDRAND (e.g., specific older AMD microcodes) occasionally failed to replenish entropy pools under heavy contention. Returning a bool status (TryGetUInt64) directly mitigates this risk by allowing developers to safely fall back to software generators.

2. OS Context Switch Support for AMX/SME:
   Both AMX and SME introduce significant new register states (Tile registers) that require OS kernel save/restore support (XSAVE on Windows/Linux for AMX, and streaming mode state management for SME). Amx.IsSupported and Sme.IsSupported must validate both CPUID flags AND OS kernel enablement flags (e.g., XCR0 bits) to prevent access violation crashes during context switches.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-runtime-intrinsics
See info in area-owners.md if you want to be subscribed.

[ahmetenesay]

I've been wondering all this for so long why it wasn't added; I really needed it!

[huoyaoyuan]

API proposal for hardware intrinsics should be separeted for different instruction sets. The proposal isn't sufficient for hardware intrinsic, which should provide exact match to each instruction.

3. Explicit APX API Exposure (Apx.IsSupported):

Can you provide an exmple how managed code can benefit differently fropm APX? Checking CPUID would be preferred if it matters.

I've been wondering all this for so long why it wasn't added; I really needed it!

For AMX, it at least requires support for the TMM registers. Otherwise the intrinsic can't be represented at all. We have just implemented AVX-VNNI support recently. AMX is much lower priority.
The same is for SME. We are still improving SVE support.

[tannergooding]

I'd start by saying this is batching things together in a way that makes it unlikely to be taken to API review. The asks are only related by being under the same namespace and are very distinct/separate from eachother. One being approved does not mean all would be approved or vice-versa.

Hardware Entropy / True Random Generation (RDRAND/RDSEED on x86, RNDR/RNDRRS on ARMv8.5-A FEAT_RNG):
Currently, .NET developers requiring hardware entropy must fallback to RandomNumberGenerator (P/Invoke to BCryptGenRandom or getrandom), which introduces unacceptable syscall and interop overhead in tight simulation loops (e.g., ray tracing, Monte Carlo simulations, or game engine procedural generation). Exposing direct processor hardware entropy registers allows sub-nanosecond random UInt64 generation with zero allocation.

Even with the syscall/interop overhead, the performance of these instructions are often 2-20x slower than a standard C or C# implemented PRNG. Typical modern versions of these instructions take around 1200-1500 cycles, on the low end, and more if multiple cores are invoking it due to shared hardware state causing contention.

If you're requiring a CSPRNG, then you're using the crypto APIs and there is no relevant argument for performance because the cryptographically secure aspect always comes first, so using these intrinsics would be a non-starter (and non-compliant if you're actually targeting FIPS/etc -- there is a large difference between the instructions themselves meeting compliance reqs and that meaning an arbitrary program using them is also compliant).

On the other hand, if you just need a standard PRNG, then seeding the initial value is fine to use the underlying system call and it will typically be faster and more robust anyways. Particularly because there is the known past security issues that have had to be mitigated around these instructions which are in part why they are so much slower, and at best scenarios should just be using them as an additional source of entropy; not the only source of entropy.

I expect we will never expose these instructions because they are likely the wrong thing in nearly any scenario, including perf, and a P/Invoke to C to access them is not going to make a measurable difference.

Hardware Matrix Acceleration (AMX on Intel/AMD, SME/SME2 on ARMv9-A):
Modern high-performance compute workloads (on-device AI inference, 3D skeletal skinning, pathfinding, and physics) rely heavily on matrix multiplication ($A \times B + C$). While vector extensions (AVX-512, AVX10, SVE) process 1D vectors, AMX (x86 Tile registers) and SME (ARM Tile matrices) operate directly on 2D matrix tiles in hardware. Exposing these intrinsics gives C# game engines and native ML runtimes equal footing with C++/CUDA pipelines without native DllImport overhead.

Both are very new ISA which has very limited hardware support and it isn't clear if it is actually what is going to persist or last over time. It will also require quite a significant amount of deeper design and thought as to how the underlying memory support and other features work for these, particularly in relation to what hardware exposes and requires (often custom alignments, specific shapes, etc).

Notably for AMX, the latest news is that the x86 Ecosystem Advisory Group is centering around ACE instead. Such designs often go through a few iterations prior to hardware actually shipping with it, so we have zero plans to do anything here until real world hardware ships and showcases how this support will persist.

https://x86ecosystem.org/wp-content/uploads/2026/06/ACE_v1_Specification_public_1_15.pdf is the latest spec covering the plans for ACE, which is what both Intel and AMD plan to implement and that it builds on some of the AMX foundations, namely the tile architecture, but doesn't actually include or guarantee that the rest of AMX support is there.

Explicit APX API Exposure (Apx.IsSupported):
While .NET 10 introduced implicit JIT codegen support for Intel APX, exposing an explicit intrinsic class allows low-level developers to query support (Apx.IsSupported) and perform conditional branching for high-performance data structures.

There's no actual proposal provided here, just an empty class declaration. Most of APX is things that the underlying JIT simply naturally emits and there is no actual intrinsic support to be exposed.

[ahmetenesay]

I doubt it's possible to provide an example at every opportunity. But I want to emphasize that, especially as someone who demands high performance and wants to push the limits of their hardware, I desperately need all of this.

[ahmetenesay]

This might sound like an unnecessary "meh..." to you, but I genuinely want to use real hardware entropy, acknowledging that it's slow. My current method for accessing these commands is Inline ASM, but this is a very dangerous, fragile, and immovable method! If you ask what I want to use it for right now, I want to use TRNG as a seed in procedural land generation. Please consider that someone actually needs this kind of thing and reconsider your plans.

[ahmetenesay]

I'd love to respond to your corporate answers with a harsh and critical reply like Linus Torvalds, but there's nothing to argue about here. In fact, the inability to directly use hardware TRNGs in C# is a huge disappointment for me! Also, how could people possibly confuse the TRNG in the System.Runtime.Intrinsics package with a cryptography package (this is like Ford's F150 lawsuit against Ferrari)? Please explain to me clearly why you avoided including this :)

[ahmetenesay]

I think I've been misunderstood; I never target TRNG for speed, and as a physicist-chemist, I know how the process works within the CPU tile.

[tannergooding]

But I want to emphasize that, especially as someone who demands high performance and wants to push the limits of their hardware
...
but I genuinely want to use real hardware entropy, acknowledging that it's slow.

These are largely polar opposite statements.

If you "need" rdrand/rdseed and are acknowledging its slow and that's acceptable, then using a P/Invoke is already sufficient and only adds a couple cycles (around 5-10 nanoseconds) overhead (general noise compared to the nearly microsecond cost of the actual instruction execution). It is trivial and is not blocked in the slightest by .NET providing it or not.

You would explicitly not be using it for high performance or to push the limits of your hardware.

I want to use TRNG as a seed in procedural land generation. Please consider that someone actually needs this kind of thing and reconsider your plans.

You cannot guarantee that such hardware randomization exists in the first place and so you fundamentally need a fallback that uses something like the OS crypto APIs, which will not only be faster but also typically a better sources of entropy and so are far more suited to your task.

These hardware random APIs are not guaranteed to be TRNG and are rather explicitly known to be problematic if used as the only source. The must be combined with other sources and by people who know what they're doing, which the OS random APIs handle (i.e the OS APIs use RDSEED if that is appropriate and additionally pull in other sources of entropy as well where relevant). -- You can somewhat consider that RDSEED is approximately a TRNG, but even that is not quite true; and RDRAND is strictly not a TRNG, but a PRNG/DRBG and has an additional separate CPUID bit indicating if its "enhanced" and more robust (but is still slower and often a worse if used as the only source).

Id love to respond to your corporate answers with a harsh and critical reply like Linus Torvalds, but there's nothing to argue about here. In fact, the inability to directly use hardware TRNGs in C# is a huge disappointment for me

This is beginning to sound like engagement in bad faith. Engaging in a way that is attacking or degrading others, including hinting at it, is not appropriate at any point.

You appear to have some misplaced presumptions about how RDRAND/RDSEED work and how they get used in the real world. None of the responses here are corporate BS or not wanting to surface things or do work. The scenarios and implications have been thought through, including from perf, correctness, fallbacks, what is required to ensure correct CSPRNG, PRNG, or even TRNG usage, etc.

---

As for AMX, it's been covered why that's not being exposed today and that it (or rather ACE) might be supported in the future.

The same over for APX, because there simply is no intrinsics to expose here. It's almost all implicit JIT lightup in the lowering/codegen layer instead; and the same is true of the C++ hardware intrinsics.

[ahmetenesay]

I apologize, I admit I briefly wrote this request to Gemini. Also, I apologize if I appeared offensive or rude and offended you; I want to state that I am genuinely disappointed and that you are right on this one point. I believe the developments in ISA and SIMD have excited many people, including myself. You said that some ISAs are evolving and not permanent, and you are absolutely right! For example, Intel disappointed us all for years with the AVX-512. HOWEVER! Hardware Entropy (TRNG) has been around and established for at least 10 years. Could you please explain your reasons for avoiding adding TRNG, at least on the X86 and ARM64 side? I need to be convinced!