Hi all,
Are MS AVstream layer uses double buffering for Scatter gather DMA list when the RAM is more?
tia,
DV.
xxxxx@gmail.com wrote:
Are MS AVstream layer uses double buffering for Scatter gather DMA list when the RAM is more?
AVStream doesn’t have anything to do with DMA. That’s entirely a
function of your driver.
I have some problem with AV Stream driver in x64 bit OS with Quad core machine with 4GB RAM. We use Scatter gather list to DMA video data into system assgined addresses in Stream pointer provided by Microsoft AV stream layer.
After completing the DMA, when the buffers are accessed with virtual address to modify the received data, we were still seeing the old data ( we have also put known signature data, and we could only access known signature data) instead of DMA’ed data from our Device. We are 100% sure that our Device is DMAing into the location. In the post process, we could not access the right data, hence it creates problems to Mpeg decoders while rendering. The problem happens in only in 2K chunks and randomly.
Is this due to double buffering in DMA? Or Am I missing something here? Or Any caching involved here?
Does your device handle 64-bit physical addresses? Have you told the
system that in the DMA adapter setup? Are you using system’s DMA
abstraction routines, or are you rolling your own? If your device can
only handle 32-bit addresses, then the operating system has to allocate
bounce buffers (“map registers”) for you. Those registers are limited
in number.
When you say “2K chunks”, what do you mean? Do you mean part of a page
transfers OK, and part does not? Or do you mean a single partial-page
transfer gets missed? Pages are 4K, and DMA failures almost always
happen in units of 4K.
We don’t use calls like GetScatterGatherList / PutScatterGatherList.
Then how do you build the scatter/gather list to send to your hardware?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Perhaps I shouldn’t chime in here- but I know there is code in KS.Sys that computes scatter gather lists and handles double buffering for 64-bit OS when a 32-bit adapter is used. I wrote it [as a contract SDE] under direction of a senior engineer several years ago (for 2k3sp1). It’s still there.
But I don’t remember how you invoke or use it [and while I prefer to take ownership where I had some involvement I just don’t have the time to do so]. OP may want to try one of the microsoft groups or open a support incident. It is conceivable that there is a race between his completion handling and the double buffering code and I always believe in the possibility of bugs, no matter how low it may become over time.
xxxxx@microsoft.com wrote:
Perhaps I shouldn’t chime in here- but I know there is code in KS.Sys that computes scatter gather lists and handles double buffering for 64-bit OS when a 32-bit adapter is used. I wrote it [as a contract SDE] under direction of a senior engineer several years ago (for 2k3sp1). It’s still there.
Why? KS.sys doesn’t do any I/O. It doesn’t have any knowledge that the
device underneath it lives on a PCI bus. None of the AVStream
structures asks me about my DMA capabilities, and I don’t make any KS
callbacks when I’m about to do DMA. How would it get involved?
I’m in no position to cast doubt here, but I can’t help but wonder if
you’re remembering a different driver.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Tim-
Go to MSDN- take a look at the page for KsStreamPointerLock, and observe the comments regarding the pin flag KSPIN_FLAG_GENERATE_MAPPINGS. That’s the stuff I’m referring to and it definitely is in KS.
xxxxx@microsoft.com wrote:
Tim-
Go to MSDN- take a look at the page for KsStreamPointerLock, and observe the comments regarding the pin flag KSPIN_FLAG_GENERATE_MAPPINGS. That’s the stuff I’m referring to and it definitely is in KS.
You are correct, my mistake.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Hi Bob,
Thank you so much. We are also in the conclusion of double buffers for DMA in 64 bit OS. Right now, we don’t use any GetScatterGatherList and PutScatterGatherList calls. We just take mappings from stream OffsetOut pointer and build our own list before passing it to hardware for DMA.
Is there anyway to flush the data to properly so that we can do our post processing on the data received through DMA?
Tim,
Thanks for reply. Our device supports only 32 bit mode. We don’t use 64bit address mode. We build our own scatter gather list based on Stream OffsetOut pointer.
tia,
DV.
xxxxx@gmail.com wrote:
Thanks for reply. Our device supports only 32 bit mode. We don’t use 64bit address mode. We build our own scatter gather list based on Stream OffsetOut pointer.
And what do you do if all or part of that buffer lives in physical
memory beyond 4GB? No one is guaranteeing that the pages will live in
low 32-bit space.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
>>
And what do you do if all or part of that buffer lives in physical
memory beyond 4GB? No one is guaranteeing that the pages will live in
low 32-bit space.
<<
KS guarantees this- the KS_STREAMPOINTER’s OffsetOut parameter’s first member is a union- if they have used KSPIN_FLAG_GENERATE_MAPPINGS properly, then it is a pointer to an array of KSMAPPING structures, which are physical addresses and byte counts for scatter-gather entries representing the frame. The addresses will all be in memory accessible to the adapter they provided with KsDeviceRegisterAdapterObject, and KS handles the buffering.
>
Is there anyway to flush the data to properly so that we can do our post
processing on the data received through DMA?
<<
The bad news here is that as I remember it, the copy operation on a device read won’t occur until you advance to the next frame. It sounds like you want to operate on the buffer before that happens. I don’t know if there is an easy way around this, but I don’t know all that much about KS- I only worked on bits and pieces of it [the DMA code was probably the biggest single piece by far]and even that was on a part-time basis.