Driver bug

[casey]

It seems that all Nvidia drivers post 28.80 cause image tearing. Im looking for volunteers to verify this. I have included my sample code and config details in the zip file /*sorry about the file extension *.zip this is the format the server requires*/. My program draws a sweeping vertical line and the swapbuffers is told to execute on the vertical retrace so I should only see an image tear when the render time of the graphics card exceeds the 60hz refresh 16.6667msec. It is my belief that the drivers (post 28.80) are running some random code segment every so often which causes this render time to exceed 16.667msec (about 1 out of 20 frames or so). The result, my line tears on my program. More importantly this is universal and all images displayed on an NVidia graphics card will show this tearing as well(when running drivers post 28.80). Or so i think.....

you will probably have to get the glut-3.7 stuff from:
http://www.opengl.org/developers/documentation/glut/
I tried shrink down my glut dir but max attach file size here is 100k er so. sorry. Look out for the Mesa lib calls in the Makefiles.
took me a while to get that solved.

questions? cjlancour@link.com

[bwkaz]

Nah, you just need the GL/glut.h file, and libglut installed. Then, compile with gcc -o hello hello.c -lglut -lGLU -lGL -L/usr/X11R6/lib -- that works just fine, no need for the full glut source install.

But I don't see any tearing... what am I looking for? The output is simply various iterations of:

1050962054.632581: delta = 29.924989.

Is this normal?

[casey]

Thanks for the tip on how to compile that stuff easy.
That 1050962054.632581: delta = 29.924989 output
was code i added so i knew how long the render time was
between frames when a drop frame occurs in milliseconds. The actual tearing to look for is in the vertical sweeping line which will look something like this:

|
| image from new data post swapbuffers event
|
|
| image from data pre swapbuffers event
|


The tear in this example is beween 1st three lines and the last 3 lines. The tear in "hello" is a bit more subtile but it is there none the less (on all the computer's i have tested so far anyway, redhat 2.4-18kern dual ppro, gentoo 2.4.20kern P4). On all tests it seems to occur about 2/3s the way down the screen
and not constant, it comes and goes but you should be able to see it about 3-4 times per sweep (often enough not to be waiting arround for an error).


thanks for taking a look,

-=Casey cjlancour@link.com

[casey]

This forum deleted the spaces i put in front of the last three vertical lines i put in, how frustrating(suppose PREVIEW would have solved that one!). Guess I should have known. Ok new example:

|
| image post swapbuffers event
|
`|
`| image pre swapbuffers event
`|

*Backticks added for effect only.
**I included the glut.h file here for those who dont have it.

[bwkaz]

You can use [code] tags to keep the spacing. Not that it matters; I think I know what you mean.

I can't really tell whether or not it's doing that here, though. It doesn't look like it, but then, the bar is moving so fast that I probably wouldn't be able to see it if it did.

Let me try putting a slowdown factor in there (nanosleep(10 ms) or something)...

Hmm, I still don't see anything. Could be that I'm blind, but now every last one of the delta's is 20, every single time...

Maybe it has something to do with the card, or the CPU? I've got an Athlon XP1800 in here, with a GF4 Ti4200 if you think that matters...

[casey]

The bar is moving fast b/c you need to have the following environment variable set:

"export __GL_SYNC_TO_VBLANK=1" /* for bash */

You can type that from the bash command prompt to set the variable.

This will tell the computer to swapbuffers on vertical retrace rather than rendering at max speed or swaping buffers when as soon as its done rendering. I tried to mention that in some of the README stuff but it was badly written and done in a hurry, sorry. Set that environment variable and it should slow the line down to a reasonable speed. If you slow it w/ some kinda usleep er somthing, it wont be swaping on the vertical retrace(it will swap whenever), and you will defininitly see the line tearing(which might be a good experement so you know what the image tearing effect looks like). but running sync to vblank is supposed to eliminate this image tearing altogether (unless rendertime exceeds 16.67milliseconds, 60Hz or 13.8msec for 72hz ect.)

THe __GL_SYNC_TO_VBLANK=1 is what we use specificly to prevent image tearing on our realtime application for flight sims.

again, thanks for taking time to look at this. Since most people dont care about a little image tear, I believe this bug has gone unnoticed.

-=Casey cjlancour@link.com

[bwkaz]

Ah, you're right -- I had that set originally, then didn't when I rebuilt it the second time.

Setting it does slow the bar down, but I (unfortunately) still don't see any tearing at all. The bar does "stutter" once in a while (i.e. a single frame gets skipped), but this doesn't cause any tearing, just two frames with the bar in the same place.

[casey]

/me scratches head, rubbs eyes, stares at his program again. Humm.... Next question....
Why are my computers doing this?

Could I get a copy of your setup files(see if i have errored in some way):
XF86Config, XF86config.0.log, kernel vers, what driver yer using, ect. Wonder if its in my compiler some how? Are you using GART or NVIDIA's agp stuff?

The tearing is usualy only a few pixels wide. Wonder if speeding up the sweep would make it more obvious. Asuming its there and you dont see it, but its not like its really hard to see either so im guessing your right (/me shruggs).

void moveDisplay(void)
{
i = i + 0.004; /* change increment from 0.002 to 0.004 */
if (i > 1.0) {i = 0.0;}
glutPostRedisplay();
// usleep (16666);
}

As far as the jumping goes, thats normal b/c hello doesnt get exclusive access to the cpu, other progs like crond tones of windomanager apps will wake everyso often and cause that. just moving the mouse arround can do it too. To reduce this we usualy just run "X" no winmanager and kill all processes that we dont need (fakeing a realtime os, b/c we dont like the realtime linux)


thanks for the help,

-=Casey

[bwkaz]

Ah -- I wonder if it's the -preempt patches...

Anyway, my X config is attached. There's really nothing in the log file, but if you still want, I'll attach it to the next post.

Kernel 2.4.20, with the -preempt patch.

I'm using agpgart, with a KT333 motherboard. But it really wouldn't surprise me if it was -preempt.

If you want, you can look around at http://www.kernel.org/pub/linux/kernel/people/rml/preempt-kernel/v2.4/ for it.

[casey]

after a conversation w/ my partner in crime for our linux builds, it would seem we are using the preempt patch. The investigation continues......