Jump to content
Eternal Lands Official Forums
Entropy

For the people with WIndows/Intel video cards

Recommended Posts

 

perhaps it would be useful to know, how much graphical memory do people have who are seeing this? (including if it's 'shared' or whatever...) (note to self/other coders: end pg 11)

are there people with other cards/chips using less than, say, 32M/64M video memory, who have been to these places without a problem?

are there people who are using drivers with OpenGL 1.4 or lower not with an intel chip that have seen this problem? (intel docs say max of OpenGL 1.4 support)

you can get the OpenGL version with #glinfo in-game

 

Mine (915G) has 128mb shared video memory and I have the newest driver available for it which has an OpenGL version of 1.4.

 

Icy was using an 845G, that has 64mb shared and I believe the current driver has OpenGL 1.3.

Share this post


Link to post
Share on other sites
I guess that should be put in the DEBUG thingy, rather than a stand alone define..
the reason I didn't do that was because I really am going a bit overboard with the checks... even in places where it shouldn't be possible for a problem (like start-lines, draw some lines, end-lines)

 

also, just checked, the slowdown from all the extra calls is significant (around a quarter 18%, if my check was right, though it does seem rather high)

 

should it be checked in, or should I send the patch to someone to compile a test client for the intel-using people?

 

ed: actually, I may be seeing this problem myself... when I go to the location, there seems to be a green light coming from somewhere... and I'm also getting results with the extra opengl-error-check calls, which I'm looking into

Edited by ttlanhil

Share this post


Link to post
Share on other sites

Well, that's what the debug versions are for, I think an 18% speed penalty is more than OK. And that code might be useful for future problems, so I don't see any reason why not to commit it.

Share this post


Link to post
Share on other sites
Well, that's what the debug versions are for, I think an 18% speed penalty is more than OK. And that code might be useful for future problems, so I don't see any reason why not to commit it.
sure, but I normally run under -DDEBUG for the extra info, and I don't like to think what would happen if there was a 20% drop in FPS every time there was debugging info for some obscure bug was added :) (it would quickly get so that you couldn't debug anyway, I imagine, because it'd be so slow)

 

anyway, I thought I had been excessive enough to add it to the end of all functions using opengl, but I still get some odd results. after a <1min run:

grep  OpenGL ~/.elc/error_log.txt |sort|uniq -c
178 elwindows.c.draw_window:1067 - OpenGL invalid operation
890 font.c.draw_string_small:747 - OpenGL invalid operation
207 font.c.draw_string_zoomed_width:457 - OpenGL invalid operation
178 spells.c.display_quickspell_handler:785 - OpenGL invalid operation
178 spells.c.display_spells_we_have:252 - OpenGL invalid operation

in the first one, it's the call to one of the windows' own display_handler() that can cause an OpenGL error.

in the font.c calls, it's the check at the start of the function (after only variable declaration). same for the second spells.c call.

however, display_quickspell_handler is a very special case:

<snip>
	glBegin(GL_QUADS);
	for(i=1;i<7;i++) {
			if(mqb_data[i] && mqb_data[i]->spell_name[0]){
<snip>
					draw_2d_thing(u_start,v_start,u_end,v_end, x-width,y-height,x+width,y+height);
			}
	}
#ifdef OPENGL_TRACE
CHECK_GL_ERRORS();
#endif //OPENGL_TRACE
	glEnd();
#ifdef OPENGL_TRACE
CHECK_GL_ERRORS();
#endif //OPENGL_TRACE

it's this last call that registers the problem. apparently glEnd() is the offending function

also, as above, it looks like there's a strong green light coming from the west:

http://i17.photobucket.com/albums/b62/ttla...elscreen065.png

http://i17.photobucket.com/albums/b62/ttla...elscreen066.png

http://i17.photobucket.com/albums/b62/ttla...elscreen067.png

 

ed: a couple of links that may be of interest: http://www.opengl.org/pipeline/article/vol002_5/ and http://petewarden.com/notes/archives/2006/...ng_openg_1.html

 

ed2: oh well, commit'd now, as -DOPENGL_TRACE (since it may be useful later, but a performance hit for something that would rarely be needed doesn't seem worth it)

