View Single Post
Old 06-17-07, 01:55 PM   #1
loopi
Registered User
 
Join Date: Feb 2005
Posts: 14
Default Advice to driver programming 100.14.09

Hi there,

I am using following:
2.6.21.3
Gigabyte 8600 GT / dual DVI but run on CRT-0 and CRT-1
Driver 100.14.09

I have problem with XVideo tearing, but only for second output. I have following theory because I could not get the chance to read the source code of NVIDIA driver and help you to fix it:

----------------
- 2nd output waits for its vertical retrace to end
- 2nd output got to know its vertical retrace is ended, but...

- 1st output also want to output one video frame, so it lock the same card for exclusive operation, waits for its vertical retrace to end, so it ended, so one frame of 1920x1080 4:2:0 YUV get delivered and get displayed, and unlock the card

- 2nd output get to access the card, so it also get to deliver one frame of 1920x1080 4:2:0 YUV, but unfortunely the vertical retrace already started, so tearing happen as part of old frame and part of new frame get displayed out from RAMDAC
-----------------

Each frame takes 3.2 MB , for 25 fps it would take atleast 100MB per output, so there will be a total 200MB/sec flooding over PCI-Express signal path, and it has to be realtime, eg. 50fps, but it can't be done perfectly atleast for 2nd output.

It seems like 1st output has higher priority than 2nd output, so 1st output always blocked 2nd output for any operations, sadly, this means 2nd output always has tearing video under the pleasure of 1st output.

To be exact, in my theory, one cycle of XvShmPutImage + CompletionEvent doesn't guaranteed a frame to get output to monitor. That frame is queued in the buffer of the driver and it just find some opportunity to get it over PCI Express bus, get it over to the card memory buffer, and get it over to the GPU, get it over YUV->RGB texture conversion, get it over to RAMDAC, and get it over during vertical blanking period, .......

To be exact, in my theory, even glSwapBuffer can't guaranteed you that it will swap the buffer exactly during vertical blank.

I have walk through the list of graphics card that you have to support and I understand it is a hard job to do driver programming. You might break certain features at some time, or it is just the fact that, every new hardware has its own demand for doing the same thing, even to output the YUV video, and you guys just could not have enough hands to fulfill each single demands done by those hardware engineers.

This is OK, I understand what's going on, as I am a software engineer myself, I have to fights with weird SATA chip, weird audio chip, and even weird Intel chipset that only support 1x on a 16x PCI-E lane, that Multi**eo.

Things just happen, but I can help you to fix them. But on a second thought, if you open the driver souce code itself, you might as well have to open the spec for NVIDIA graphics chip, which is certainly no good for your company.

Can we get some NDA done ? I help you , you help me.

Best Regards.
loopi is offline   Reply With Quote