memory position of numpy arrays

David Cournapeau david at ar.media.kyoto-u.ac.jp
Thu Oct 26 06:08:05 EDT 2006


Lars Friedrich wrote:
> Hello,
>
> thanks for your comments.
>
> Am Mittwoch, den 25.10.2006, 11:28 +0900 schrieb David Cournapeau:
>   
>> Andrew Straw wrote:
>>     
>>> David Cournapeau wrote:
>>>   
>>>       
>>>> I don't know anything about your device, but a driver directly accessing 
>>>> a memory buffer from a userland program sounds like a bug to me. 
>>>>     
>>>>         
>>> David, DMA memory (yes, I know thats an example of RAS Syndrome,
>>> apologies) allows hardware to fill a chunk of RAM and then hand it over
>>> to a userspace program. In my experience, RAM used for this purpose must
>>> be pre-allocated, usually in a ring-buffer type arrangement. So this is
>>> normal operating procedure for something like a frame grabber and not a
>>> bug at all.
>>>   
>>>       
>> What I understood from former emails was that the user is allocating a 
>> memory buffer, and that it gives this memory buffer to the hardware. In 
>> this sense, I don't see how it is possible to avoid kernel panic or 
>> equivalents. If on the contrary, the driver gives you the memory buffer, 
>> then, ok, by eg a mmap-like call, you can access directly the device 
>> memory, but within a range fixed by the driver, which is valid if the 
>> driver is not buggy.
>>     
>
> The API of the camera provides a function
> pl_exp_start_cont(hCam, buffer, size)
>
> The usage is to pass a Camera-Identifier "hCam", a pointer "buffer" and
> a size "size" in bytes. The camera will then start to acquire frames and
> put them to the buffer, which has to be size-bytes long. When the
> function reaches the end of the buffer, it will start at the beginning
> again (circular buffer mode). There is also a function available to ask
> for the last buffer position that is written to. The buffer has to be
> allocated by the caller of this API-function, so I guess it will be in
> *userland*.
>   
In this case, I think the data are copied from the device to your buffer.
> To have enough time to read a frame, the buffer has to be sufficiently
> big. I don't know what is sufficient, but I made it 50 frames big. With
> an acquisition time of lets say 10ms I have about 0.5seconds to get a
> frame, that was recently written to the buffer.
>   
You have no way to check if the ringbuffer is full or not ? In audio 
programming under linux, what happens normally is that you have a ring 
buffer locked in memory (that is cannot be paged out), and you need to 
check if your read/write pointers overlap to detect a buffer overrun.
> I know, these things are not numpy and even not Python-questions, but
> C-questions, and I think I should go and read something about it. Does
> anyone have a recommendation where to find information on this
> memory-locking things? How is this kind of programming called?
> Driver-Programming? Hardware-Programming? System-Programming?
>
>   
Real time programming, maybe ? Without a knowledge of the API of your 
device, it is hard to know what the problem is for me.

By the way, I found the information about locking pages into memory for 
windows:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/memory/base/virtuallock.asp

It may not work as expected, though, as it happens quite often with 
windows :)

David


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642




More information about the NumPy-Discussion mailing list