bttv driver questions
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 15 lines · Jean Delvare
Hi Mauro, hi Trent,
I'm back with more questions about the bttv driver:
* When is the bttv IRQ handler called? At the end of every frame? At the end of the VBI? Between the odd field and even field sequences for full resolution frames?
* Does the bttv driver have anything special to do for full resolution frames, that it doesn't have to do for half resolution ones? In particular, I wonder if the BT878 DMA engine knows how to interlace fields when writing to the memory, or if the bttv driver must take care of reordering the fields properly afterwards. I suspect the latter.
Quoted 6 lines
* How longs are the blocks written by the BT878 DMA engine to memory? Obviously it can't send more than the FIFO size (128 bytes) at once. With the default PCI latency value (32) it seems that a maximum of 96 bytes can actually be sent at once (8 cycles for setup and 24 cycles for data on a 32-bit PCI bus -> 96 bytes per transfer.)
IF I'm reading the PCI 2.2 spec correctly, targets are allowed an initial (start of burst) latency of up to 16 cycles before they must be ready for the first data transfer in a burst. Host bridges as targets are allowed an additional 16 cycles setup time (for a total of 32) if the transfer is to a modified cache line. For subsequent transfers in the burst, the target is only allowed 8 setup cycles max.
So with a BT878 latency timer of 32 cycles, a 128 byte burst could be sent as 2 transactions, assuming a maximum target setup time for the host bridge, with a transfer that doesn't hit a modified cache line, assuming transparent arbitration:
1 addr cycle + 16 setup cycles + 15 data cycles (60 bytes transferred) 1 turn around cycle (I think...)
1 addr cycle + 8 setup cycles + 17 data cycles (68 bytes transferred) 1 turn around cycle
....
Quoted 7 lines
I am curious if there is a minimum FIFO usage for the
BT878 to request the PCI bus. Couldn't find anything related to this in the datasheet.* In continuation of the above, am I correct assuming that setting the latency timer of the BT878 above 40 doesn't make sense? 40 PCI cycles is enough to empty the FIFO completely,
It can make sense, especially if it's the only high bandwidth card in the system. Set the timer too high for any one card though, and you will start to starve other devices off the bus when that one card is busy. The cards that are held off the bus too long, may have their FIFOs or buffers overrun....
Setting latency timers for a system is a balancing act between the needs of individual devices and the system's need for the shared PCI bus to support the maximum anticipated burst or sustained activity on the bus by all the devices that could be active at once.
Quoted 4 lines
and then there's no
data left to send. But I'm curious how the BT878 behaves if it is granted more time than it needs. Can it return the PCI bus control earlier?
A PCI latency timer is the maximum amount of cycles a master is allowed to have the bus before it must request another grant. It is not the amount of cycles the master must use the bus. So yes a bus master can, and often does, release the bus before it's latency timer expires: it's a normal circumstance. What an actual BT878 does, I'll leave to the experts, who may know about any potential quirks it may have.
Quoted 3 lines
Or is it keeping control of the bus and sending more data
as it becomes (slowly) available? The later would be bad for both latency and throughput.
During the time an initiator (a bus master like the BT878) has FRAME asserted, the initiator can deassert IRDY or the target can deassert TRDY to insert wait states according to the PCI spec. So theoretically a BT878 could do such a thing, but I'm unsure why a chip would do such a thing if it had little or nothing to send. Of course every wait cycle counts against the latency timer too. Again, that's what's possible, but I defer to BT878 experts on what the chip actually does.
Quoted 2 lines
If anyone can help me answer these questions, I would be grateful. Thanks!
PCI-X and PCIe are of course slightly different from PCI. I do not know how much of the above applies for those busses.
Regards,
Andy
--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list
Quoted 2 lines · Andy Walls
Quoted 1 line · Jean Delvare
* When is the bttv IRQ handler called? At the end of every frame?
yes
Quoted 1 line
Quoted 1 line
At the end of the VBI?
yes
Quoted 1 line
Quoted 1 line
Between the odd field and even field sequences for full resolution frames?
no, in-between only if fields are captured independently
Quoted 6 lines
Quoted 6 lines
* Does the bttv driver have anything special to do for full resolution frames, that it doesn't have to do for half resolution ones? In particular, I wonder if the BT878 DMA engine knows how to interlace fields when writing to the memory, or if the bttv driver must take care of reordering the fields properly afterwards. I suspect the latter.
The driver fills buffers with instructions for the DMA engine, one buffer for the top field and one for the bottom field. These instructions tell the engine where to write a specific pixel. For interlaced video the instructions for the top field write to line 0, 2, 4, ... in memory and for the bottom field to line 1, 3, 5, ... .
Quoted 3 lines
Quoted 3 lines
* How longs are the blocks written by the BT878 DMA engine to memory? Obviously it can't send more than the FIFO size (128 bytes) at once.
The FIFO is bigger. In packed modes it is 140x4 bytes. In planar modes it is 70x4 bytes for luma and 35x4 bytes for each chroma FIFO.
Quoted 12 lines
IF I'm reading the PCI 2.2 spec correctly, targets are allowed an initial (start of burst) latency of up to 16 cycles before they must be ready for the first data transfer in a burst. Host bridges as targets are allowed an additional 16 cycles setup time (for a total of 32) if the transfer is to a modified cache line. For subsequent transfers in the burst, the target is only allowed 8 setup cycles max.
So with a BT878 latency timer of 32 cycles, a 128 byte burst could be sent as 2 transactions, assuming a maximum target setup time for the host bridge, with a transfer that doesn't hit a modified cache line, assuming transparent arbitration:
Quoted 4 lines
1 addr cycle + 16 setup cycles + 15 data cycles (60 bytes transferred) 1 turn around cycle (I think...)
1 addr cycle + 8 setup cycles + 17 data cycles (68 bytes transferred) 1 turn around cycle
I think worst case for slow targets is more like
1 addr cycle
15 setup cycles (unsure if initial latency includes addr cycle...) 1 data cycle
7 setup cycles
1 data cycle
7 setup cycles <-- latency timer of 32 expires, assuming GNT# is deasserted 1 data cycle <-- can't deassert FRAME# yet
7 setup cycles <-- FRAME# deasserted
1 data cycle
1 turnaround cycle
--------------------
16 bytes in 42 cycles
With fast targets we have
1 addr cycle
31 data cycles
(more data cycles as long as GNT# is asserted)
1 data cycle with FRAME# deasserted
1 turnaround cycle
--------------------
128 bytes in 34 cycles
Quoted 3 lines
Quoted 3 lines
I am curious if there is a minimum FIFO usage for the
BT878 to request the PCI bus. Couldn't find anything related to this in the datasheet.
There are FIFO trigger points settable in the GPIO_DMA_CTL register. They can be set to 4, 8, 16, or 32 DWORDS.
Quoted 2 lines
A PCI latency timer is the maximum amount of cycles a master is allowed to have the bus before it must request another grant.
The master may request extended/another grant before its timer expires. Furthermore the arbiter may grant the bus without it being requested (bus parking).
Making use of both features can be turned off in the Bt878 by the EN_TBFX and EN_VSFX bits respectively to cope with bad chipsets.
Jean, is v4l-dvb-maintainer the right place to discuss these things?
Daniel
--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list
Quoted 9 lines · On Wed, 27 Aug 2008, Daniel [iso-8859-1] Gl�ckner wrote:
Quoted 7 lines · Andy Walls
Quoted 6 lines · Jean Delvare
* Does the bttv driver have anything special to do for full resolution frames, that it doesn't have to do for half resolution ones? In particular, I wonder if the BT878 DMA engine knows how to interlace fields when writing to the memory, or if the bttv driver must take care of reordering the fields properly afterwards. I suspect the latter.
Quoted 5 lines
The driver fills buffers with instructions for the DMA engine, one buffer for the top field and one for the bottom field. These instructions tell the engine where to write a specific pixel. For interlaced video the instructions for the top field write to line 0, 2, 4, ... in memory and for the bottom field to line 1, 3, 5, ... .
Keep in mind that _either_ field can be transmitted first. I.e., in some cases one first writes lines 1,3,5 then lines 0,2,4. I'm not sure if bttv supports both field dominances or not, but I think it does.
Quoted 5 lines
Quoted 5 lines
So with a BT878 latency timer of 32 cycles, a 128 byte burst could be sent as 2 transactions, assuming a maximum target setup time for the host bridge, with a transfer that doesn't hit a modified cache line, assuming transparent arbitration:
Quoted 8 lines
I think worst case for slow targets is more like
1 addr cycle
15 setup cycles (unsure if initial latency includes addr cycle...) 1 data cycle
7 setup cycles
1 data cycle
7 setup cycles <-- latency timer of 32 expires, assuming GNT# is deasserted
Isn't the latency timer in units of 250 ns, not PCI cycles?
--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list
Quoted 3 lines · Trent Piepho
Quoted 2 lines · On Wed, 27 Aug 2008, Daniel [iso-8859-1] Gl�ckner wrote:
Quoted 1 line · Andy Walls
On Mon, 2008-08-25 at 14:45 +0200, Jean Delvare wrote:
<snipped>
Quoted 9 lines
Quoted 5 lines
The driver fills buffers with instructions for the DMA engine, one buffer for the top field and one for the bottom field. These instructions tell the engine where to write a specific pixel. For interlaced video the instructions for the top field write to line 0, 2, 4, ... in memory and for the bottom field to line 1, 3, 5, ... .
Keep in mind that _either_ field can be transmitted first. I.e., in some cases one first writes lines 1,3,5 then lines 0,2,4. I'm not sure if bttv supports both field dominances or not, but I think it does.
My particular board always returns top field first on capture. I don't know if that helps.
--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list
Quoted 7 lines · Robert William Fuller
Quoted 6 lines · Trent Piepho
Quoted 5 lines
The driver fills buffers with instructions for the DMA engine, one buffer for the top field and one for the bottom field. These instructions tell the engine where to write a specific pixel. For interlaced video the instructions for the top field write to line 0, 2, 4, ... in memory and for the bottom field to line 1, 3, 5, ... .
Quoted 6 lines
Quoted 3 lines
Keep in mind that _either_ field can be transmitted first. I.e., in some cases one first writes lines 1,3,5 then lines 0,2,4. I'm not sure if bttv supports both field dominances or not, but I think it does.
My particular board always returns top field first on capture. I don't know if that helps.
V4L2 allows the application to select the field dominance, V4L2_FIELD_INTERLACED_TB vs V4L2_FIELD_INTERLACED_BT. The bt878 chip can support both, but I don't know if the bttv driver has support for it.
--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list
Quoted 3 lines · Trent Piepho
On Wed, 27 Aug 2008, Daniel [iso-8859-1] Glckner wrote:
Isn't the latency timer in units of 250 ns, not PCI cycles?
Latency timer is in PCI clock cycles. Most devices ignore the 3 least significant bits of the setting (as allowed/suggested by the PCI spec), making most latency timers as multiple of 8 PCI clock cycles.
MIN_GNT and MAX_LAT are in units of 250 ns according to the PCI spec. I'm assuming it's no coincidence that 8 PCI clock cycles = 8/33 MHZ = 242.4 ns or approximately 250 ns.
-Andy
--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list
Quoted 8 lines · Andy Walls
Quoted 3 lines · Trent Piepho
On Wed, 27 Aug 2008, Daniel [iso-8859-1] Glckner wrote:
Isn't the latency timer in units of 250 ns, not PCI cycles?
Latency timer is in PCI clock cycles. Most devices ignore the 3 least significant bits of the setting (as allowed/suggested by the PCI spec), making most latency timers as multiple of 8 PCI clock cycles.
I bet I was reading a datasheet for a device that did this. They probably dropped three bits from the field width and said it was 250 ns units.
--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 1 line · Jean Delvare
What determines whether fields are captured independently?
Right now I can only think of V4L2_FIELD_ALTERNATE causing this.
Quoted 4 lines
My tests with a SECAM
source show a rate of 74-78 interrupts/second, which would be 3 interrupts per frame. So I guess I a missing a 3rd cause of interrupts. Any idea?
I checked the code. As soon as the device is opened, the VSYNC interrupt is unmasked to count the fields. These interrupts are in addition to the interrupts generated for queued buffers.
Quoted 3 lines
I thought that there was only one RISC program
loaded at any given time and that it had to be changed twice per frame, which would have taken one additional interrupt.
There is only one program with jumps that are patched at runtime to point to the program fragments for capture.
Quoted 2 lines
The BT878 has a hint which suggests that the fastest model described by Daniel is probably almost the right one.
The setup cycles mentioned by Andy and me depend on the target (the host bridge). The master must assert IRDY within 8 cycles in all data phases.
As a single Bt878 is able to capture PAL in BGR32 at 4*Fsc (70937900 byte/s peak), there must be less than one wait cycle per data phase on average.
Quoted 5 lines
Apparently the bttv driver sets them to relatively large values, instead of the small hardware default (4). This makes sense to me, 4 was very small and would cause the BT878 to request control of the PCI bus every now and then, significantly reducing the available PCI bus bandwidth.
I think for competing Bt878s the smallest trigger point in combination with a high latency counter should perform best.
Quoted 4 lines
Quoted 1 line
The master may request extended/another grant before its timer expires.
Do you happen to know if the BT878 does that? Couldn't find any mention in the datasheet.
Well, if they give us a bit to turn it off, I assume it is done. Read the section about the 430FX Compatibility Mode.
Quoted 7 lines
Quoted 1 line
Jean, is v4l-dvb-maintainer the right place to discuss these things?
I thought so. At least I received pertinent answers to my questions, so it seems that I have reached the right persons. But if you think I am abusing this list, I don't want to make anyone angry, so we can either continue this discussion in private, or on another list you think would be more appropriate.
Trent started CCing video4linux-list and from linux/MAINTAINERS I read that v4l-dvb-maintainer is mainly for patches..
I'm only subscribed to video4linux-list, so I don't know what is customary on the maintainer list.
Daniel
--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list
Hello,
Am Donnerstag, den 28.08.2008, 22:20 +0200 schrieb Daniel Glöckner:
Quoted 55 lines · Jean Delvare
Quoted 1 line
What determines whether fields are captured independently?
Right now I can only think of
V4L2_FIELD_ALTERNATEcausing this.Quoted 4 lines
My tests with a SECAM
source show a rate of 74-78 interrupts/second, which would be 3 interrupts per frame. So I guess I a missing a 3rd cause of interrupts. Any idea?I checked the code. As soon as the device is opened, the VSYNC interrupt is unmasked to count the fields. These interrupts are in addition to the interrupts generated for queued buffers.
Quoted 3 lines
I thought that there was only one RISC program
loaded at any given time and that it had to be changed twice per frame, which would have taken one additional interrupt.There is only one program with jumps that are patched at runtime to point to the program fragments for capture.
Quoted 2 lines
The BT878 has a hint which suggests that the fastest model described by Daniel is probably almost the right one.
The setup cycles mentioned by Andy and me depend on the target (the host bridge). The master must assert IRDY within 8 cycles in all data phases.
As a single Bt878 is able to capture PAL in BGR32 at 4*Fsc (70937900 byte/s peak), there must be less than one wait cycle per data phase on average.
Quoted 5 lines
Apparently the bttv driver sets them to relatively large values, instead of the small hardware default (4). This makes sense to me, 4 was very small and would cause the BT878 to request control of the PCI bus every now and then, significantly reducing the available PCI bus bandwidth.
I think for competing Bt878s the smallest trigger point in combination with a high latency counter should perform best.
Quoted 4 lines
Quoted 1 line
The master may request extended/another grant before its timer expires.
Do you happen to know if the BT878 does that? Couldn't find any mention in the datasheet.
Well, if they give us a bit to turn it off, I assume it is done. Read the section about the 430FX Compatibility Mode.
Quoted 7 lines
Quoted 1 line
Jean, is v4l-dvb-maintainer the right place to discuss these things?
I thought so. At least I received pertinent answers to my questions, so it seems that I have reached the right persons. But if you think I am abusing this list, I don't want to make anyone angry, so we can either continue this discussion in private, or on another list you think would be more appropriate.
Quoted 7 lines
Trent started CCing video4linux-list and from linux/MAINTAINERS I read that v4l-dvb-maintainer is mainly for patches..
I'm only subscribed to video4linux-list, so I don't know what is customary on the maintainer list.Daniel
for me it seems all lists are right and even linux-dvb should be added.
We had quite a lot of reports during the last years concerning bttv throughput on certain hardware and often there was no quick solution.
It is nice to see how many are still aware of the driver's details.
Such a thing even caused the foundation of the v4l wiki, since David Liontooth was on some affected bttv hardware mix times back and had to dig into on which hardware best to start for his upcoming teaching.
Unrelated not yet working saa713x NTSC closed captions were fixed in following attempts too.
But it sheds also a light on the saa713x restrictions, when DVB-T and/or DVB-S on hybrid cards is in use already and why in such a case analog video can only use packed formats at once, but no planar.
A user friendly solution still needs to be found and this here seems to be a good point to start.
Cheers,
Hermann
--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 3 lines · Jean Delvare
My assumption that there was a
VBI interrupt was wrong, probably because my video source is a VCR and it doesn't send any information during VBI?
When there is an application requesting VBI capture, there will be a VBI interrupt, regardless of the content in those lines.
Quoted 5 lines
Quoted 2 lines
There is only one program with jumps that are patched at runtime to point to the program fragments for capture.
And this all happens magically inside the BT878 without the bttv driver having to care? Wow! Tricky.
No, this is how bttv does it.
Other implementations may use a single loop without jumps.
Quoted 7 lines
In my case there's a PCI Express-to-PCI bridge on the path, so I presume that this acts as the target. I suppose that the board was designed that way precisely to make sure that no extra latency would happen on the PCI bus due to the host being slow/busy. If the bridge has large enough buffers, it should be easy for it to send the data down to the host bridge, given that PCI Express x1 is much faster than PCI.
It's not that much faster. Of the 250MB/s a lot is lost to overhead, especially when there are mostly short packets. And there may be other bottlenecks before the data reaches the RAM.
Quoted 5 lines
Quoted 2 lines
I think for competing Bt878s the smallest trigger point in combination with a high latency counter should perform best.
I don't quite follow you here. Care to explain how you reached this conclusion?
A smaller trigger point will make the PCI bus less idle but the average FIFO fill will be lower.
Yesterday I wrote a small program that simulates a number of PCI masters with constant data rate filling their FIFOs. There is a simple round robin arbiter and neither the target nor the master needs wait cycles.
For 5 masters with 24.2MB/s each (peak data rate of YUY2 640x480 NTSC), a latency counter of 254, and a FIFO trigger of 4, the bus is never idle. The maximum FIFO fill is 16 DWords. With a latency counter below 20, the FIFO fill rises infinitely.
With a FIFO trigger of 32 and a latency counter of 254, the maximum fill is 33 DWords and the bus is 4.5% idle.
Those 17 less FIFO entries in the 4-entry-trigger case can buffer for 93 PCI cycles. The 4.5% idle cycles in the 32-entry-trigger case are wasted if there is no other master on the bus, as is the case when the Bt878s are behind a bridge.
In reality there are always idle phases during syncs and additional traffic will be generated to fetch RISC instructions and to access registers.
Daniel
--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list
Quoted 15 lines · Daniel Glöckner
A smaller trigger point will make the PCI bus less idle but the average FIFO fill will be lower.
Yesterday I wrote a small program that simulates a number of PCI masters with constant data rate filling their FIFOs. There is a simple round robin arbiter and neither the target nor the master needs wait cycles.
For 5 masters with 24.2MB/s each (peak data rate of YUY2 640x480 NTSC), a latency counter of 254, and a FIFO trigger of 4, the bus is never idle. The maximum FIFO fill is 16 DWords. With a latency counter below 20, the FIFO fill rises infinitely.
With a FIFO trigger of 32 and a latency counter of 254, the maximum fill is 33 DWords and the bus is 4.5% idle.
Quoted 8 lines
Those 17 less FIFO entries in the 4-entry-trigger case can buffer for 93 PCI cycles. The 4.5% idle cycles in the 32-entry-trigger case are wasted if there is no other master on the bus, as is the case when the Bt878s are behind a bridge.
In reality there are always idle phases during syncs and additional traffic will be generated to fetch RISC instructions and to access registers.
Modeling, simulation and analysis. Very cool. :)
Regards,
Andy
Quoted 2 lines
Daniel
--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 13 lines · Jean Delvare
Hi Andy,
In the specific case I am studying, there are 8 BT878 chips, so each one definitely can't be considered the only "high bandwith card in the system". And it seems to me that latency matters as much as bandwith here... A high latency timer on one card will hurt bus latency at least as much as bus banwidth as I understand it.
Quoted 4 lines
Setting latency timers for a system is a balancing act between the needs of individual devices and the system's need for the shared PCI bus to support the maximum anticipated burst or sustained activity on the bus by all the devices that could be active at once.
Quoted 4 lines
We agree on that. With 8 BT878 chips, the problem is that both bus latency and bus bandwidth are potentially problematic. So the balance isn't an easy one to find. Which is exactly why I am asking all these questions.
No it probably isn't easy. With a static analysis (spreadheet), assuming worst case conditions, you will likely end up with the conclusion that the PCI bus can't handle the worst case load, so you'll need to model with higher fidelity and different assumptions than worst case.
Consistently meeting the real-time communications needs of the 8 BT878's and the disks on the PCI bus could well be impossible with (the very common) round robin arbiters.
You may find this thesis paper interesting:
http://os.inf.tu-dresden.de/papers_ps/schoenberg-phd.pdf
Which addresses the problem by proposing a different arbiter.
This, much shorter paper:
http://www.irisa.fr/manifestations/2004/wcet2004/Papers/Stohr.pdf
proposes that the Master Enable bit of devices be switched on and off to ensure deterministic times across the bus. (I'm not sure if I'd want to do that though...)
Regards,
Andy
--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list
Quoted 4 lines · Andy Walls
On Thu, 2008-08-28 at 16:58 +0200, Jean Delvare wrote:
Consistently meeting the real-time communications needs of the 8 BT878's and the disks on the PCI bus could well be impossible with (the very common) round robin arbiters.
Trying to capture 8 full resolution streams on one PCI bus is probably impossible, but with a NIC or HD controller on the same bus, forget it.
You'd need to get a chipset with multiple busses and put the capture card on its own bus.
Or get something like viewcast's multi-bttv cards that use a PCI to PCI-E bridge.
--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list
Quoted 2 lines · Trent Piepho
Or get something like viewcast's multi-bttv cards that use a PCI to PCI-E bridge.
The DVC-5215 card Jean mentioned in his first post is a PCIe card. The bridge visible on the card must be a TI XIO2000A with external PCI arbiter. It allows to tweak some QoS parameters for PCIe traffic that might be helpful.
Btw., for cards with PCI-PCI bridge the latency counter of the bridge on the main bus should be set to a high value to give it an advantage to flush its buffers.
Daniel
--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 4 lines · Jean Delvare
But I have to admit that I'm not really sure how the different PCI Express slots relate to each other. Does each slot have its own bus and thus bandwidth? Or is the same PCI Express bus shared by all slots as is usually the case for PCI?
Each slot has the full bandwidth, but the receiving end can stop the transmitter if it has no space left in its buffer.
Quoted 2 lines
And what about the motherboards
which have both PCI and PCI Express slots/on-board devices?
There will be a PCI-PCIe bridge. Both busses will be independent as long as they don't exchange data.
Quoted 2 lines
I see no reference to the XIO2000 in the kernel source tree. If I am supposed to tweak QoS parameters, how would I do that?
Having read the XIO2000 datasheet I would try to use the second VC with a higher traffic class for access from the PCI bus to memory. The configuration of the bridge should be modifiable with setpci. Other chips might need tweaking too for this to have effect.
Quoted 1 line
According to "lspci -vv" the latency timer of the bridge is set to 0.
The latency timer is meaningless for PCIe.
The secondary, PCI bus has a separate latency timer, but I wouldn't set that one to a high value.
Quoted 2 lines
As far as I remember, all PCI-PCI bridges I've ever seen always had their latency timer set to 0.
0 is the default for a bridge after reset.
Daniel
--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 5 lines · Jean Delvare
Quoted 2 lines
It's not that much faster. Of the 250MB/s a lot is lost to overhead, especially when there are mostly short packets.
The very same is true of the PCI side, isn't it? Out of the 133 MB/s of PCI bandwith I don't expect to get more than 100 MB/s effective.
You are right. PCI is only faster for transfers of 4 bytes or less. The throughput formula for memory writes without waitstates on PCI is
400/3*x/(x+8) MB
and for memory writes with infinite credit without ECRC on PCIe
250*x/(x+20) MB,
where x is the burst size and must be a multiple of four in both protocols.
Quoted 2 lines
Actually there may be up to 8 masters. Latency counter values of 254 and 20 are rather extreme values.
The equilibrium pattern for latency values between 20 and 254 at a trigger of 4 in my simulation is the same.
Quoted 2 lines
I guess that your computations assume that the BT878 returns the bus control as soon as its FIFO is empty?
Yes
Quoted 3 lines
Not sure what you call "maximum fill"? If the FIFO triggers at 32, I have a hard time believing that it always gets the control within the next 0.17 µs (2 pixels).
There is an initial phase of about 2000 PCI cycles where the FIFO fill may be higher (this is not the case for a trigger of 4). Afterwards they acquire the bus in a uniform pattern and stay below the quoted values. At a trigger of 32 the bus is idle between requests, so access is granted immediately.
Quoted 5 lines
Again, I fail to see how we care about the idle cycles. I agree that we don't have to pay attention to having a lot of them, because the BT878s are alone on that side of the bridge, but we also don't need to maximize the "raw" bus usage. What matters is that the bus can take the bandwidth peaks and that the FIFOs do never overflow.
It's not about maximizing the bus usage. I suggest to use a low trigger to keep the FIFO usage low. The high bus usage is just a side effect, which can be neglected if the Bt878s are on a secondary bus (and either the primary bus is faster or the bridge can merge writes).
Quoted 2 lines
Care to share your simulation tool with me? This seems to be a very valuable tool for the problem I am trying to solve.
Attached.
Cycle description, FIFO overflows and periodic bus idleness estimations on stderr. FIFO fill for all masters in every cycle on stdout.
Daniel
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
static int busstate;
static int nextbusstate;
static int gnt;
static unsigned long long clk;
#define N 5
static struct master {
int req;
int fifofill;
int trigger;
int latval;
int latcnt;
int phase;
unsigned long long step; /* fixed point 32 bit mantissa */ unsigned long long accu;
} masters[N];
static void simulate(int i)
{
masters[i].fifofill+=masters[i].accu>>32;
masters[i].accu&=0xffffffff;
if(masters[i].fifofill>140) {
fprintf(stderr,"%llu [%i dropped %i]\n",clk,i,masters[i].fifofill-140);
masters[i].fifofill=140;
}
if(busstate==0 && gnt==i && masters[i].fifofill>=masters[i].trigger) {
nextbusstate=1;
masters[i].phase=1;
}
if(busstate==1) {
switch(masters[i].phase) {
case 1:
masters[i].phase=2;
masters[i].latval=masters[i].latcnt;
fprintf(stderr,"%llu %i addr\n",clk,i);
break;
case 2:
masters[i].fifofill--;
fprintf(stderr,"%llu %i data, %i remaining\n",clk,i,masters[i].fifofill);
}
if(masters[i].latval>0)
masters[i].latval--;
if(masters[i].phase && (masters[i].fifofill==1 || (!masters[i].latval && gnt!=i)))
nextbusstate=2;
}
if(busstate==2 && masters[i].phase) {
masters[i].fifofill--;
fprintf(stderr,"%llu %i final data, %i remaining\n",clk,i,masters[i].fifofill);
if(gnt==i && masters[i].fifofill>=masters[i].trigger) {
nextbusstate=1;
masters[i].phase=1;
} else {
nextbusstate=0;
masters[i].phase=0;
} }
masters[i].req=(masters[i].fifofill>=masters[i].trigger || (masters[i].phase && nextbusstate==1 && masters[i].fifofill>1)); masters[i].accu+=masters[i].step;
}
int main()
{
int i;
unsigned long long idle;
int wasactive;
clk=idle=0;
busstate=0;
gnt=0;
wasactive=0;
srandom(time(0));
for(i=0;i<N;i++) {
masters[i].req=0;
masters[i].trigger=4;
masters[i].fifofill=random()%masters[i].trigger;
masters[i].latcnt=64;
masters[i].phase=0;
#define PAL(w) (((unsigned long long)(w)<<31)*3/5200)
#define NTSC(w) (((unsigned long long)(w)<<31)*30/52856)
masters[i].step=NTSC(640);
masters[i].accu=random()%masters[i].step;
}
while(1) {
int nextgnt=gnt;
if(wasactive) {
for(nextgnt=(gnt+1)%N;nextgnt!=gnt;nextgnt=(nextgnt+1)%N)
if(masters[nextgnt].req)
break;
if(nextgnt!=gnt)
wasactive=0;
}
for(i=0;i<N;i++) {
printf("%i%c",masters[i].fifofill,i+1==N?'\n':'\t');
simulate(i);
}
gnt=nextgnt;
if(!busstate && nextbusstate)
wasactive=1;
clk++;
if(!nextbusstate) {
if(busstate)
fprintf(stderr,"%llu turnaround\n",clk);
else {
fprintf(stderr,"%llu idle\n",clk);
idle++;
}
}
if(!(clk&511))
fprintf(stderr,"[%llu bus idle %f%%]\n",clk,100.0*idle/clk);
busstate=nextbusstate; }
return 0;
}
--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 5 lines · Jean Delvare
This is because each master never needs its full grant, the FIFO is empty before and they return the bus control early. If each master was to keep control of the bus for as long as control was originally granted, things would be much different. Would it be difficult to modify your simulation tool to allow this case?
It is impossible to extend a transaction by an arbitrary number of cycles without violating the spec. Every DWord must be ready in 8 cycles. When the data rate is below 16.7 MB/s, the next DWord will not be ready in time.
Quoted 4 lines
I would also like to be able to add an arbitrary number of setup cycles at the beginning of every transaction. Your assumption that there are no such cycles wasted is a bit optimistic, and I'd like to get more realistic figures.
It's not like the bridge has to fetch a cachline from memory. It just needs to decode the address. Either there are buffers waiting or it can't accept data (in which case it will probably signal RETRY). Address decoding is specified as medium DEVSEL timing, which equals 1 wait cycle worst case.
Quoted 2 lines
Which raises a question... do you know if the XIO2000 can merge writes?
I don't know. TI support might be able to answer this.
Quoted 1 line
And do you know how much of a buffer it has?
The XIO2000A FAQ says a PCIe transaction payload can be 512 bytes maximum. It furthermore says that Intel chipsets accept only transactions up to 128 bytes. The number of buffers would be interesting, too. And if the second VC has the same number of buffers...
Quoted 3 lines
The problem I have with low trigger is that it means many short transactions, which in turn means small effective bandwidth, and I know that in my case we can't have too much bandwidth.
When the bus is loaded, transaction lengths will grow automatically above the trigger point up to the latency counter value. The simulation for 5 masters required a minimum latency of 20 even though the trigger was 4.
Quoted 4 lines
I think your code assumes YUY2 as a capture format, i.e. 2 bytes per pixel? I already know that 8 masters can't do that concurrently over the same PCI bus, no matter how we tweak the PCI settings. I'll have to change the code to assume Y8 as a capture format.
8 masters doing Y8 is less traffic with more FIFOs than 5 masters doing YUY2. It probably works out of the box.
If grayscale is not what your customer wants, there is a 8 bit color mode V4L2_PIX_FMT_HI240.
Daniel
--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 6 lines · Jean Delvare
Le mardi 02 septembre 2008, Daniel Gl�ckner a �crit�:
Quoted 2 lines
If grayscale is not what your customer wants, there is a 8 bit color mode
V4L2_PIX_FMT_HI240.I've seen this, and BT878 supports that format. But I don't know how to check how it looks like visually... mplayer doesn't seem to
It looks "ok". I used to use it when I watched tv with overlay and a video card in 8-bit pseudocolor. It will probably compress very poorly. You can turn dithering on and off, on looks better, but jpeg compress will probably be much worse with dithering.
Quoted 2 lines
support that pixel format. Apparently ffmpeg forces the format to YUV 4:2:0 planar (a pretty bad choice if you ask me), so I can't use
Most codecs operate on planar 4:2:0, so it makes the most sense to request the right format from the hardware, instead of converting from packed to planar in software. ffmpeg doesn't know that DMA of planar formats is harder for the bt8x8 and that you are running out of PCI bandwidth but might have lots of memory bandwidth and CPU cycles to use.
--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 2 lines · Jean Delvare
I couldn't find a format for HI24 though, maybe it's not standard enough and ffmpeg doesn't support it.
I've written a small program that captures in HI240 and converts to YCbCr 4:2:0. The output is either PGM as generated by mpeg2dec or Y4M as expected by the mjpegtools. The HI240 to RGB formula is from xawdecode.
You can find it at
http://www.stud.uni-hannover.de/~daniel/hi240.c
While skipping through the Fusion 878A datasheet, I found a sentence which made me realize that the problems associated with switching from one GNT to another in idle state are not limited to IDSEL stepping. Inserting a cycle with all GNTs deasserted is required because a device parked on an idle bus must drive the AD and C/BE# lines. This is not correctly modeled in the simulation.
Daniel
--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 7 lines · Jean Delvare
Quoted 4 lines
I've written a small program that captures in HI240 and converts to YCbCr 4:2:0. The output is either PGM as generated by mpeg2dec or Y4M as expected by the mjpegtools. The HI240 to RGB formula is from xawdecode.
I've never heard of PGM nor Y4M. Can either mplayer or ffmpeg decode either format?
FFmpeg knows how to deal with both formats.
For Y4M:
ffmpeg -f yuv4mpegpipe -i -
For PGM:
ffmpeg -f image2pipe -vcodec pgmyuv -i -
Quoted 3 lines
This doesn't build for me. Your code makes use of keyword "restricted" which I've never seen before and my version of gcc (4.1.2) doesn't know about.
"restrict" is C99. Either compile with -std=c99, replace "restrict" with "__restrict", or delete it completely.
Daniel
--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list