-
Notifications
You must be signed in to change notification settings - Fork 686
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
Comments
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. |
@tex3d Needing this even more now, after having implemented several int64 operators in DirectML. The equivalent emulation is very verbose. |
+1 |
@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? |
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. |
Sounds good. Tagging this as a feature request. We'll need to prioritize this request and spec it out. |
Cool. Will be happy to simplify affected parts of the DirectML code 🙂. |
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. |
@davidcook-msft to figure out priority/urgency for this with impacted teams. |
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.
The text was updated successfully, but these errors were encountered: