intel video card -> opengl errors

[jamerlan]

This post consists of 2 sections: 1) Errors found with glIntercept 2) Error handling in OpenGL - my research

My main idea was: spring should work on intel video cards. I think that some opengl errors can be fixed/workarounded and spring will run on intel. So I tryed to find out which errors can produce these visual bugs on intel video. And I find a few ways how to get error messages. 1) glIntercept (http://code.google.com/p/glintercept/) 2) glGetError() (http://www.glprogramming.com/red/chapter14.html#name1)

So 1) glIntercept. It works only under windows. So I played short singleplayer game with 2-4 fps using this tool. Error log is attached (gliLog.txt).

2) glGetError(). I downloaded spring code and put

Code: Select all

GLenum errCode;
const GLubyte *errString;

if ((errCode = glGetError()) != GL_NO_ERROR) {
    errString = gluErrorString(errCode);
   LOG("OpenGL Error: %s\n", errString);
}

into Game:Draw function to get errors. Also I rewrite clearGlErrors function and some other places where I found glGetError().

So I compilled and tested spring with glGetError() enabled. It logs lot's of GL_INVALID_ENUM too.

I am newbie in c++ and opengl.. So maybe my research was very dumb. I just want to show you these errors, maybe you can fix it and spring will run under intel without problems?

------
Why we can see strange visual bugs using intel video:

When OpenGL detects an error (in either the base GL or GLU), it records a current error code. The command that caused the error is ignored, so it has no effect on OpenGL state or on the framebuffer contents.

What we can do to detect such opengl errors?

It is strongly recommended that you call glGetError() at least once in each display() routine

[jamerlan]

If it's hard to fix these errors, maybe we can log them better?

[jK]

those `errors` are by design and handled correctly

[jamerlan]

Why spring does not work on intel then? I think because of these opengl errors.

Why we don't log these errors?

It is strongly recommended that you call glGetError() at least once in each display() routine

[jK]

Why spring does not work on intel then? I think because of these opengl errors.

Cause their OpenGL drivers have endless loops, pointer dangling, ... in them = their drivers are BUGGED.
Neither do they update/fix once released drivers (for most GPUs there was just _one_ driver released and never updated!)

It is strongly recommended that you call glGetError() at least once in each display() routine

Cause it is a flush operator? (it will halt the thread until the GPU is finished with processing all commands in the GL stream)

[abma]

two possible solutions:
improve this, so it works with spring:
http://sourceforge.net/projects/gldirect/ (opengl->directx wrapper) i don't know if its possible to do that with a nice performance (or at all...)

currently it cries about "Needed OpenGL extension(s) not found: GL_ARB_texture_env_combine GL_ARB_texture_compression

use linux! intels opensource drivers should be better as the closed one. they are regulary updated and some steam and intel guys are currently working on improving it.

(just my two cents)

[jamerlan]

abma, I use linux. And spring has lots of visual bugs with intel sandy bridge video. Unplayable. So OpenGL->DirectX is not a solution for me :-D I think realo solution - understand what exactly causes problems and fix/workaround it.

I rebooted to windows just to get glIntercept reports as OpenGL errors example.

those `errors` are by design and handled correctly

Sounds strange. But I am newbie. So I will trust you.

[abma]

abma, I use linux. And spring has lots of visual bugs with intel sandy bridge video. Unplayable. So OpenGL->DirectX is not a solution for me :-D I think realo solution - understand what exactly causes problems and fix/workaround it.

from your infolog.txt:
OS: Microsoft Windows

sad to hear that its still unplayable. hopefully it becomes better when steam officially supports linux.

[jamerlan]

from your infolog.txt:
OS: Microsoft Windows

I rebooted to windows just to get glIntercept reports as OpenGL errors example.

glIntercept works under windows only

[jamerlan]

I tried to research more.. don't be anger please.

Lot's of errors in different places.

For example (from infolog.txt):
[f=0009721] after LocalModelPiece::Draw() glCallList(dispListID); OpenGL Error: invalid operation

How I traced:

Code: Select all

void LocalModelPiece::Draw() {
....
if ((errCode = glGetError()) != GL_NO_ERROR) {
	errString = gluErrorString(errCode);
	LOG("before LocalModelPiece::Draw() glCallList(dispListID); OpenGL Error: %s\n", errString);
}

if (visible)
	glCallList(dispListID);

if ((errCode = glGetError()) != GL_NO_ERROR) {
	errString = gluErrorString(errCode);
	LOG("after LocalModelPiece::Draw() glCallList(dispListID); OpenGL Error: %s\n", errString);
}
...
}

Sad that I have not knowledge of OpenGL and especially Display Lists. Can't understand how models can have these lists with errors.

[jK]

I wonder if MESA dislikes

Code: Select all

glCallList(0);

[jamerlan]

Wow! I found something!

http://www.mesa3d.org/debugging.html

Normally Mesa (and OpenGL) records but does not notify the user of errors. It is up to the application to call glGetError to check for errors. Mesa supports an environment variable, MESA_DEBUG, to help with debugging. If MESA_DEBUG is defined, a message will be printed to stdout whenever an error occurs.

also

There is a display list printing/debugging facility. See the end of src/dlist.c for details.

[jamerlan]

Mesa prints messages like that:
Mesa: User error: GL_INVALID_ENUM in glPolygonMode(mode)
(my logging) [f=0000237] after eventHandler.DrawWorldPreUnit(); OpenGL Error: invalid enumerant

