examples: add the FP component examples under examples/cudax/fp - #11273
Draft
akolesov-nvidia wants to merge 7 commits into
Draft
examples: add the FP component examples under examples/cudax/fp#11273akolesov-nvidia wants to merge 7 commits into
akolesov-nvidia wants to merge 7 commits into
Conversation
Four examples covering the extended and reduced precision floating-point types, with the documentation that goes with them. They land in the consumer example tree, which acquires CCCL through CPM and so builds the way a user of the released library would, since these are meant as customer entry points. Each one reports from the host and from the device in a single run: the functions doing the arithmetic are __host__ __device__, so the build already carries both copies and main only has to call one and launch the other. That also names the GPU the device results came from. A missing GPU is not an error, the device section is skipped. The fpmp and fpemu readme open with what the types buy, measured on the pi benchmark and quoted with the caveats that go with the numbers: the software quad comparison reverses on FP64-limited hardware, the tied digit count is the benchmark's own truncation floor rather than equivalent formats, and the pipe-splitting figure is an upper bound with no such kernel built yet. The fp_custom example holds its two inputs as doubles so the constants are written once. Building each reduced format from a native fp_custom value would work, but only because that source's operator float() is explicit; from any other format the same spelling is ambiguous, there being no conversion between two fp_custom instantiations. The doc records that gap, the route through double, and the caveat that it carries the value the source was given rather than the one its format would produce.
Contributor
Contributor
Author
|
/ok to test 165c2c3 |
This comment has been minimized.
This comment has been minimized.
miscco
approved these changes
Sep 9, 2026
miscco
left a comment
miscco
left a comment
Contributor
There was a problem hiding this comment.
Looks good.
Some nits and one request for cmake improvements
Review feedback on NVIDIA#11273. The fp samples are picked up with a CONFIGURE_DEPENDS glob rather than a hand-kept list, so adding one needs no edit here. This follows what the cub and thrust examples already do; examples/cudax listed names only because vector_add was the sole entry and there was no list to maintain. The two fpemu inputs become named constants at file scope, next to the existing drift constants. Each literal appeared four times per kernel, and naming them groups the accuracy-level declarations by value as asked. Output is unchanged, byte for byte.
Contributor
Author
|
/ok to test f937476 |
This comment has been minimized.
This comment has been minimized.
Contributor
Author
|
Thank you for looking into that, colleagues! Could you please merge this PR if no other suggestions? Then I will be able to proceed with main documentation development with links to these examples. Thanks! |
davebayer
requested changes
Sep 11, 2026
davebayer
left a comment
davebayer
left a comment
Contributor
There was a problem hiding this comment.
These examples need to be rewritten using CCCL Runtime, we want the examples to highlight our best practices
Review feedback on NVIDIA#11273. The device half of each example now goes through the runtime rather than the CUDA runtime API: cuda::devices to find a GPU, a cuda::stream to submit on, cuda::make_pinned_buffer for the results the kernels write back, and cuda::launch for the launches themselves. Errors arrive as exceptions, so the per-call status checks give way to a catch on main. Pinned memory is enough here, each result being one struct that the host reads once the stream has drained. The fpemu stack limit has no runtime equivalent, so it remains a CUDA runtime call, now with its status checked.
Contributor
Author
|
/ok to test c127fca |
This comment has been minimized.
This comment has been minimized.
The pinned memory pool arrived in 12.9, so reaching for make_pinned_buffer left these uncompilable on the 12.0 packaging job. Each example now picks its results buffer by toolkit version: the pinned pool where it exists, since writing memory the host reads directly is the point of the pattern, and a device buffer brought back with cuda::copy_bytes below that. Both paths were run against one GPU and print the same bytes.
Contributor
Author
|
/ok to test 0e7cf3d |
Contributor
🥳 CI Workflow Results🟩 Finished in 5m 35s: Pass: 100%/9 | Total: 30m 52s | Max: 5m 15s | Hits: 100%/856See results here. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Four examples covering the extended and reduced precision floating-point types, with the documentation that goes with them. They land in the consumer example tree, which acquires CCCL through CPM and so builds the way a user of the released library would, since these are meant as customer entry points.
Each one reports from the host and from the device in a single run: the functions doing the arithmetic are host device, so the build already carries both copies and main only has to call one and launch the other. That also names the GPU the device results came from. A missing GPU is not an error, the device section is skipped.
The fpmp and fpemu readme open with what the types buy, measured on the pi benchmark and quoted with the caveats that go with the numbers: the software quad comparison reverses on FP64-limited hardware, the tied digit count is the benchmark's own truncation floor rather than equivalent formats, and the pipe-splitting figure is an upper bound with no such kernel built yet.
The fp_custom example holds its two inputs as doubles so the constants are written once. Building each reduced format from a native fp_custom value would work, but only because that source's operator float() is explicit; from any other format the same spelling is ambiguous, there being no conversion between two fp_custom instantiations. The doc records that gap, the route through double, and the caveat that it carries the value the source was given rather than the one its format would produce.
Description
closes
Checklist