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

OpenCL support #1214

Open
cryptoquick opened this issue Feb 25, 2023 · 3 comments
Open

OpenCL support #1214

cryptoquick opened this issue Feb 25, 2023 · 3 comments

Comments

@cryptoquick
Copy link

I've been looking for versions of secp256k1 that can run on GPUs. I've found this project, which seems like a fork: https://github.com/ilaychen/ECDSA-OpenCL

Maybe it would make sense to upstream some of these changes, to better support GPU acceleration? Am willing to donate 7900 XTX to Sipa.

I saw this comment: #502 (comment)

I'm not sure what that meant other than it's possible, and GPUs certainly have improved since that paper was written 10 years ago. It might make sense to revisit this.

@real-or-random
Copy link
Contributor

Thanks for the suggestion.

GPU supports sounds very interesting for speeding up verification, but I doubt that this is something we should add to our roadmap. (We don't have a written roadmap, but if we had one, I don't think it would be on it. The lack of responses here confirms this.) That means, feel free to work on it, and maybe then there's a chance to get this accepted. But don't expect us to spend time on this right now.

@apoelstra
Copy link
Contributor

It might be interesting to try to outline what would be needed to make such changes upstreamable here.

I would guess that changing scalar/field datatypes wouldn't be acceptable. Probably not changing entire algorithms ... but maybe if there was like like, an entire new ecmult_multi_opencl_impl.h which normally isn't compiled in, that could be ok? And changing the build system and adding new SECP256K1_ attributes to functions (which are suitably #ifdefed in util.h) woud probably be fine.

@real-or-random
Copy link
Contributor

real-or-random commented Mar 8, 2023

I think as long as it's an additional implementation that can be turned off (we certainly want to keep targeting CPU-only users), there's not even a fundamental reason not to change datatypes or algorithms. It's "just" an additional burden to maintain multiple algorithms, but that's one of many variables that would influence a decision to merge (amount of performance improvement, maintainer buy in/skills, reviewer power, ...)

FWIW, here's an ancient thread about this topic: https://bitcointalk.org/index.php?topic=3238.0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants