Hallo
I start developing wdm drivers for windows a few month ago.
I’d like to allocate up to 1GB DMA memory from the non-paged-pool and map it into user space.
And here is my problem. If I call the function
AllocateCommonBuffer with a buffer size of 256 MB,
the function returns successful. After this I call the function
IoAllocateMdl for the mapping. The function failed, if the buffer size is
larger than 64MB because of the constraint PAGE_SIZE * (65535 - sizeof(MDL)) / sizeof(ULONG_PTR).
I’d like to map the whole buffer linear into the user-space.
Is there any chance to solve this problem?
Thanks
> I’d like to allocate up to 1GB DMA memory from the non-paged-pool and map it into user space.
it’s crazy.
Just to highlight a point here…All windows based x86 system upto Windows
2003 SP2 have a max limit of 256 MB of Non Paged Pool virtual memory and
that puts a restriction that upto only 256 MB of Physical memory can be used
as Non Paged limit, which you can’t possibly use because there would be
other device drivers which will be loading in the same address space and if
you use that complete range, your machine is either going to bugcheck or
will hang. I suggest you revisit your design and identify a feasible design
goal.
On Wed, Jul 30, 2008 at 1:22 PM, wrote:
> Hallo
>
> I start developing wdm drivers for windows a few month ago.
> I’d like to allocate up to 1GB DMA memory from the non-paged-pool and map
> it into user space.
> And here is my problem. If I call the function
> AllocateCommonBuffer with a buffer size of 256 MB,
> the function returns successful. After this I call the function
> IoAllocateMdl for the mapping. The function failed, if the buffer size is
> larger than 64MB because of the constraint PAGE_SIZE * (65535 -
> sizeof(MDL)) / sizeof(ULONG_PTR).
> I’d like to map the whole buffer linear into the user-space.
> Is there any chance to solve this problem?
>
> Thanks
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
–
Thanks & Regards
Pushkar Prasad | Email: xxxxx@eccellente-it.com | URL:
http://www.eccellente-it.com |
“A positive attitude may not solve all your problems, but it will annoy
enough people to make it worth the effort.” -Herm Albright
I’m on a project for developing a
driver and library for a frame grabber.
I need this memory to store the acquired images
so that a user have direct access to this data.
I guess at this point, we need to wait for *Daniel, Anton, Mark and Tim*.
They will be getting up shortly. They are the experts who could guide you in
proper way. In my opinion what you are attempting is infeasible on x86 and
you need to consider a approach of moving the image data to some user buffer
rather than storing it all in Non Paged Pool if your app is supposed to run
on x86, otherwise if you wanna stick to this approach then you need to move
to x64 platform and for your customer you will have to come up with a
specific set of Hardware requirements for x64 (viz. RAM) to be able to run
that application without running into issues.
Thanks & Regards
Pushkar Prasad | Email: xxxxx@eccellente-it.com | URL:
http://www.eccellente-it.com |
“A positive attitude may not solve all your problems, but it will annoy
enough people to make it worth the effort.” -Herm Albright
On Wed, Jul 30, 2008 at 2:48 PM, wrote:
> I’m on a project for developing a
> driver and library for a frame grabber.
> I need this memory to store the acquired images
> so that a user have direct access to this data.
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
–
> I’d like to allocate up to 1GB DMA memory from the non-paged-pool and map it
into user space.
MmAllocatePagesForMdl is the proper function, a single MDL cannot describe more
then 32MB, so, you will need lots of MDLs and discontiguous mapping to user
mode.
Also - why do you need this? maybe there are other ways of solving your task?
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
> I’m on a project for developing a
driver and library for a frame grabber.
1GB nonpaged kernel-mode allocation is not necessary for a frame grabber.
USB Video devices are exactly the frame grabbers, and they do not require this
allocation.
The correct way is to allocate in user mode, then pass the buffer to the driver
in DeviceIoControl, then, in the driver, run the device’s DMA over this buffer
or submit the pipe read request to USB stack with this buffer.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
For example:
I’d like to call a function to a acquire n images continuously into this buffer. And than
I’d like to have direct access to all this image data.
In the past we realised this by editing the boot.ini, but we don’t want to do this with the next driver.
How does a graphics board with shred memory (f.e. 256MB) work? TUnless I’m mistaken this board also need a lot of memory out of the non-paged-pool?
Is there an other chance to aquire images continuously into an buffer by using dma?
> I’d like to call a function to a acquire n images continuously into this
buffer. And
than
I’d like to have direct access to all this image data.
Allocate the usual memory in user app code, then consume the incoming stream to
it.
In the past we realised this by editing the boot.ini
This is inacceptable.
Is there an other chance to aquire images continuously into an buffer by
using
dma?
Surely. Do like DirectShow does, or just write a DirectShow/AVStream driver and
use DirectShow.
The hardware just consumes some AVI-like data from some source and then DMAs it
to the main RAM. The DMA transfer size can be by far smaller then the video
frame.
And, for simplicity, DMA should run over the buffer the app will provide to
ReadFile.
So, if the app wants to have “virtual screen”, it should allocate this memory
and call several ReadFile calls to the driver to consume the stream. No need in
huge nonpaged buffer.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
> Is there any chance to solve this problem?
Sure - just redesign it…
As other posters told you already, the way you have presented it is just insane, at least on 32-bit system - 32-bit virtual address space is is just not sufficient for contigious mappings that large, even if the amount of physical RAM on your machine allows this . In any case, it has nothing to do with non-paged pool - in order to map one G, you have to allocate physical pages with MmAllocatePagesForMdl() at least 32 times, and map these MDLs into the user address space independently from one another…
Anton Bassov
xxxxx@gmx.de wrote:
I’d like to call a function to a acquire n images continuously into this buffer. And than
I’d like to have direct access to all this image data.
This is not going to work.
How does a graphics board with shred memory (f.e. 256MB) work? TUnless I’m mistaken this board also need a lot of memory out of the non-paged-pool?
No. For a shared memory graphics card, the memory is carved out at boot
time by the BIOS, long before any software is loaded. When the system
finally comes up, that chunk of main memory is seen as device memory,
and the physical RAM amount is reduced by that amount. It’s not pool
memory at all.
Is there an other chance to aquire images continuously into an buffer by using dma?
Absolutely. There are several ways to do this. If your device supports
scatter/gather, as all proper devices do ;), you can have the
application submit a bunch of read requests, lock the buffers down, and
have the frame grabber DMA directly into them.
If not, then you need a common buffer, and you’ll have to copy from
there into the user buffer. Hey, don’t think I didn’t just hear you
scoff, but you haven’t done the math. Today’s processors do copies
ridiculously fast. Your PCI device is going blast about 50 MB/s;
copying that continuously is less than 2% CPU load.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Thank’s for all your requests. The design was not my idea. It has a historicly background.
I started driver development a few mouth ago and I have to solve this problem. And at this time I have not enough
know-how. Therefore I looked what my antecessor has done.
Finaly I have to thing about an other solution for this problem.