> On 31 May 2016, at 13:11, Gian-Carlo Pascutto <g...@sjeng.org> wrote: > > On 31/05/2016 20:45, David Ongaro wrote: >> I suspect Aja is right and Remi should go the path of integrating the >> GPU even if it's just to get more "oomph" for CS. That he tried to >> learn GPU programming from scratch is a noble attempt but I guess >> it's just to ambitious to accomplish in a reasonable timeframe. Using >> one of the ready to use frameworks should make it feasible though. > > They're a pretty annoying burden if you want to make the engine > commercial. I'm not even sure CuDNN can be bundled with the engine?
Isn't e.g. TensorFlow Apache 2.0 license and would allow its inclusion in commercial products? > Additionally, not all customers might have a GPU that is enough faster > than the CPU (i.e. not the built-in one in modern CPUs, save maybe AMD's > APU units), so you need a good CPU fallback anyway. Oh, and if you use > CUDA, you lose about 1/3rd of your customers, again. Again, I think TensorFlow (but there might be others) is in big parts CPU/GPU agnostic, so one could make flexible choices here (even at runtime) without rewriting code. I'm aware that abstractions are leaking and not always desirable (e.g. if you want to take explicit advantage of the actual differences), but it should make things much easier to start with. > You're overestimating the difficulty of programming a GPU though. Yes, > if you've never done it before the programming takes some adjustment, > but the SIMT model is very convenient to write code in, IMHO much easier > than trying to coerce things to SIMD layouts. I might overestimating it, but on the other hand I guess a Professor like Rémi has much more obligations other then writing Go Software. So anything which could save time helps. David O. _______________________________________________ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