one thing I noticed while looking though the code... `void draw_3d_object_detail(object3d * object_id)` in 3d_objects.c, and at around like 310:

		/*
	DANGER:

	The below client state management code is commented out because client
	states are assumed to be managed by the caller, since these will be
	rendered in series.  IF THIS ASSUMPTION IS EVER VIOLATED, this code
	may well crash.  glDrawArrays DOES NOT TAKE KINDLY TO THINGS THAT ARE
	ENABLED BUT FOR WHICH THE ARRAYS HAVE NOT BEEN SET.

	You have been warned.
	*/

this function already checks for OpenGL errors, but I figured it may be of interest to anyone else looking into this

Edited by ttlanhil

Share this post


Link to post
Share on other sites

How can there be an error in such a simple function?

Maybe if nothing was drawn between begin/end (like if the if() fails )?

 

Anyway, the green light thing, is it at the location with the Intel problem?

Share this post


Link to post
Share on other sites
How can there be an error in such a simple function?

Maybe if nothing was drawn between begin/end (like if the if() fails )?

darn good question :) unfortunately, I just tested, and the result is as I'd expect, 4 cases where it's true, followed by 2 there it isn't (I have 4/6 spell quickbar slots used). so there's always something done in that for() loop

and draw_2d_thing() does include one of the extra checks, so it's not the cause of the problem... unless there can be an error that is caused by something before the glBegin() and OpenGL doesn't register it until the glEnd() (which would be possible, I guess), this is very funky... it seems like something in another thread (or even another process) is messing with stuff... but if so, why would it only be at that stage, and not random?

very interesting, in the pejorative sense

Anyway, the green light thing, is it at the location with the Intel problem?
same place (exact coords) as maxine's screenies

Share this post


Link to post
Share on other sites

well whoops... looks like the errors there was because you can't check for an error in a glBegin()... if there's no check until after the glEnd(), it isn't interrupted, and it doesn't complain that there was an unexpected call during that glBegin()/glEnd() pair. makes sense (though the late reporting is confusing).

 

well, there's still a lot of calls in CVS, but after some more tuning, I no longer get any reports of OpenGL errors in a >1min test spinning the camera at that location... if there's anyone who gets the darkness problem, and compiles CVS, can you check with that option on?

Share this post


Link to post
Share on other sites

Just a little additional information I got with help from Segal (TECHie) about my system:

#opengl command results in

[08:13:49] Video card: Intel 915GM

[08:13:49] Vendor ID: Intel

[08:13:49] OpenGL Version: 1.4.0 - Build 4.14.10.4609

[08:13:49] Supported extensions: GL_ARB_depth_texture GL_ARB_fragment_program GL_ARB_multitexture GL_ARB_point_parameters GL_ARB_shadow GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_dot3 GL_ARB_texture_env_crossbar GL_ARB_transpose_matrix GL_ARB_vertex_buffer_object GL_ARB_vertex_program GL_ARB_window_pos GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_func_separate GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_clip_volume_hint GL_EXT_compiled_vertex_array GL_EXT_cull_vertex GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_multi_draw_arrays GL_EXT_packed_pixels GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_specular_color GL_EXT_shadow_funcs GL_EXT_stencil_two_side GL_EXT_stencil_wrap GL_EXT_texture_compression_s3tc GL_EXT_texture_env_add GL_EXT_texture_env_combine GL_EXT_texture_filter_anisotropic GL_EXT_texture3D GL_3DFX_texture_compression_FXT1 GL_Irepeat GL_NV_blend_square GL_NV_texgen_reflection GL_SGIS_generate_mipmap GL_WIN_swap_hint

 

The Intel 915GM (mobile series) does not have its own memory but uses the RAM from the motherboard. Segal looked at identical laptop and told me.

#GM from Segal: looks like 128mb shared .. which means your video card uses your RAM memory

I hope this helps answer the question about the memory.

Share this post


Link to post
Share on other sites

We discovered that there were some 'bad lights' in that map, and ttlanhil commited some code in the cvs that is supposed to fix it.

