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
