PDA

View Full Version : OpenGL bugs on specific platforms only?



RobertWebb
04-24-2005, 01:22 AM
Hi,

Does anyone know if there is a site listing implementations of OpenGL that are buggy and how to work-around their problems? I am repeatedly coming up against weird behaviour on certain graphics cards.

My software works fine on my computer (of course!), but users sometimes report
weird behaviour. Takes a long time to track it down when I don't have access
to their machine. For example, drawing bitmap text during GL picking mode
crashes on many laptops!

Here's the latest one I'm stuck with:

I have a call to glColor3f() that isn't doing anything on one user's machine. I draw stuff before in another colour, change the colour, draw other stuff, but the new stuff comes out in the first colour. Remember, it works fine on ALL other computers I've encountered. I sent a diagnostic version and got the following info:

GL_VENDOR: 'Intel'
GL_RENDERER: 'Intel 845G'
GL_VERSION: '1.3.0 - Build 4.14.10.3889'

I also called the following before and after glColor3fv():

glGetFloatv(GL_CURRENT_COLOR, c);

And output the result to a diagnostic file. Sure enough, GL still thinks it's using the previous colour, unchanged by glColor3fv().

Weird thing is that the same code is used at another time and it works as expected, so there must be some difference in rendering state that causes this. It is not an intermittent problem though, it happens consistantly.

Anyone encountered this before? Any general tips for how to remotely debug such an issue?

Thanks,
Rob.

M/\dm/\n
04-24-2005, 02:58 AM
Color for what?

If you want to change color of bitmap fonts, then you must call glSetRasterPos or smthn. after you have changed color. Color of raster operations isn't updated otherwise.

RobertWebb
04-24-2005, 07:52 PM
Originally posted by M/\dm/\n:
Color for what?

If you want to change color of bitmap fonts, then you must call glSetRasterPos or smthn. after you have changed color. Color of raster operations isn't updated otherwise.Just for drawing lines, with:

glBegin(GL_LINES);
glVertex2dv(p1);
glVertex2dv(p2);
glEnd();
Don't forget, this works on EVERY other machine I've tried, and no one else has reported the problem, so I don't think I'm actually doing anything wrong. It's specific to this Intel graphics card. I find it's quite common for laptops to have problems with one or two aspects of OpenGL.

Rob.

RigidBody
04-24-2005, 10:06 PM
if you search in the advanced forum for "intel" and "opengl" you'll find some matches like No Hardware Acceleration (http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=3;t=012666)

intel doesn't seem to be a first choice for OpenGL

execom_rt
04-25-2005, 03:22 AM
Originally posted by RobertWebb:
Hi,

Does anyone know if there is a site listing implementations of OpenGL that are buggy and how to work-around their problems? I think that such of site would never happens.
It would be immediately shutted down due to NDA problems by the vendors, and the site owner would be sued for DMCA or something.

Just imagine a few secs. By exploiting one of the OpenGL bugs (especially crash-bugs), someone could write a virus or something to exploit the crash and gain administrator priviledges ...

RobertWebb
04-25-2005, 06:07 AM
Originally posted by execom_rt:
By exploiting one of the OpenGL bugs (especially crash-bugs), someone could write a virus or something to exploit the crash and gain administrator priviledges ...Really? I can write a program that crashes and doesn't even need OpenGL (I do it all the time :) ).

I found a work-around, by calling glFlush() before the call to glColor3f(). It only needs to be done once per frame, so hopefully it isn't a performance hit on other platforms.

Rob.

MickeyMouse
04-25-2005, 06:30 AM
Originally posted by RobertWebb:

I found a work-around, by calling glFlush() before the call to glColor3f(). It only needs to be done once per frame, so hopefully it isn't a performance hit on other platforms.That seems somewhat funny bug - looks like the driver's OpenGL operations' queue was full at the time you called glColor3f() and so your call was simply rejected / ignored.

execom_rt
04-25-2005, 10:26 AM
Really? I can write a program that crashes and doesn't even need OpenGL (I do it all the time :) ).
Yes, but it's your program. The crash in opengl would be in a SYSTEM DLL, so with administrator rights.

Moreover, this DLL would be present in much more computers than your program ;)

zed
04-25-2005, 08:22 PM
Does anyone know if there is a site listing implementations of OpenGL that are buggy and how to work-around their problems? I am repeatedly coming up against weird behaviour on certain graphics cards.IIRC there was something from intel? a few years ago, a replacement to opengl32.dll or someit. anyways IIRC there was a bit of info about various cards and various problems with them (of course it prolly hasnt been maintained but u never know)

