I was going to paste some code here, but I dont think the mailing list will compose it properly so I wont bother. On a gpu implementation of this AI idea.... Its square powers of 2 for synapses and cells, that just simplified the system, which actually got a little complicated on the way. As I see it, you have to reduce it to a series of texture draws, I did it in about 20, so far in the system, its actually about 700 lines long, so its pretty big, but it runs real quick. Your not allowed to use steamout, because its not sli compatable, but you are allowed to use geometry shaders, and these help you if you need to do a scatter draw on a texture, you opt for the geometry shader which says the exact locations of the pixels you need.One other tip, if you can develop lod's of any texture (keeping them square powers of 2) and this can help you disregard cells if you need to, depending on how you built the mips, then you can traverse the hierarchy, and disregard any useless information. When you want a sensory reconstruction - you flat write in, and scatter write back out. Another tip to get you going quicker->Gradually collecting the data, over collecting it straight away, is optimized in the fact now you can do it with less synapses, if you do that, your using your "deepness" to your advantage, you have to count error for every cell on the way in, and then you can get to a more refined error by using all the little groups together. Ive just done a tonne more theory, and I'm still not sure how im going to do temporal (which is essentially just reconstructing redundant future states) and then your getting somewhere.
> From: [email protected] > Subject: nupic Digest, Vol 13, Issue 12 > To: [email protected] > Date: Fri, 9 May 2014 12:00:06 -0400 > > Send nupic mailing list submissions to > [email protected] > > To subscribe or unsubscribe, visit > http://lists.numenta.org/mailman/listinfo/nupic_lists.numenta.org > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of nupic digest..." > > > Today's Topics: > > 1. Re: GPU data base (Doug King) > 2. 2014 Spring Hackathon demos online (Matthew Taylor) > 3. Re: GPU data base (Joonas Haapala) > 4. Re: GPU data base (Ian Danforth) > 5. Re: GPU data base (Ian Danforth) > 6. Re: nupic Digest, Vol 13, Issue 6 (Irwan Ramli) > 7. list of HTM successful application in commercial projects > (Sergey Bryukov) > 8. Re: quick post-hackathon report (Matthew Taylor) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 8 May 2014 11:14:11 -0700 > From: Doug King <[email protected]> > To: "NuPIC general mailing list." <[email protected]> > Subject: Re: [nupic-discuss] GPU data base > Message-ID: > <caldcxdb+a_a-jvov8uwyxdpeo3+1qsfagwwv7bhaqyrbd0+...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Magnus, that is very interesting. Am I getting this right - you are doing > your own version of CLA. Parts of it are GPU accelerated using bitmap > processing with shaders/textures? Can you tell us which parts are on the > GPU and how the data is structured? Any metrics on how much speedup you are > getting? Is latency from CPU to GPU a problem? It sounds like you allocate > all the memory for data structures regardless of whether they are used > (connected synapses) or not. This sounds like it might be a good tradeoff > and makes the data more GPU friendly. It also sounds like this approach of > using texture/shaders makes it scalable via SLI to add more GPU power by > installing more GPU cards - no code changes necessary. > > We would all be very interested in seeing a sketch / outline of how you are > doing this. It sounds like the convolution approach that Greg is speaking > of that is used for deep nets. I was under the impression that the CLA does > not map well to convolution. I hope I am wrong and we can find a way > restructure our data and algorithm to do convolution / shader operations. > Perhaps allocating temporal pooler memory for all potential weights instead > of growing memory over time like Ian suggests. > > Please share further details. > > > On Wed, May 7, 2014 at 11:04 PM, Magnus McWootton > <[email protected]>wrote: > > > Ive done something crazy, because I make video games. > > ive written a spacial system in direct x 11... i do with 16 synapses per > > cell, and i can go up to about an 8192x8192 texture, 16 synapses per cell, > > means its 2048x2048 cells. > > If you do it purely on textures only, then itll work with SLI. which is > > pretty important. > > Ive got a hierarchy, its not totally working yet, but I cycle pretty > > quick... I dont think a cuda one would beat it, writing it in shaders is > > even more restrictive. > > The synapses all have an address, and a weight, when scoring your cells, > > you literally brute force every synapse. the gpu does a good job at it. > > > > > > _______________________________________________ > > nupic mailing list > > [email protected] > > http://lists.numenta.org/mailman/listinfo/nupic_lists.numenta.org > > > > > -------------- next part --------------
_______________________________________________ nupic mailing list [email protected] http://lists.numenta.org/mailman/listinfo/nupic_lists.numenta.org
