nV News Forums


nV News Forums (http://www.nvnews.net/vbulletin/index.php)
-   NVIDIA Linux (http://www.nvnews.net/vbulletin/forumdisplay.php?f=14)
-   -   4191 and 4349 2d corruption problem (http://www.nvnews.net/vbulletin/showthread.php?t=9607)

grmoc 04-03-03 08:29 PM

4191 and 4349 2d corruption problem
1 Attachment(s)
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.


#include <stdio.h>
int main(int argc, char**argv){
int i;
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?


grmoc 04-03-03 09:17 PM

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)

bwkaz 04-03-03 09:33 PM


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 04-04-03 03:59 AM

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 04-04-03 08:23 AM

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 04-04-03 01:43 PM

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 04-04-03 02:17 PM

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. :D


grmoc 04-04-03 02:57 PM

1 Attachment(s)
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 04-04-03 03:42 PM

1 Attachment(s)
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
# define ONDEBUG(X)

#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;

int i;

int nItems=0;
int fbAttribList[]={

_configs=glXChooseFBConfig(_dpy,DefaultScreen(_dpy ),

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

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";

int 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";)
ONDEBUG(std::cerr<<"Binding of new glx context (to pbuffer) is successful\n";)
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";


unsigned char frameBuf[720][486][4];
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 04-04-03 03:44 PM

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

Andy Mecham 04-04-03 03:54 PM

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


grmoc 04-04-03 04:09 PM

1 Attachment(s)
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..

All times are GMT -5. The time now is 10:49 PM.

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