Go Back   nV News Forums > Linux Support Forums > NVIDIA Linux

Newegg Daily Deals

Reply
 
Thread Tools
Old 04-03-03, 09:29 PM   #1
grmoc
.. Arg!!. Uh Pinky?
 
Join Date: Jan 2003
Posts: 38
Default 4191 and 4349 2d corruption problem

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!
Attached Thumbnails
Click image for larger version

Name:	ewwww.jpg
Views:	235
Size:	92.9 KB
ID:	1158  
grmoc is offline   Reply With Quote
Old 04-03-03, 10:17 PM   #2
grmoc
.. Arg!!. Uh Pinky?
 
Join Date: Jan 2003
Posts: 38
Default More on the bug

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)
grmoc is offline   Reply With Quote
Old 04-03-03, 10:33 PM   #3
bwkaz
Registered User
 
Join Date: Sep 2002
Posts: 2,262
Default

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?
__________________
Registered Linux User #219692
bwkaz is offline   Reply With Quote
Old 04-04-03, 04:59 AM   #4
grmoc
.. Arg!!. Uh Pinky?
 
Join Date: Jan 2003
Posts: 38
Default

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.
grmoc is offline   Reply With Quote
Old 04-04-03, 09:23 AM   #5
bwkaz
Registered User
 
Join Date: Sep 2002
Posts: 2,262
Default

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?
__________________
Registered Linux User #219692
bwkaz is offline   Reply With Quote
Old 04-04-03, 02:43 PM   #6
grmoc
.. Arg!!. Uh Pinky?
 
Join Date: Jan 2003
Posts: 38
Default

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.
grmoc is offline   Reply With Quote
Old 04-04-03, 03:17 PM   #7
Andy Mecham
l33t master
 
Join Date: Jul 2002
Location: Santa Clara, CA
Posts: 1,163
Default

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

Quote:
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
__________________
Andy Mecham
NVIDIA Corporation
Andy Mecham is offline   Reply With Quote
Old 04-04-03, 03:57 PM   #8
grmoc
.. Arg!!. Uh Pinky?
 
Join Date: Jan 2003
Posts: 38
Default

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.
Attached Thumbnails
Click image for larger version

Name:	ewww2.jpg
Views:	140
Size:	95.5 KB
ID:	1180  
grmoc is offline   Reply With Quote

Old 04-04-03, 04:42 PM   #9
grmoc
.. Arg!!. Uh Pinky?
 
Join Date: Jan 2003
Posts: 38
Default

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;
}
Attached Thumbnails
Click image for larger version

Name:	ewww3.png
Views:	163
Size:	48.5 KB
ID:	1182  
grmoc is offline   Reply With Quote
Old 04-04-03, 04:44 PM   #10
grmoc
.. Arg!!. Uh Pinky?
 
Join Date: Jan 2003
Posts: 38
Default

Sorry about this, but there is one more thing-
Remeber- This bug manifests with 4191 and 4349, but not 3123.
grmoc is offline   Reply With Quote
Old 04-04-03, 04:54 PM   #11
Andy Mecham
l33t master
 
Join Date: Jul 2002
Location: Santa Clara, CA
Posts: 1,163
Default

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

--andy
__________________
Andy Mecham
NVIDIA Corporation
Andy Mecham is offline   Reply With Quote
Old 04-04-03, 05:09 PM   #12
grmoc
.. Arg!!. Uh Pinky?
 
Join Date: Jan 2003
Posts: 38
Default

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..
Attached Files
File Type: txt test.cpp.txt (2.8 KB, 131 views)
grmoc is offline   Reply With Quote
Reply


Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT -5. The time now is 12:19 AM.


Powered by vBulletin® Version 3.7.1
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Copyright 1998 - 2014, nV News.