You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 💯
The text was updated successfully, but these errors were encountered:
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 🫡
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 thatrust-gpu
can't compile downOption<T>
or similar Enums. If that gets solved I assume core part could be rewritten to iterators to not requirealloc
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 💯
The text was updated successfully, but these errors were encountered: