4191 and 4349 2d corruption problem

[grmoc]

Ok, this one is a fun one...

(screenshot attached, with lots of ugly .jpg compression (sorry about that))

Take just about any program that updates the screen quickly.

e.g.

#include <stdio.h>
int main(int argc, char**argv){
int i;
while(1){
printf("\r");
for(int j=0;j<10;++j) printf("happy happy joy joy ");
printf(" %d",++i);
}
return 1;//keeps compiler happy. Bad compiler!
}

Ok, now run it for a while. Some random amount ot time later, you'll start getting corruption anywhere you move the mouse. The corruption seems to start in the rapidly updating window,
and then can at times go away.

This bug is not apparent in 3123, but IS in 4191.

.. I do lots of GL programming every day with your drivers (I do real-time television special-effects)... and that means that I can be a veritable fountain of bugs. Should I just email them to linux-bugs@nvidia.com, or do you want me to post here first?

Thanks!

[grmoc]

Switching desktops seems to temporarily clear the problem (i.e. fully obscuring everything, then reshowing it).

It really is a wierd bug. (And it -never- happens in 3123)

[bwkaz]

WFM...

But then again, I'm not running a heavy DE, either. Does it still happen if you turn off Gnome and run just a window manager?

[grmoc]

Yup. After some random amount of time, it still happens even with TWM and no pretty-stuff. (i.e. TWM+xterm)

It can take on the order of hours to reproduce this one at times.. Other times it takes seconds.

I havnt yet disabled a CPU (it is an SMP system) to see if that has anything to do with it.

[bwkaz]

Interesting... you might want to try disabling a CPU, yeah. Might be a workaround, anyway -- granted, a pretty crappy one, but still.

Your monitor isn't by any chance connected via the DVI port, in digital mode, is it?

[grmoc]

Hahahahah No...

When you have a DVI connection in digital mode on an SMP machine, you have problems (i.e. doesn't work at all, machine hangs).

It is in analog mode.... However that being said, with 4191 (when DVI worked) the same behaviour manifested with either the DVI output or the HD15 output.

I've tried turning off UBB, alas that did nothing.

I'll try it in non-SMP mode now.

[Andy Mecham]

Cool, thanks for the sample code. I'll look at this today.

When you have a DVI connection in digital mode on an SMP machine, you have problems (i.e. doesn't work at all, machine hangs).

Whatever works easiest for you. Sample code (and detailed descriptions) are very useful to those on the NVIDIA end of linux-bugs@nvidia.com. We're always happy to fix bugs.

--andy

[grmoc]

okies, we'll keep to this forum for the meantime, I'll send more easily reproducible bugs directly to linux-bugs@nvidia.com

Allrighty then, here is a screen-shot of the behaviour using TWM.

In this case, I did not have a lot of printouts in a terminal, but rather had a xforms (which is a widget set) text-label updating with the frame-rate. (some 1000 fps for this particular application).

Look at the fields which appear black. TWM exhibits slightly different behaviour than KDE's WM- when you switch windows most of the time the problem temporarily goes away.

I'm going to try uniprocessor mode next.

[grmoc]

Allrighty, this is in uniprocessor mode, with a different application triggering the bug. Screenshot attached.

Use the following code to duplicate the problem (which seems only to manifest when applications use GL... at least thusfar..)

//
// Command line to compile me:
//
// g++ test.cpp -lGL -lGLU -L/usr/X11R6/lib -lX11

#include <iostream>

using namespace std;

#ifdef DEBUG
# define ONDEBUG(X) X
#else
# define ONDEBUG(X)
#endif


#include <X11/Xlib.h>
#include <X11/keysym.h>
#include "GL/gl.h"
#include "GL/glx.h"
#include "GL/glu.h"

int main(int argc, char** argv){
Display *_dpy=0;
GLXFBConfig* _configs=0;
GLXContext *_ctx=0;

GLXPbuffer _pbuffer;

char *dpyName = 0;

_dpy = XOpenDisplay(dpyName);
if (!_dpy) {
std::cerr<<"Error: couldn't open display ";
if(dpyName) std::cerr<<dpyName;
std::cerr<<"\n";
exit(0);
}

int i;

int nItems=0;
int fbAttribList[]={
GLX_RED_SIZE,8,
GLX_GREEN_SIZE,8,
GLX_BLUE_SIZE,8,
GLX_ALPHA_SIZE,8,
GLX_STENCIL_SIZE,8,
GLX_DEPTH_SIZE,24,
GLX_ACCUM_RED_SIZE,16,
GLX_ACCUM_GREEN_SIZE,16,
GLX_ACCUM_BLUE_SIZE,16,
GLX_ACCUM_ALPHA_SIZE,16,
GLX_RENDER_TYPE,GLX_RGBA_BIT,
GLX_DRAWABLE_TYPE,GLX_PBUFFER,
GLX_CONFIG_CAVEAT,GLX_NONE,
None
};


_configs=glXChooseFBConfig(_dpy,DefaultScreen(_dpy ),
fbAttribList,&nItems);

//GLXFBConfig* configs=glXGetFBConfigs(dpy,DefaultScreen(dpy),&nI tems);
ONDEBUG(std::cerr<<nItems<<" GLXFBConfigs returned.\n"

if(_configs==0){
std::cerr<<"error: "<< gluErrorString(glGetError()) <<"\n";
std::cerr<<"dpy==" <<(void*)_dpy<<" screen="<<DefaultScreen(_dpy)<<"\n";
std::cerr<<"configs="<< (void*)_configs<<"\n";
std::cerr<<"Wasn't able to choose a valid FBConfig. Exiting.\n";
exit(0);
}

int pbAttribList[] = {
GLX_PBUFFER_WIDTH,720,
GLX_PBUFFER_HEIGHT,486,
None
};

_pbuffer=glXCreatePbuffer(_dpy,_configs[0],pbAttribList);
ONDEBUG(std::cerr<<"Here is the pbuffer!! ("<<_pbuffer <<")\n"


_ctx = new GLXContext;
*_ctx=glXCreateNewContext(_dpy,_configs[0],GLX_RGBA_TYPE,0,True );

ONDEBUG(std::cerr<<"Here is the ctx!" <<_ctx<< "\n"
if(glXMakeCurrent(_dpy,_pbuffer,*_ctx)){
ONDEBUG(std::cerr<<"Binding of new glx context (to pbuffer) is successful\n"
}else{
std::cerr<<"Doh! Binding of new glx context (to pbuffer) is NOT successful\n";
std::cerr<<"Gl says: \"" << gluErrorString(glGetError()) <<"\"\n";
}

std::cerr<<"GL_RENDERER = "<< glGetString(GL_RENDERER) <<"\n";
std::cerr<<"GL_VERSION = "<< glGetString(GL_VERSION) <<"\n";
std::cerr<<"GL_VENDOR = "<< glGetString(GL_VENDOR) <<"\n";
std::cerr<<"GL_EXTENSIONS = "<< glGetString(GL_EXTENSIONS) <<"\n";

glViewport(0,0,720,486);
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
glOrtho(0,720,0,486,-10000,10000);
glMatrixMode(GL_MODELVIEW);
glLoadIdentity();


unsigned char frameBuf[720][486][4];
i=0;
while(1){
glReadPixels(0,0,720,486,GL_RGBA,GL_UNSIGNED_BYTE, (unsigned char*) frameBuf);
cerr<<"\rThis is a string of indeterminate length. I love big words "<<++i<<" iterations";
}
return 1;
}

[grmoc]

Sorry about this, but there is one more thing-
Remeber- This bug manifests with 4191 and 4349, but not 3123.

[Andy Mecham]

grmoc: it's probably better to attach sample code as a file rather than cut-n-paste - formatting can be broken in forums.

--andy

[grmoc]

OKdokie, noted

I would have attached it (It was less work that way), but already had the attachment. Here it is again in non-reformatted non-smiley plaintext..