-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/26/2012 11:19 AM, dave wrote: > Hi Kent, > > Offloading to the GPU is a most obvious approach ....in the manner > of math profs with chalk in the right hand and the eraser in the > left ..."it is obvious that". <grin> > > Most of the present day GPU's wouldn't even strain handling motion > the problem is simply that processors (GPU) are a moving target > and reinventing the wheel with each new generation of GPU would be > a pain to the most dedicated programmer. Now if one is bright > enough (don't look at me) to build an engine that does the > development the the strain gets lowered some. Sharing a video chip > between motion and display would certainly present some interesting > problems unless one has two boards and dedicates one to motion.
At my day job, we do a *LOT* of processing with the GPU, and it isn't really applicable to the LinuxCNC work-load. There aren't nearly enough parallel calculations required, and latency is a significant issue. The GPU excels when you need massively parallel calculations and can wait a bit for the results. Our use for the GPU is mixing and manipulating HD video images in real time, and we are operating on (very) large data sets in apx. 15 mS 'chunks', which would make for pretty lousy servo loop timing. > Along different lines I keep waiting for someone to write a driver > between linuxcnc and something like mesa's softdmc. I'm looking into the AM335x family of ARM chips from TI (ie: BeagleBone and friends). This part includes not only a 700+ MHz ARM core with 3D processor for running Linux, but two 32-bit microcontrollers that run at 1/2 the ARM clock frequency and have direct access to hardware I/O. I think this could make an excellent inexpensive LinuxCNC platform by crafting a software version of the normal Mesa/Pico hardware running hard real time on the embedded micro-controllers. Real hardware would still be faster and more capable, but the programmable micro-controllers would run rings around a normal x86 based parallel port software solution. There are also 3 high-performance PWM generators and hardware encoder inputs, so you could have 3 very high-performance channels and an arbitrary mix of slightly lower performance I/O implemented in software. ...oh, and there's a 12-bit A/D on board too. The catch will be to see what the latency numbers look like (I don't have hardware in-hand to play with yet, I'm waiting to see if my TI rep will get me one of these: http://www.ti.com/tool/tmdssk3358#3 or if I'll have to buy it myself). - -- Charles Steinkuehler char...@steinkuehler.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlCKu/UACgkQLywbqEHdNFxbAwCcDKQKYvtLEfUScHdVtDBdbhts zGMAniawz5Ob2F7vK/t+LXi6xAm38M8m =aho+ -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ The Windows 8 Center In partnership with Sourceforge Your idea - your app - 30 days. Get started! http://windows8center.sourceforge.net/ what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/ _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
