>and use the following snippet of code.
HANDLE fileHandle = CreateFile(“test.yuv”,
GENERIC_READ,
0,NULL,
OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL,
NULL);
ULWord* frameBuffer;
GetBaseAddress(&frameBuffer);
ReadFile(fileHandle,
frameBuffer,
1920*2*1080,
&nBytesRead,
NULL) ;
So this directly reads from disk to our board.
If this is your exact code, your NOT doing DMA directly from the frame
buffer to the disk controller. You need to open the file in unbuffered mode
(I forget the flag). This code is doing a memory copy from your frame
buffer to some file system buffers, and then doing DMA from those buffers
to disk. The memory copy is probably not getting good PCI bursts, as it’s
really hard to get bursts for PCI target to memory copies. Disk transfer
are also probably not really large, as the lazy page writer is initiating
them. Note that an unbuffered transfer will have to be an integral number
of disk sectors, which 1920*2*1080 probably is. Also note the file offset
also needs to align on sectors.
Doing the performance analysis math: each frame is 4,147,200 bytes, which
at 30 fps is about 124 MBytes/sec or at 24 fps is about 100 MBytes/sec. If
your capturing HDTV video, your either already too slow (at 30 fps) or else
need to have almost 100% device utilization (at 24 fps). Per frame: the
frame buffer transfer takes about 40 milliseconds, and the disk transfer
takes about 28 milliseconds. If these two do not overlap, the total time
will be 68 milliseconds for 4.14 MBytes or about 15 fps, or about 62
MBytes/sec.
Another question is the architecture of the PCI bus to memory path. If the
32-bit bus ties up the 64-bit bus for the duration of a 32-bit PCI
transaction, your may have a problem. If the 32-bit bus is bridged from the
64-bit bus, this may be the case. I actually don’t know if a PCI bridge
tries to minimize latency, by initiating the destination side transfer in
parallel with the source side transfer. I think there is a high probability
it does, to tell the master that some target is accepting the transaction,
especially since in this case the master will be reading from the target.
Bridges can sometimes read ahead, although all the bridge programming magic
happens in the OS kernel (assuming W2K). You should be able to look at the
bridge parent bus registers and decide the hierarchical structure. What you
want is for both the 32-bit and 64-bit buses to be directly attached to the
memory controller. Perhaps if you told us the machine, somebody here knows
it’s PCI bus architecture. I’m not saying this IS a problem, just it MIGHT
be a problem. This problem also goes away if you actually get direct
transfers from the capture target memory to the disk controller.
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
