Bernhard Wymann wrote:
Hi allThat's really odd. There's an important difference in the edited
I'm a developer of the TORCS (The Open Racing Car Simulatior) project, look at www.torcs.org. A user reported that the initialization of TORCS 1.2.2 fails with his Matrox g550. I post here
because I was not able to figure out the problem, I do not have access to such a card. You can find the original thread at: http://news.gmane.org/gmane.games.torcs.general/cutoff=226
My question: Is the initialization of TORCS wrong or is it a bug in GLX/DRI?
First I had a look at his glxinfo output (shortened, full version at the end of the post) and checked if there is a match with the video modes we probe in TORCS (/src/libs/tgfclient/screen.cpp, look at it here http://cvs.sourceforge.net/viewcvs.py/torcs/torcs/torcs/src/libs/tgfclient/screen.cpp?rev=1.10&view=auto
):
direct rendering: Yes OpenGL renderer string: Mesa DRI G400 20020221 AGP 1x x86/MMX/3DNow!/SSE OpenGL version string: 1.2 Mesa 4.0.4
visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id
dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat ----------------------------------------------------------------------
0x25 24 tc 1 24 0 r y . 8 8 8 0 0 24 8 0 0 0 0 0 0 None 0x29 24 tc 1 24 0 r y . 8 8 8 0 0 24 8 16 16 16 0 0 0 Slow 0x2d 24 dc 1 24 0 r y . 8 8 8 0 0 24 8 0 0 0 0 0
0 None 0x31 24 dc 1 24 0 r y . 8 8 8 0 0 24 8 16 16 16 0 0
0 Slow
These 4 modes have RGB, double buffering and a 24 bit depth buffer, at least the report claims that. So the following code from screen.cpp should (but it does not) pick up one of the above modes.
... if (!glutGet(GLUT_DISPLAY_MODE_POSSIBLE)) { // Failed, try without antialiasing and alpha support. visualDepthBits = 24; visualSupportsMultisample = false; visualSupportsAlpha = false; glutInitDisplayString("rgb double depth>=24"); } ... if (!glutGet(GLUT_DISPLAY_MODE_POSSIBLE)) { // All failed. printf("The minimum display requirements are not fulfilled.\n"); printf("We need a double buffered RGBA visual with a 16 bit depth buffer at least.\n"); } else { ...
We modified the code then to get a visual in the failure path:
... if (!glutGet(GLUT_DISPLAY_MODE_POSSIBLE)) { // All failed. printf("The minimum display requirements are not fulfilled.\n"); printf("We need a double buffered RGBA visual with a 16 bit depth buffer at least.\n"); glutInitDisplayMode(GLUT_RGB | GLUT_DOUBLE | GLUT_DEPTH); } else { ...
This did not work either, he got no visual. So I let him comment out the whole initialization with the glutInitDisplayString and put instead just the glutInitDisplayMode(GLUT_RGB | GLUT_DOUBLE | GLUT_DEPTH); in the code (you can find the file in the above mentioned thread). Now, that worked, very strange...
screen.cpp as far as I can see however, it doesn't check for the
GLUT_DISPLAY_MODE_POSSIBLE state as it did before. I guess it shouldn't
matter, as it should just fail later if the check isn't done, but you
never know...
The GLX visual matching code is pretty much driver-independant, so it's
odd this would only be a problem with the mga driver. That said, there
were some changes in that area since XFree86 4.3, but I don't think the
visual matching code was broken in a way which could have caused this bug - it would be helpful if the OP could test this with a newer XFree86 version. Unfortunately though I believe the dri snapshots (both driver and the (needed) XFree server from the extras directory) do not include the changed glx stuff.
By the way, we need the complicated initialization to get a 24 bit depth buffer and the best fitting visual on some cards (if you use GLUT_DOUBLE with glutInitDisplayMode you get often just a 16 bit depth buffer even if 24 bits are possible).
If you'd use glutInitDisplayString with depth>=16 you _should_ get a 24bit depth buffer if available though, at least in theory - if not that would be a bug in glut or the glx visual matching code.
Questions: 1. Is the code in screen.cpp ok, should it match with an available mode (I think yes...), if not, what do I get wrong?Looks to me also like it should - though I'm not really competent in that area...
2. Is GLX somehow puzzled because of the glut probing (the standalone glutInitDisplayMode works, the glutInitDisplayMode as "last resort" does not)?
If you want to test it start TORCS with -s to disable multitexturing.
That's also something which shouldn't be necessary, the G400/G450/G550 should work AFAIK just fine with multitexturing.
Also, the OP is using the drivers from matrox, he should try the "normal" drivers. If this bug is only in the matrox version of the driver (I don't think it is, but it might be possible), then there's little the dri developers could do to help.
Thank you, bye, Bernhard.
Bye, Roland
The Original Report: --------------------
hello, i compiled torcs 1.2.2 on my system (mdk 9.2). after i run the game i get:
tuxracer is working like a charm.
output of glxinfo:
name of display: :0.0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context client glx vendor string: SGI client glx version string: 1.2 client glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context GLX extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context OpenGL vendor string: VA Linux Systems Inc. OpenGL renderer string: Mesa DRI G400 20020221 AGP 1x x86/MMX/3DNow!/SSE OpenGL version string: 1.2 Mesa 4.0.4 OpenGL extensions: GL_ARB_multisample, GL_ARB_multitexture, GL_ARB_texture_compression, GL_ARB_texture_env_add, GL_ARB_transpose_matrix, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_clip_volume_hint, GL_EXT_compiled_vertex_array, GL_EXT_packed_pixels, GL_EXT_polygon_offset, GL_EXT_rescale_normal, GL_EXT_texture3D, GL_EXT_texture_env_add, GL_EXT_texture_object, GL_EXT_vertex_array, GL_IBM_rasterpos_clip, GL_MESA_window_pos, GL_NV_texgen_reflection, GL_SGIS_generate_mipmap glu version: 1.3 glu
extensions: GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess
visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id
dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat ----------------------------------------------------------------------
0x23 24 tc 1 24 0 r y . 8 8 8 0 0 0 0 0 0 0 0 0 0 None 0x24 24 tc 1 24 0 r . . 8 8 8 0 0 0 0 0 0 0 0 0 0 None 0x25 24 tc 1 24 0 r y . 8 8 8 0 0 24 8 0 0 0 0 0
0 None 0x26 24 tc 1 24 0 r . . 8 8 8 0 0 24 8 0 0 0 0 0
0 None 0x27 24 tc 1 24 0 r y . 8 8 8 0 0 0 0 16 16 16 0 0
0 Slow 0x28 24 tc 1 24 0 r . . 8 8 8 0 0 0 0 16 16 16 0 0
0 Slow 0x29 24 tc 1 24 0 r y . 8 8 8 0 0 24 8 16 16 16 0 0
0 Slow 0x2a 24 tc 1 24 0 r . . 8 8 8 0 0 24 8 16 16 16 0 0
0 Slow 0x2b 24 dc 1 24 0 r y . 8 8 8 0 0 0 0 0 0 0 0 0
0 None 0x2c 24 dc 1 24 0 r . . 8 8 8 0 0 0 0 0 0 0 0 0
0 None 0x2d 24 dc 1 24 0 r y . 8 8 8 0 0 24 8 0 0 0 0 0
0 None 0x2e 24 dc 1 24 0 r . . 8 8 8 0 0 24 8 0 0 0 0 0
0 None 0x2f 24 dc 1 24 0 r y . 8 8 8 0 0 0 0 16 16 16 0 0
0 Slow 0x30 24 dc 1 24 0 r . . 8 8 8 0 0 0 0 16 16 16 0 0
0 Slow 0x31 24 dc 1 24 0 r y . 8 8 8 0 0 24 8 16 16 16 0 0
0 Slow 0x32 24 dc 1 24 0 r . . 8 8 8 0 0 24 8 16 16 16 0 0
0 Slow
------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
