NewsForumsCodeLogsGallerySpecsSearch

Using the Mac OS Multithreaded Engine

BlitzMax Forums/OpenGL Module/Using the Mac OS Multithreaded Engine

Michael Larson(Posted 2007) [#1]
If you want to enable the multithreaded engine on Mac OS 10.4.9 update the glgraphics.mod.m file to this

static void _validateContext( BBGLContext *context ){
int flags;
NSOpenGLContext *shared;
NSOpenGLContext *glContext;
NSOpenGLPixelFormat *glFormat;
CGLPixelFormatAttribute attrs[16];

if( !context || context->glContext ) return;

flags=context->flags;
shared=_sharedContext();

switch( context->mode ){
case MODE_DISPLAY:
flags|=FLAGS_FULLSCREEN;
break;
}

_initAttrs( attrs,flags );

glFormat=[[NSOpenGLPixelFormat alloc] initWithAttributes:attrs];
glContext=[[NSOpenGLContext alloc] initWithFormat:glFormat shareContext:shared];
[glFormat release];

if( !glContext ) bbExThrowCString( "Unable to create GL Context" );

// Here...
CGLEnable([glContext CGLContextObj], kCGLCEMPEngine);

switch( context->mode ){
case MODE_WIDGET:
[glContext setView:context->view];
break;
case MODE_WINDOW:
[glContext setView:[context->window contentView]];
break;
case MODE_DISPLAY:
[glContext setFullScreen];
break;
}

context->glContext=glContext;
}

And rebuild the glgraphics mod

It makes the graphics noticably faster and if you do a shark trace all the GL calls are out of the trace.

I haven't seen any issues.

Good Luck!

Mike Larson
Apple OpenGL Group


Brucey(Posted 2007) [#2]
This is very cool.

Would be nice as an official modification !! :-)

Any thoughts, Mr Sibly?

Perhaps for backwards compatibility the code can be #ifdef'd ?


hec(Posted 2007) [#3]
Speaking of multithreading and blitzmax.... WHEN? :)


ImaginaryHuman(Posted 2007) [#4]
What exactly is this and how does it benefit people?

(my guess is, it enable some kind of multi-threaded activity in the driver, to process OpenGl commands faster?)


Brucey(Posted 2007) [#5]
This technote explains things quite well :

http://developer.apple.com/technotes/tn2006/tn2085.html

It's only useful for Intel Macs, but imho it doesn't hurt adding it.


ImaginaryHuman(Posted 2007) [#6]
I cannot get this to compile. I pasted it over the existing _validatecontext code within glgraphics.mod/glgraphics.macos.m and tried to build modules but the compiler complains that the first line of the sourcecode is invalid at the #include.

Compile Error
2: error: invalid preprocessing directive #Include


Michael Larson(Posted 2007) [#7]
Intel macs for 10.4.8 and up, it will be universal for 10.5 (Leopard).

It disconnects the gl interface at a very high level in the API stack which allows most of the gl stack to run on a separate thread (dual core CPU's..). It's an opt in feature that developers have to enable.

The compile worked fine for me, I may have missed a #include of CGLTypes.h but I believe that is included in the framework regardless.


ImaginaryHuman(Posted 2007) [#8]
I am on an intel mac with 10.4.10. It's not that it didn't work on the machine, it's that it wont build in blitzmax.

You just took the code and overwrote the existing validatecontext section, right, down to the } ???

I don't know why, after making that change and saving it and building, the builder says that the first line of the whole file is wrong at the #include.

I am doing this with the glgraphics.mod/glgraphics.macos.m file, is that right?


Brucey(Posted 2007) [#9]
@AngelDaniel

Does the module compile okay without the change? (apple-D to build modules)

The only bit that you actually need is :
// Here...
CGLEnable([glContext CGLContextObj], kCGLCEMPEngine);


Adding this (in the appropriate place), it compiles fine on my (PPC) Powerbook - although I know it's not going to do anything here...

I'd be interested to know what kind of difference it makes (in terms of FPS) to a basic Max example...


Michael Larson(Posted 2007) [#10]
Shark shows it is spending more time in application than GL, GridWars shows about a 2x difference in the time spent in draw with this enabled so my impression is it is doing it's job on the other thread.

Your right the code following // Here.. is the only thing you need to enable this.

It would be nice to implement more threading support in Blitz, with 4 processor cores and 8 - 16 processor cores on the way it will become more important.


ImaginaryHuman(Posted 2007) [#11]
I inserted only that one line into the exact place suggested and saved the file. Built modules, and it still comes up saying: "Compile Error 2: error: invalid preprocessing directive #Include", and points to the first line of the .m file. Also it looks as though in the debug window it has LOTS of errors compiling, almost as if it thinks perhaps the sourcecode is a blitzmax source not an objective c source? I did not append anything to the filename. I tried editing the source using a text editor also and that did nothing different.

I get all these errors:



Michael Larson(Posted 2007) [#12]
Here are the first few lines of my glgraphics.macos.m

<extra line here... if that helps>

#include <AppKit/AppKit.h>
#include <OpenGL/gl.h>
#include <OpenGL/OpenGL.h>
#include <OpenGL/CGLTypes.h>

#include <brl.mod/system.mod/system.h>

It works for me. Your prior post says 10.4.10 so your good for the enum... hmm


Brucey(Posted 2007) [#13]
Include with an uppercase "I" ? Sounds like, for whatever reason, your .m file has been reformatted by the IDE.

If, in the editor, the word Include is highlighted, you are going to have problems. Rather edit the file in a different text editor, since it sounds like your editor assumes .m files are the same as .bmx - formatting them at load time.


ImaginaryHuman(Posted 2007) [#14]
I tried editing in TextEdit already and saved as plain text with same extension and no other changes to the file, it still has the same errors.


ImaginaryHuman(Posted 2007) [#15]
Well... I got it to work. I think that because I'd originally tried to make the modification by loading the original file into BlitzMax and editing it there, and then saving it, BlitzMax had changed the case on a lot of things and tokenized what it recognized as BlitzMax commands, which really are Objective C commands. Then when it failed to work and I tried to change the same file in a text editor, it still didn't work because it was still using the file that BlitzMax had tokenized and modified. Hence all the errors.

So I started afresh, never went into BlitzMax, edited the file in a text editor outside of BlitzMax and saved it from there - no tokenizing, no other changes, fresh file. Upon going back into Blitz it compiled first time! :-)))

So anyway.... I was hoping to see a speedup. However, I ran the bird flying demo from MiniB3D with Flip 0, and it did not seem to gain even ANY frames per second. Tried also the cubemax example and it was no faster. Maybe these demos aren't doing enough GL instructions to make a difference, as after all its largely the time spent in the GL library on top of the GPU that is affected, right?

So anyway, good to know it technically works, but will need to see a more conclusive example of the speed difference.

Thanks for all your help trying to figure this out.


ImaginaryHuman(Posted 2007) [#16]
I tested the modification with my blobby objects which have a larger number of GL calls and showed no changes in the framerate. Any ideas why?


Michael Larson(Posted 2007) [#17]
I did my testing on GridWars and that is all immediate mode stuff so there was a benefit there. But we know that most applications have to rig up against OpenGL Profiler to determine where they are causing a stall at. The standard stuff comes to mind glFinish / glFlush etc. But profiler should show this, also look at shark traces it will show where your spending cpu time at. In the gridwars source it was obvious, we are running that in 1920x1200 resolution and the numbers pop right out.


Michael Larson(Posted 2007) [#18]
What sort of mac / video card are you running?


ImaginaryHuman(Posted 2007) [#19]
Imac Intel Core 2 Duo 2.0 GHz, 1GB Ram, OpenGL 2.0, ATI X1600 Mobility graphics card (about 2 billion texels/sec), Shader Model 3 (in PC terms) (vista compatible).