sqrt[-1]
07-25-2005, 04:50 PM
Just a post for historical purposes:

I was also getting a crash on Intel 845G chipsets. (only this chipset, the newer Intel chipsets were fine)

It turns out that it does not like using hardware-mipmap generation and crashes in the driver when it is being used. (even tho it is in the extension string)

I found this by knocking out each OpenGL extension one by one, (via GLIntercept) until the crash went away.

Hopefully this may be of some use to other people.

Korval
07-25-2005, 05:22 PM
It would be immediately shutted down due to NDA problems by the vendors, and the site owner would be sued for DMCA or something.Are you aware that NDA stands for "non-disclosure agreement?" As in, two people agreeing to something? In order for a hardware vendor to accuse you of violating an NDA, they have to make you sign one first. Plus, they then have to disclose some information to you; finding a bug doesn't count.

Similarly, the DMCA deals with copyrights, and the violation thereof. The existence of a bug is hardly copyrightable, so it doesn't apply here.

An OpenGL bug site would be no different from a Consumer Reports style website.


Yes, but it's your program. The crash in opengl would be in a SYSTEM DLL, so with administrator rights.You realize that "crash" means "the program halts execution", right? This means that it stopped. You can't use that to make a virus, because the program that the virus is a part of would have stopped.

This isn't a buffer overrun or anything; it's just a crashed process.

And even so, I'm not entirely convinced that system .dll's run with adminstrator rights.

rgpc
07-25-2005, 09:17 PM
Korval, in the minds of the paranoid - anything is possible. ;)

execom_rt
07-26-2005, 01:36 AM
Intel graphics chipsets are not suited for 3D anyway (especially in OpenGL). I think the Direct3D is better because if the driver is WHQL, it has been tested by Microsoft (in D3D of course).

There is no equivalent for OpenGL (no 'OpenGL' certified driver).

Just look at thoses pages :

http://support.intel.com/support/graphics/sb/CS-010438.htm

or

http://support.intel.com/support/graphics/sb/CS-014555.htm

And see how well thoses chipset works on modern games ...

sqrt[-1]
07-26-2005, 03:52 AM
I think Intel is getting a bad rap from some of their earlier chipsets.

810 - Poor
815 - Poor
845 - Okish with some issues.
865 - Ok
915 - I have had zero issues. (Plus this has ARBVP/ARBFP)

The above two links are for the ancient 810/815 chipsets. (1999 era?) I would like to see a Nvidia/ATI card from that era try and run Doom3/Farcry. (which is what the above two bug reports are about)

execom_rt
07-26-2005, 04:44 AM
Yes it's an oldish chipset I've took as example. But even a Voodoo2 can manage to run Doom 3 ...

Anyway, you can send a mail to

graphics@mailbox.intel.com

with specific details.

They might help you.

sqrt[-1]
07-26-2005, 05:08 PM
Originally posted by execom_rt:
Yes it's an oldish chipset I've took as example. But even a Voodoo2 can manage to run Doom 3 ...

Anyway, you can send a mail to

graphics@mailbox.intel.com

with specific details.

They might help you.umm, the voodoo2 has no chance of running Doom3 out of the box. The only way people got it to run was using a hacked up opengl32.dll that essentially displayed everything as flat diffuse. (and reporting to the Doom3 game that it was a better card than it was as well as uncompressing all textures and scaling them to 1/10 their size)

If the same effort was done I am sure it could run on the Intel 810.

zed
07-26-2005, 05:31 PM
surely noone who actually buys games is actually using an intel chipset it seems it struggles both with opengl + d3d
http://graphics.tomshardware.com/graphic/20050524/vga_charts-07.html
http://graphics.tomshardware.com/graphic/20050524/vga_charts-05.html

be wary of anything with the word extreme etc in its name

bashbaug
07-27-2005, 04:00 PM
Sorry I missed this the first time (back in April!).

RobertWebb or sqrt[-1], if you're still having issues with the Intel driver please send me an email.

Thanks,
-- Ben

James Dolan
07-27-2005, 05:57 PM
"surely noone who actually buys games is actually using an intel chipset it seems it struggles both with opengl + d3d"

You say that, but Intel is actually the number one GPU producer on the planet by volume. I can imagine that at least a few of the people that buy computers with Intel GPUs use them to play games to some extent, so ignoring the issue is not going to make it go away.