I was wondering how feasible it is to have OpenGL run as a seperate application (so it runs in a seperate thread). I am intersted in this because I have a Mac Mini Core Duo with and intel GMA950 chipset. When playing an advanced game it only uses one processor at 100% usage. The drivers do the Transform & Lighting in software, so I though if OpenGL itself is in another thread the driver will also be in another thread. I already had an idea to achieve this, but I am unexperienced on the Windows Platform, so I would like some feedback on how realistic this is. (I am especially interested in OpenGL for windows (by using BootCamp on the Mac)).
Currently the topology of an application is:
Application.exe
->
OpenGL32.dll
I want to change it to
Application.exe
->
OpenGL32.dll (impostor dll)
<=>
SeperateApplication
->
OpenGL32.dll (the official dll)
It works by replacing the real OpenGL32 dynamicly linked lib by a intermediate imposter DLL. This imposter DLL sends all the OpenGL routine calls and their arguments to a child application. The child application then buffers all those routine calls. The child application will now instead talk directly to OpenGL. Under ideal circumstances this can give a performance boost if you set that the original application and the child application run on seperate processors.
Challenges:
[li]Is it best to hide the existing OpenGL32.dll and replace it by the imposter DLL or do we hack into the application to which we want to add multithreading and replace all links to the new library. This has as an advantage that we don’t have to deal with multiple applications calling the OpenGL library.[]How can we let a DLL communicate with an application[]Is there a way to measure how much time is spent in OpenGL and in the drivers to see if there might be a performance gain in the first place.[]Will the overhead of datatransfers be small enough.[]Do functions that require a return value pose a problem.
I do have a general idea of what the general construction of the project should be. For example: all the routine-redirect-functions can just be generated by writing a small application that creates source.c files from the OpenGL header files.
I would like to hear from anyone who has a good suggestion.
I would like to hear from anyone who has a good suggestion.
I suggest that you avoid this route and buy yourself better card or even computer if your Mac does not support change of graphics card. This will get you almost guaranteed faster gameplay much faster and easily than what you attempt to do.
Any variant with two processes will be almost certainly significantly slower than what you currently have, especially with simple wrapper you suggested because of price of memory copy and process switch. Additionaly there will be significant issues with interaction between original application and this new application.
Theoretically you may create a additional thread in the original application and use that thread to call the OGL functions asynchronously however there are many issues with that approach and interaction of rest of the application like OGL context handling, window handling, memory copies, ensuring that reads from OGL are done in correct order with other operation. Also the wrapper would be more complicated that simple automatically generated code because it would have to know what each function does to ensure that everything is done correctly.
I forgot to add that OpenGL is build up for ussage as a terminal-mainframe interface. Maybe the thing I am suggesting already exists. In the form of a terminal debug interface or something?
Komat: thanks for the suggestion. Memory copy is indeed a big overhead which very well make it an even slower solution. I am not necessarily interested in playing advanced games. I am just curious in the concept and if it makes sense a lot of people with dual processors, but with sub-par graphics cards would be happy. I know that the multi threaded drivers of Ati and nVidia only deliver a mere 10% performance boost. Though slow graphics cards might benefit more.
PS: inconvenient that I can’t edit my own message.
On windows, the OpenGL and DirectX drivers from ATI and nVidia are already multithreaded. They get about a thirty percent speed improvement on certain games and apps. Yes, there is the cost of copying data twice but that is offset by having the state validation run on a separate core. I am not sure if they have to app detect in order to enable this optimization in the driver but depending upon the game and system and resolution, one can get up to a 30% speedup. For your situation, I’d say having a separate render thread would be much preferred to a separate app. The biggest speed boost would come from the fact that TCL and state validation, are now performed on the second core whereas now it has to be performed in the same thread as your single threaded app.