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

GPU acceleration #16

Open
reinismu opened this issue Oct 12, 2024 · 1 comment
Open

GPU acceleration #16

reinismu opened this issue Oct 12, 2024 · 1 comment

Comments

@reinismu
Copy link
Contributor

First of all this is super cool project! Been trying myself to properly implement latest tech in poker for some time now.

Today was playing around with robopoker and looking what to improve. As almost all compute is run in parallel, GPU seems to be a good thing to use.

From what I saw https://github.com/charles-r-earp/krnl seemed to be the best to approach it. I moved cards into separate repo, flagged out STD code part, but run into limitation that rust-gpu can't compile down Option<T> or similar Enums. If that gets solved I assume core part could be rewritten to iterators to not require alloc and we could use GPU to crunch data.

I would open a PR, but code is a bit of a mess.

Anyway, this is super exciting project 💯

@krukah
Copy link
Owner

krukah commented Oct 12, 2024

thanks! it's a little bit of a milestone for me (& the project) to have the first person to open up an issue here, so really appreciate taking the time to play around and bring this up!

i've only barely considered GPU acceleration up until this point, so it's great to have this on the radar. i've mostly been intimidated by having to refactor some of the Vec and [BTree | Hash]Map dependencies. coincidentally, i actually just yesterday managed to eliminate Vec allocations in evaluation.rs, even though that was motivated by me wanting to speed up Hand evaluation from ~200ns to ~10ns, rather than enabling GPU compatibility.

anyway, i think the only other allocations that are part of the core cards module are some std::fmt::Display implementation, and some Vec<Card> <=> Hand bijections, neither of which are that necessary to core functionality.

not sure if relevant for your use case, but the clustering module, outside of the scope of the core cards, depends on some (deterministic) exhaustive enumerations of Observations that could be refactored into fixed-length [Observation; N] arrays. but then this is also where there are lots of *Map allocations that are quite a bit more tricky and intimidating to refactor.

i'd be happy to take a look at your fork though, and offer any help i can! appreciate the interest 🫡

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

2 participants