Thanks a lot for everyone's input! It seems like for our application, GPU off-loading is not the way to go. We have redesigned our system for all processing to take place on the Intel i7. Total maximum processing latency stays 100ms, and interrupt frequency goes up to 1.5 KHz.
I have done some research on the pro's and con's of PREEMPT_RT vs Xenomai. As far as I can determine some of the benefits include: 1. Programming with Xenomai native API's are more elegant than POSIX real-time API’s. 2. Xenomai has possibly less overhead than a full preemptive kernel. The user interface does not require RT capabilities. Are there any other substantial benefits worth considering? Which would you use? Regards, On Thu, Feb 3, 2011 at 3:21 PM, Gilles Chanteperdrix < [email protected]> wrote: > Jan Kiszka wrote: > > On 2011-02-03 12:49, Gilles Chanteperdrix wrote: > >> Jan Kiszka wrote: > >>> On 2011-02-03 12:27, Gilles Chanteperdrix wrote: > >>>> Jan Kiszka wrote: > >>>>> On 2011-02-03 12:04, Gilles Chanteperdrix wrote: > >>>>>> Jan Kiszka wrote: > >>>>>>> [ And, personally, I don't trust the NVIDIA driver a lot. But that > might > >>>>>>> be influenced by the fact that latest versions lock up my notebook > >>>>>>> regularly after resume and that I filed another obvious locking > issue of > >>>>>>> the compilable driver stub around mmap_sem without any response > from the > >>>>>>> vendor. ] > >>>>>> Some colleague of mine is using the NVIDIA driver (through the > opengl > >>>>>> mapping, not CUDA/VDPAU, whatever) on high-end NVIDIA boards in a > non RT > >>>>>> situation. he definitely observed some huge latencies not due to > >>>>>> scheduling issues, when uploading textures to the GPU. We are > talking > >>>>>> tens of milliseconds here. > >>>>> Ugh, tens of milliseconds is heavy, more than I would expect from > >>>>> wbinvd. OTOH, uploading textures may involve mapping the RAM that > >>>>> contains them for the GPU. To exclude that as source, he could try > >>>>> instrumenting CACHE_FLUSH() (in nv-linux.h). > >>>> No, it really looks like a bug in the blob. Of course the 40ms is a > spot > >>>> from time to time, usually, the upload is really fast. > >>> Unless it's a stall on the PCI bus, the blob should leaves some traces > >>> in ftrace. > >> I am talking about the kernel-space blob. ftrance does just show that > >> the ioctl has been submitted. > > > > Function tracing takes you at least into the blob wrapper, both for > > requests issued to the blob and for its callbacks to access Linux > > services. It looks like NVIDIA as concentrating both arch and kernel > > specific abstractions there, not in the blob (but that's just an > > impression). > > Sorry, I misunderstood ftrace, I thought strace. No, we did not try ftrace. > > -- > Gilles. >
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