[jamerlan]

hm... what can be wrong in simple functions like glPolygonMode?

looks like this function accepts constants, why it says: wrong enum? :-D

Searching in Spring code...
...
glPolygonMode(GL_FRONT_AND_BACK, GL_FILL);
...
glPolygonMode(GL_FRONT_AND_BACK, GL_LINES);
...
glPolygonMode(GL_FRONT_AND_BACK, GL_LINE);
...

CommandDrawer.cpp -> glPolygonMode(GL_FRONT_AND_BACK, GL_LINES);
WHAT? GL_LINES? Is it correct constant? looks like not! http://www.cs.rutgers.edu/~decarlo/428/ ... nmode.html

from glew.h
#define GL_LINE 0x1B01
#define GL_LINES 0x0001

[jamerlan]

I recompiled Spring without LINES and there are now less errors. But still lots of them.

Examples:
Mesa: User error: GL_INVALID_ENUM in glGetFramebufferAttachmentParameterivEXT(attachment)
Mesa: User error: GL_INVALID_OPERATION in glFramebufferTexture2DEXT

Mesa: User error: GL_INVALID_OPERATION in Inside glBegin/glEnd
Mesa: 13 similar GL_INVALID_OPERATION errors
Mesa: User error: GL_INVALID_OPERATION in glBegin
[f=0025148] after LocalModelPiece::Draw() glCallList(dispListID); OpenGL Error: invalid operation

Mesa: User error: GL_STACK_OVERFLOW in glPushAttrib
[f=0025616] after selectedUnits.DrawCommands(); OpenGL Error: stack overflow

Mesa: User error: GL_INVALID_OPERATION in Inside glBegin/glEnd
Mesa: 411 similar GL_INVALID_OPERATION errors
Mesa: User error: GL_INVALID_OPERATION in glBegin
[f=0025619] after sky->DrawSun(); OpenGL Error: invalid operation

Mesa: User error: GL_STACK_OVERFLOW in glPushAttrib
[f=0025810] after featureDrawer->DrawFadeFeatures(noAdvShading); OpenGL Error: stack overflow

conclusion: lot's of problems inside display lists. Only god knows how to fix them. Looks like we need to compile mesa with debug symbols and use "void
mesa_print_display_list(GLuint list)" function from ./src/mesa/main/dlist.c

How to use it? I have no idea.

[jamerlan]

glGetFramebufferAttachmentParameterivEXT
located in FBO::DownloadAttachment(const GLenum attachment)

and used:
for(int i = 0; i < 15; ++i) {
DownloadAttachment(GL_COLOR_ATTACHMENT0_EXT + i);
}

why ++i? what will be generated as result?
DownloadAttachment(GL_COLOR_ATTACHMENT0_EXT + 0);
...
DownloadAttachment(GL_COLOR_ATTACHMENT0_EXT + 15);
???

According documentation:
http://wiki.delphigl.com/index.php/GL_E ... fer_object
there are from 0 to 15 inclusive.

GL_COLOR_ATTACHMENT0_EXT
GL_COLOR_ATTACHMENT1_EXT
GL_COLOR_ATTACHMENT2_EXT
GL_COLOR_ATTACHMENT3_EXT
GL_COLOR_ATTACHMENT4_EXT
GL_COLOR_ATTACHMENT5_EXT
GL_COLOR_ATTACHMENT6_EXT
GL_COLOR_ATTACHMENT7_EXT
GL_COLOR_ATTACHMENT8_EXT
GL_COLOR_ATTACHMENT9_EXT
GL_COLOR_ATTACHMENT10_EXT
GL_COLOR_ATTACHMENT11_EXT
GL_COLOR_ATTACHMENT12_EXT
GL_COLOR_ATTACHMENT13_EXT
GL_COLOR_ATTACHMENT14_EXT
GL_COLOR_ATTACHMENT15_EXT

I think that for loop should looks like:

for(int i = 0; i <= 15; i++) {
DownloadAttachment(GL_COLOR_ATTACHMENT0_EXT + i);
}

the same for:
FBO::DetachAll()
for(int i = 0; i < 15; ++i) {
Detach(GL_COLOR_ATTACHMENT0_EXT + i);
}

maybe I am wrong

[jK]

Code: Select all

for(int i = 0; i < 15; ++i) {
    stdout << i << endl;
}

0
1
...
14 !

PS: using post- or pre-increment operator doesn't make any _logical_ difference in for-loops increment part (still pre-increment produces more efficient code with non-native vartypes).

[gajop]

(still pre-increment produces more efficient code with non-native vartypes).

theoretically, yes, but aren't compilers allowed to optimize? (i've been told they do for most stl iterators and such)

[jamerlan]

jK,

can you fix and commit this? CommandDrawer.cpp -> glPolygonMode(GL_FRONT_AND_BACK, GL_LINES);

0
1
...
14 !

So that means that "GL_COLOR_ATTACHMENT15_EXT" will be ignored? It's not a bug and works by design?

[jamerlan]

interesting info for nvidia and amd video:

A new development area through OpenGL debugging (GL_ARB_debug_output)
http://www.g-truc.net/post-0320.html

Catch all errors without distinction:
glDebugMessageControlARB(GL_DONT_CARE, GL_DONT_CARE, GL_DONT_CARE, 0, NULL, GL_TRUE);
glDebugMessageCallbackARB(&glf::debugOutput, NULL);

This extension is supported by nVidia drivers and through GL_AMD_debug_output on AMD drivers