I put a new binary on (same url) so please try it.

Share this post


Link to post
Share on other sites

darnit... well, has error_log.txt changed much? (I don't know if ent included the new OpenGL error checking or not, so it may not have)

Share this post


Link to post
Share on other sites

for the opengl stuff, it's just -DDEBUG and -DOPENGL_TRACE

of course, just narrowing it down to where the offending code is called is the first step... after that it'd be trying the stuff CK said about checking the stack and what-not

Share this post


Link to post
Share on other sites

Ok, I have an idea:

We need a special key (F12 or something) that clears ALL the lights in the map, and adds two lights: 1 global light (light #7), and one local light, at your feet.

 

This way we can see if it is a light problem or not..

Share this post


Link to post
Share on other sites

Good Golly Fuck, that compile option of yours has a HUGE bug in it, it will take all the hdd space with the error log, and closing the client won't help (it needs to be terminated manually).

Here is what it spams the error log with:

 

elc/3d_objects.c.free_e3d_va:1975 - OpenGL invalid operation

 

It repeats the same line over and over.

Share this post


Link to post
Share on other sites

well that's interesting, I didn't have any on the latter runs when testing this, and now the only one I get is:

reflection.c.draw_lake_water_tile_framebuffer:452 - OpenGL invalid operation

 

yes, it's going to print a lot. we render however many times per second, and this does additional checks many times per render. so if there's a problem, it can be expected to print a lot (part of the reason it shouldn't be used often)

 

why you can't close the client, I have no idea, it's only printing some extra stuff to file, nothing else

 

I will have a look at those locations

Share this post


Link to post
Share on other sites

Ideall, some system should be implemented not to print the same message over and over again, not only because it is annoying but also because it makes reading the log impossible (can't find a different message in the middle of a few GB of messages).

Share this post


Link to post
Share on other sites

okay, I'll add that (though it'll only be if it's the same message. if it's two that cycle between each other my simple code won't help it much)... should be in CVS in a few minutes

 

and I've removed those two OPENGL_TRACE entries, and ran both old and new client, not getting any OpenGL error reports in my error_log (which isn't to say it can't happen, just not with my client/drivers in the locations I'm at)

Share this post


Link to post
Share on other sites

okay, I'll add that (though it'll only be if it's the same message. if it's two that cycle between each other my simple code won't help it much)... should be in CVS in a few minutes

 

That should be good.

 

and I've removed those two OPENGL_TRACE entries, and ran both old and new client, not getting any OpenGL error reports in my error_log (which isn't to say it can't happen, just not with my client/drivers in the locations I'm at)

 

umm, how can you get those two errors if you removed the debug entries? :icon13:

Share this post


Link to post
Share on other sites
okay, I'll add that (though it'll only be if it's the same message. if it's two that cycle between each other my simple code won't help it much)... should be in CVS in a few minutes
That should be good.
now, I thought I had done this... turned out I had only added this to log_error() not log_error_detailed() (which is the one used in some of the -DDEBUG calls).

oh well, makes it even easier to add :)

I've also added timestamps while I was at it, since those can be handy (and were also already in log_error()

umm, how can you get those two errors if you removed the debug entries? :D
I removed those #ifdef CHECK_GL_ERRORS() calls, the rest of them are still there :icon13: Edited by ttlanhil

Share this post


Link to post
Share on other sites

Why did you remove them? If we know for sure we have some errors in that code, then it's good to let those calls there so that we can try various fixes and see if the problem persists or not.

Share this post


Link to post
Share on other sites
Why did you remove them? If we know for sure we have some errors in that code, then it's good to let those calls there so that we can try various fixes and see if the problem persists or not.
because it was invalid command, not some other message... invalid command was the result I got when checking OpenGL errors, for example, between a glBegin() and glEnd() call

if there really is an error in the code, well, the next check will pick it up, but I expect that it's just because I had the checks in functions that are called after some opengl states have been set already

Share this post


Link to post
Share on other sites

Ok, since we are not getting anywhere with this bug, I contacted Intel, see if they are willing to assign some engineer to work with us and help solve the problem..

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×