Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support IMul/UMul/UDiv with two outputs from HLSL #6727

Open
tex3d opened this issue Apr 10, 2020 · 9 comments
Open

Support IMul/UMul/UDiv with two outputs from HLSL #6727

tex3d opened this issue Apr 10, 2020 · 9 comments
Labels
enhancement Feature suggestion high-impact For high impact usability issues
Milestone

Comments

@tex3d
Copy link
Contributor

tex3d commented Apr 10, 2020

IMul/UMul/UDiv ops with two outputs have been part of the shader models since 4.0, but HLSL has never explicitly exposed these to HLSL so they could be fully used.

This is the suggestion that we should add new intrinsic functions to HLSL that map to these DXIL ops, which could open up scenarios without requiring the optional 64-bit support to be used.

@jstoecker
Copy link

The UMul instruction, in particular, is useful for implementing the Philox-4x32 pseudorandom number generator. This is one of the fastest PRNGs available for GPUs, since it is non-sequential, and mulhi/mullo (the two outputs of UMul) are at at the core of the Philox algorithm. Philox is commonly used for hardware-accelerated machine learning frameworks to initialize random weights in a model.

This instruction is exposed as umulExtended in GLSL.

@fdwr
Copy link

fdwr commented Dec 3, 2021

@tex3d Needing this even more now, after having implemented several int64 operators in DirectML. The equivalent emulation is very verbose.

@oscarbg
Copy link

oscarbg commented Aug 19, 2022

+1

@llvm-beanz llvm-beanz added the needs-triage Awaiting triage label Jun 29, 2023
@llvm-beanz
Copy link
Collaborator

@tex3d, while these operations have been defined in older shader models we don’t have any tests for them at runtime. Is this something we could safely expose without a shader model revision, or do we need to gate this on a new shader model?

@tex3d
Copy link
Contributor Author

tex3d commented Jul 13, 2023

@llvm-beanz

we don’t have any tests for them at runtime

The shader5x HLK test does test these operations for D3D11, and we test them in DXIL by running that test, through translation. That means we should be able to safely expose these operations to HLSL.

@llvm-beanz llvm-beanz added enhancement Feature suggestion and removed needs-triage Awaiting triage labels Jul 13, 2023
@llvm-beanz
Copy link
Collaborator

Sounds good. Tagging this as a feature request. We'll need to prioritize this request and spec it out.

@fdwr
Copy link

fdwr commented Jul 13, 2023

Tagging this as a feature request.

Cool. Will be happy to simplify affected parts of the DirectML code 🙂.

@damyanp damyanp transferred this issue from microsoft/DirectXShaderCompiler Jun 26, 2024
@damyanp damyanp transferred this issue from microsoft/hlsl-specs Jun 26, 2024
@damyanp damyanp added the high-impact For high impact usability issues label Jun 26, 2024
@damyanp
Copy link
Member

damyanp commented Jun 26, 2024

This does not require a SM change. We need to add new intrinsics and can enable them retrospectively for older SM's, but we already have other code paths that generate these DXIL operations.

@damyanp damyanp added this to the Backlog milestone Jun 26, 2024
@damyanp
Copy link
Member

damyanp commented Jun 26, 2024

@davidcook-msft to figure out priority/urgency for this with impacted teams.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Feature suggestion high-impact For high impact usability issues
Projects
Status: Triaging
Status: MSFT Triaging
Development

No branches or pull requests

6 participants