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

Documentation (& code) regarding determining temp_storage_bytes not very clear #847

Open
eyalroz opened this issue Mar 31, 2016 · 3 comments
Labels
cub For all items related to CUB good first issue Good for newcomers.

Comments

@eyalroz
Copy link

eyalroz commented Mar 31, 2016

I would like to be able to determine my device-wide primitive's temp_storage_bytes before I have all of the primitive's arguments ready. The interface for obtaining it ostensibly requires everything to be ready for the actual run - and the documentation does not make it clear what arguments it actually needs and what it's going to do with them (e.g. will it look at the input at all, in any way? Probably not, but who knows)

Also, delving into the source (in my case: dispatch_select_if.cuh), I see:

if (d_temp_storage == NULL)
{
    // Return if the caller is simply requesting the size of the storage allocation
    break;
}

which is super-weird. What if I passed a pointer to a size_t containing 2^64-1? Would my code be led to believe it has to allocate that much? Hmm.

@daktfi
Copy link

daktfi commented Jan 20, 2017

From my experience with library, the arguments to calculate temp storage size are data type(s) (templated) and length of it.
I call the methods very early in the code with all pointers set to nullptr and only non-zero argument is size of the data to be processed and get the temp size that works fine till the very end.
Hope this helps.

@dumerrill
Copy link

dumerrill commented Jan 20, 2017

Yep. That is the case for everything currently in CUB: we need to know the data types and length of input. The iterators:pointers can be null.

@alliepiper alliepiper added the good first issue Good for newcomers. label Sep 23, 2020
@alliepiper alliepiper reopened this May 6, 2022
@alliepiper
Copy link
Collaborator

We should add a section to the docs about this. A generic section that explains the common pattern and conventions for using the cub::Device* API would be useful.

@jrhemstad jrhemstad added the cub For all items related to CUB label Feb 22, 2023
@jarmak-nv jarmak-nv transferred this issue from NVIDIA/cub Nov 8, 2023
@miscco miscco removed their assignment Dec 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cub For all items related to CUB good first issue Good for newcomers.
Projects
Status: Todo
Development

No branches or pull requests

6 participants