On Fri, 2012-10-26 at 11:36 -0400, Kent A. Reed wrote:
> On 10/26/2012 2:10 AM, Sven Wesley wrote:
> > I did some testing yesterday. I upgraded the graphics driver (Nvidia) and
> > the latency test went from 18 000 to 150 000... I removed the driver and
> > reconfigured X and came down to a sweet 7 000, but there's something
> > messing things up as the latency all of a sudden popped up to 15 800.
> > Running the machine headless is on my top prio to see what happens. Mesa
> > card is high on the wish list too. I have a new machine project and Mesa is
> > the way to go in that case (5 axis 3,3 m long).
> >
> > Andy, Gene and Pete, same guys replied to my questions ages ago. Good to
> > see you're still here. :-)
> >
> > /S
> >
> 
> Glad to hear you are making progress, Sven.
> 
> I know it's wrong but the little boy in me wants to do a victory dance. 
> People keep downplaying the impact of the graphics subsystem but in my 
> experience it still ranks ahead of other problems when latency kicks up. 
> We remain blissfully ignorant of the interplay between the graphics 
> hardware, its drivers, and the BIOS, in which direct-memory-access 
> figure prominently. For a while I was hoping the open-source BIOS 
> initiative would prevail but it remains irrelevant in the face of rapid 
> advances in Intel x86 and ARM technology. I don't see any hope we'll 
> ever have BIOSes we can not only examine but also fix (like when Intel 
> screwed up its EPP-setting scheme).
> 
> Running systems headless is one of the tests I routinely perform before 
> posting latency-test results to the Wiki.
> 
> On the plus side, I expect someday to see someone successfully exploit 
> the GPU to offload some of our CNC calculations from the CPU. The 
> horsepower is there; it's a matter of timing.
> 
> Regards,
> Kent
> 
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. 

Along different lines I keep waiting for someone to write a driver
between linuxcnc and something like mesa's softdmc. 

Both of these rather break the original philosophy of emc/linuxcnc but
nothing in technology is really static.  

Nomex suit is donned. Have at it. 

Dave


> 
> ------------------------------------------------------------------------------
> 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



------------------------------------------------------------------------------
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

Reply via email to