Skip to content

[REQ] Add opt-in setting to enable builtin approximates for wp.inverse and wp.division #1199

Description

@sarichardson-nv

Description

Add an opt-in parameter: "use_rcp_approx", to disable/enable the explicit usage of the PTX intrinsic "div.approx" and "rcp.approx" for both FP32/FP64-based matrix inverses (wp.inverse) and division (wp.div).

i.e.
wp.div(a, b, use_rcp_approx = True)
wp.inverse(a, use_rcp_approx = True)

Activity

  1. changed the title [-][REQ] Add opt-in reciprocal approximate setting to wp.inverse and wp.division[/-] [+][REQ] Add opt-in builtin approximate setting to wp.inverse and wp.division[/+] on Jan 28, 2026
  2. changed the title [-][REQ] Add opt-in builtin approximate setting to wp.inverse and wp.division[/-] [+][REQ] Add opt-in setting to enable builtin approximates for wp.inverse and wp.division[/+] on Jan 28, 2026
  3. added this to the 1.12.0 milestone on Feb 2, 2026
  4. shi-eric commented on Feb 21, 2026

    @shi-eric
    Contributor

    This is now available on main (e8106c0). Rather than adding an opt-in parameter to the existing wp.div() / wp.inverse(), we introduced two new built-in functions:

    • wp.div_approx(a, b) — uses div.approx.f32 for float32; for float64, uses rcp.approx.ftz.f64 followed by a multiply (no div.approx.f64 exists in PTX)
    • wp.inverse_approx(a) — uses rcp.approx.f32 for float32 and rcp.approx.ftz.f64 for float64

    This approach keeps the semantics explicit: callers opt in by choosing a different function rather than toggling a flag. Both fall back to exact arithmetic on CPU. Only floating-point scalar types are supported.

    Will ship in the 1.12.0 release.

  5. c0d1f1ed commented on Feb 22, 2026

    @c0d1f1ed
    Contributor

    The merged changes look good but one thing worth noting is that it might be unexpected that float16 approximate division falls back to using full float32 division. It would make more sense to use the 32-bit div_approx. Not an immediate priority though.

  6. shi-eric commented on Feb 22, 2026

    @shi-eric
    Contributor

    The merged changes look good but one thing worth noting is that it might be unexpected that float16 approximate division falls back to using full float32 division. It would make more sense to use the 32-bit div_approx. Not an immediate priority though.

    Sounds good, I'll prepare a change for this today so we don't have to risk confusing people with a behavior change in a future release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

feature requestRequest for something to be added

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions