View Issue Details

IDProjectCategoryView StatusLast Update
0001855FSSCPOpenGLpublic2009-01-03 11:46
ReporterEchelon9 Assigned ToEchelon9  
PrioritynormalSeverityblockReproducibilityalways
Status resolvedResolutionfixed 
PlatformMacOSOS X 
Product Version3.6.9 
Fixed in Version3.6.10 
Summary0001855: Mac OS X OpenGL errors with vglUseProgramObjectARB(Current_shader->program_id)
DescriptionWhen using a 3.6.10 trunk build that supports GLSL shaders in the engine (post r4707), with a shaders.vp or equivalent, running fullscreen on Mac OS X ships and numerous other textures will appear fully white, and further effects like shadows, shine and environment mapping fail to work properly.

This is reliably reproducible on Leopard 10.5.x releases. It is currently unconfirmed whether Tiger (10.4.x) is likewise affected.

Curiously, when running in windowed mode (-window) GLSL appears to work fine, however performance is severely degraded as the OS chrome is still being rendered.
Steps To ReproduceEnsure:
- You are using Mac OS X
- A 3.6.10 trunk build with the GLSL shader feature is being used (post r4707)
- shaders.vp, sdr119.vp or 3.6.10 MediaVPs are present, and windowed mode is not enabled

Enter the Techroom or Ship Lab (F3) and textures should appear white.
TagsNo tags attached.

Activities

Echelon9

2008-12-26 08:24

developer   ~0010465

Last edited: 2008-12-27 03:01

It is believed that the OpenGL error INVALID_VALUE occurs when calling vglUseProgramObjectARB(Current_shader->program_id) within opengl_shader_set_current() in gropenglshader.cpp

See further: http://www.hard-light.net/forums/index.php/topic,58553.msg1183113.html#msg1183113

2008-12-26 08:29

 

