tag:blogger.com,1999:blog-4801956593085384975.post2962779106904484524..comments2019-01-06T18:08:06.599+02:00Comments on Chess on a GPGPU: Memory vs. speedSamuelhttp://www.blogger.com/profile/08368313655614431067noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-4801956593085384975.post-15408105091573584912013-02-06T18:15:04.814+02:002013-02-06T18:15:04.814+02:00Yes, I can clarify. I forgot to explain the B and ...Yes, I can clarify. I forgot to explain the B and R properly. They contain bishop-like pieces and rook-like pieces, not only bishops and rooks. Queens belong to both categories, bishop-like pieces and rook-like pieces. Then the queens are calculated as an intersection of those two sets (= B & R).<br /><br />I thought about the bitboard-implementation more today. Currently the problem is fitting the move list in the shared memory if I generate all the moves at once. If I cannot find a solution to this problem, I might have to abandon bitboard again.<br /><br />I do not have the code public yet. When I have it working properly, I might publish it.Samuelhttps://www.blogger.com/profile/08368313655614431067noreply@blogger.comtag:blogger.com,1999:blog-4801956593085384975.post-74132887182622102332013-02-06T16:59:14.932+02:002013-02-06T16:59:14.932+02:00Won't you need a separate bitboard for the que...Won't you need a separate bitboard for the queen itself? I don't see how "wQ = w & B & R;" becomes the queen bitboard. Could you clarify?<br /><br />As for rotated bitboards. You could try using magics instead for all the sliding pieces (R,B,Q). This will require 64*4096*2*64 bit (4 MByte), which is a lot. Not sure if that's a good idea.<br /><br />See: http://chessprogramming.wikispaces.com/Magic+Bitboards<br /><br />Ps. Are you hosting the code somewhere public?Error323https://www.blogger.com/profile/07666134146175312082noreply@blogger.com