identify-Current_shader-program_id-1855.txt (720 bytes)   
Index: code/graphics/gropenglshader.cpp
===================================================================
--- code/graphics/gropenglshader.cpp	(revision 5020)
+++ code/graphics/gropenglshader.cpp	(working copy)
@@ -228,7 +228,12 @@
 	Current_shader = shader_obj;
 
 	if (Current_shader != NULL) {
+		// Super debug
+		GL_CHECK_FOR_ERRORS("shader_set_current() - before vglUseProgramObjectARB()");
+		nprintf(("OpenGL", "OpenGL Current_shader->program_id: %d\n", Current_shader->program_id));
 		vglUseProgramObjectARB(Current_shader->program_id);
+		// Super debug
+		GL_CHECK_FOR_ERRORS("shader_set_current() - vglUseProgramObjectARB()");
 
 #ifndef NDEBUG
 		if ( opengl_check_for_errors("shader_set_current()") ) {

Echelon9

2008-12-26 08:32

developer   ~0010466

A patch (identify-Current_shader-program_id-1855.txt) against r5020 has been uploaded which outputs the Current_shader->program_id passed into vglUseProgramObjectARB() to the fs2_open.log when using a debug build.

You must have a debug_filter.cfg with +OpenGL in it to see the extended Current_shader->program_id value in your fs2_open.log

Tinman

2008-12-26 11:20

reporter   ~0010467

I can confirm running fullscreen on Mac OS X 10.4.11 (G5/Nvidia7800GT) ships and numerous other textures will appear fully white. Tested with 3.6.10-trunk rev5019 nightly build.
In windowed mode the textures are shown properly.

Echelon9

2008-12-26 12:01

developer   ~0010468

Tinman,

I've packaged up a new build with the attached Current_shader->program_id patch.

http://members.iinet.net.au/~tjkidd/fs2open/build/mac/FS2_Open%20r5020%20(debug)%20newtown.zip

Could you give the Newtown build a test (add +OpenGL to ~/Library/FS2_Open/data/debug_filter.cfg first). I'd like you to simply open FS2_Open fullscreen, go into the Techroom, and then exit.

When you've done that, zip up the fs2_open.log and attach here if you be so kind. This will help confirm or dispel a hunch, and get this problem fixed for us all. Let me know if you have any questison.

2008-12-26 13:34

 

fs2_open.log.zip (92,386 bytes)

Tinman

2008-12-26 13:38

reporter   ~0010469

Ok, I here's the requested log. As far as I can see it worked. I had to create a "debug_filter.cfg" but I think I did this right.
Just for info: I had "-mod mediavps" active, cos the shaders are in the mediavp, but you will see this in the log anyway.

Echelon9

2008-12-26 13:52

developer   ~0010470

Tinman,

Just to confirm, you definitely used the 'newtown' build I linked to? The way you created debug_filter.cfg all looks fine, but there's a few other things I wasn't expecting in the log.

Tinman

2008-12-26 14:19

reporter   ~0010471

Last edited: 2008-12-26 14:20

Yes. I used "FS2_Open r5020 (debug) newtown". There's a second one added. HTH.

2008-12-26 14:20

 

fs2_open.log2.zip (90,425 bytes)

Echelon9

2008-12-26 14:45

developer   ~0010472

Ah yes, the second fs2_open.log has what I need. Much appreciated.

You will see in your log that a search for the text "Current_shader->program_id" will be followed by a number highlighting the respective shader being acted upon by the GLSL code.

Echelon9

2008-12-27 08:59

developer   ~0010474

A fix may have been found, more to follow.

Echelon9

2008-12-27 12:20

developer   ~0010475

http://www.hard-light.net/forums/index.php/topic,60044.0.html

Tinman

2008-12-31 14:49

reporter   ~0010496

Last edited: 2008-12-31 16:30

just played around on the F3 screen

I do not know if it is helpful, but i have 4 fps with the Ulysses and when I turn on "fixed render pipeline" in the render options the fps jump to 60 (which is the limit by vsync) and the cpu load is considerable lower than with "fixed render pipeline" disabled.

I have not the least inkling what "fixed render pipeline" is, though.

edit:

I use the mv_complete.vp of the 3610mediavps, usually.

All comments are for the Ulysses LOD 0 windowed (wim) mode and fullscreen (fsc) mode:

the shaders in mv_complete.vp show 4fps in F3 screen with MacOS 10.5.6 all the time with no change.

the 1119 shaders show 7-8fps in F3 screen with MacOS 10.5.6 for about 40-60s , CPU load both cores 100%
               then the fps rises from 7 to 30fps(wim)/43fps(fsc), the cpu load is then decreasing to 80% for both CPUs
               then after about 20s the fps rises to 60, cpu load is then decreasing to 40-50% for both CPUs
               (this is showing again after leaving and reentering F3-screen)

the mv_complete.vp shaders show 60fps in F3 screen with MacOS 10.4.11 immediately
the 1119 shaders show 60fps in F3 screen with MacOS 10.4.11 immediately

Echelon9

2009-01-03 11:45

developer   ~0010501

Fixed as of r5028.

Issue History

Date Modified Username Field Change
2008-12-26 08:20 Echelon9 New Issue
2008-12-26 08:24 Echelon9 Note Added: 0010465
2008-12-26 08:29 Echelon9 File Added: identify-Current_shader-program_id-1855.txt
2008-12-26 08:32 Echelon9 Note Added: 0010466
2008-12-26 11:20 Tinman Note Added: 0010467
2008-12-26 12:01 Echelon9 Note Added: 0010468
2008-12-26 13:34 Tinman File Added: fs2_open.log.zip
2008-12-26 13:38 Tinman Note Added: 0010469
2008-12-26 13:52 Echelon9 Note Added: 0010470
2008-12-26 14:19 Tinman Note Added: 0010471
2008-12-26 14:20 Tinman File Added: fs2_open.log2.zip
2008-12-26 14:20 Tinman Note Edited: 0010471
2008-12-26 14:45 Echelon9 Note Added: 0010472
2008-12-27 03:01 Echelon9 Note Edited: 0010465
2008-12-27 08:59 Echelon9 Note Added: 0010474
2008-12-27 12:20 Echelon9 Note Added: 0010475
2008-12-27 15:12 Echelon9 Status new => assigned
2008-12-27 15:12 Echelon9 Assigned To => Echelon9
2008-12-31 14:49 Tinman Note Added: 0010496
2008-12-31 14:55 Tinman Note Edited: 0010496
2008-12-31 16:30 Tinman Note Edited: 0010496
2009-01-03 11:45 Echelon9 Note Added: 0010501
2009-01-03 11:46 Echelon9 Status assigned => resolved
2009-01-03 11:46 Echelon9 Fixed in Version => 3.6.10
2009-01-03 11:46 Echelon9 Resolution open => fixed