Page 2 of 3

Posted: Sun May 23, 2010 5:57 pm
by slavik262
Given modern processors, or even older ones that some Irrlicht projects target, I wouldn't worry very much about the overhead from context switching in threads. Besides, it's been agreed that it should be an option, not a requirement, to use threads.

Posted: Sun May 23, 2010 6:06 pm
by 3DModelerMan
It would be fine if it was just made thread SAFE so that we could use multiple threads in most areas. I wouldn't really care if the threading support was built in, we could just use OpenMP to create the threads.

Posted: Sun May 23, 2010 6:25 pm
by hybrid
First, thread safe requires a lot of extra work, and second it's usually thread technique specific how to rule out common access to a shared variable etc. Hence we need to identify those places where mutual exclusion is almost automatically guaranteed, or where reentrancy is enough for safe work.

Posted: Sun May 23, 2010 7:33 pm
by DtD
Dorth wrote:bitplane, I have to disagree with point 1. Do you avoid deving on DirectX because it can't be used on most platforms?
Bitplane isn't saying we shouldn't do threading at all, he just says it should be optional. Threading is a powerful feature, but it isn't for everyone. DirectX can be more powerful than OpenGL, and some people might prefer it. But there are others that would rather have OpenGL.

Posted: Mon May 24, 2010 6:15 am
by Dorth
This is quite a reasonable assumption, which I hadn't thought about when I answered him first. HOWEVER. I am most certain he is more than capable to clarify, if need be, his own posts, especially since you have no authority nor proof to do it in his stead. So please defend your own posts and leave other posts alone, thanks.

Posted: Mon May 24, 2010 10:42 am
by hybrid
Since you're also running here without the official "Admin" tag maybe you should also keep within your own range. Just keep posts on the technical level, and reduce advices about etiquette to the absolute necessary. This is, btw, a good advice for all here. Please don't get into off-topic this soon. This is not IRC, we cannot ignore posts that easily.

Posted: Mon May 24, 2010 8:31 pm
by DtD
Sorry, that post was worded poorly. I was just saying what my interpretation was and was stating it because I support the optionality of the threading.

Anyway! Back on topic!

Also, I think threading would give us a nice advantage over Ogre, I don't believe it has threading :D

Posted: Mon May 24, 2010 9:23 pm
by hybrid
Of course it has :roll:

Posted: Mon May 24, 2010 9:40 pm
by DtD
It does? Well...they probably did it worse than we will :P all the more reason to add it!

Posted: Wed May 26, 2010 8:32 am
by zet.dp.ua
Threading support requires more complicated logic. The first question everyone has to answer is "For what do I need threading?", the second - "How others do the same?".

In general game engine definitely must support threading. At least e.g. CThread class with 'virtual int Run(void* param) = 0;' function and mutex class + optionally CThreadsStorage class.

But as for the usage of threads... (The more fps - the better + no lags at all) == our goals as programmers.
Assets loading, sounds streaming, level generating and solving - here we can effectively use threads to minimize update lags.
It is not necessary to make video driver multithreaded only because of texture loading. Texture creation from raw data is really fast and we only have to make smth like queue in the rendering thread.
Separating update and rendering in the different threads can increase fps...theoretically. Synchronization in this case is _really_ complicated.

And don't forget that mobile devices have only 1 core for now, so the less threads the better.

Posted: Wed May 26, 2010 8:48 am
by BlindSide
Most of the time Irrlicht applications can make use of threading without any issues on the logic side. For example you can run physics in a separate thread and that's more than enough concurrency for most games.

I suppose for some things like streamed loading then threading support directly inside Irrlicht would be desirable but until I actually see people making an effort to use threading application-side I'm not that motivated about integrating it.

Half of those things you mentioned zet (Sound, generating) don't require direct threads in Irrlicht. Infact it's possible right now to generate an octtree scene node for the level using threads and Irrlicht without much problems if you are careful with some things (I tried it a while ago).

Posted: Thu May 27, 2010 2:09 pm
by zet.dp.ua
My opinion is just to add thread-related classes. And user (game programmer) have to decide to use or not to use them.
I can't say that irrlicht requires direct threads inside. Where that threads can be used? I can't see. (I don't take into account the possibility of "for"-like cycles parallelization using openmp.)

Of course the game can use only one main thread, but the modern desktop computers have >= 2 cores, why don't use it?

P.S.: In the irrlicht's core message collecting proc can be separated in the another thread under Windows to avoid blocking in some situations. But it is really not a problem.

multiple GPU

Posted: Sun Jun 20, 2010 2:17 am
by Dareltibus
thinked about some computers have more than one graphics card?

dividing the work on two graphics card is done by drivers or programmer can use that to improve multy thread performance?


another thing.

.. in wich way the separate thread will comunicate between them ?
(providing safe data structures maybe is a good idea)

for example a integer table in wich store the work of one thread and load from another thread..

a thing i think it is A MUST moving on another thread (better another CPU)
is sorting. Especially when sorting a lot of thing such the leaves of a forest..

i now thatin opengl before drawing blended fragments you must sort them from farest to nearest. it is possibile do that just pass the array of sorted index to the graphics thread ecc.


Provide the way to easily let the programmer move all IA and collision calculation to separate thread and so on..

wich interface?

a calback system of functions in wich every one can put what hi want to do in another thread..

call back function can access to wich variables? i think callback is very intuitive.. (or overriding a method of a class.. is the same thing at the end, but this class has some private member and thread safe function returning their values, single values or array.)

the thread class will have overidables method.. so an example of a thread class for general purpose (so where users can put what they want, IA computing collisions etc.):

Code: Select all

class Ithread{
private:
     f32 *f32array;
     bool loadingrequest;

     void BreakIfLoading(); // a loop that wait extern users of the
                                      //  thread doing their loading of data
 
protected:

    virtual Ithread{

        using = false;
        loading = false;
        saving = false;
        f32array=new f32[size]; //or better an array datastruct

    }

    virtual void IdleThreadFunction{

        //no new variables declaration

        //put here the thread safe code
        // this function will be called periodically in the thread 
        // like a cycle.
        // makin calculations    
  
    }

    virtual void SavingThreadFunction{

        //when called (if is possibile write in data wich is not loaded
        // by some different thread)
        // this function wait for data is writable
        //so we can save the result of idle function calculation

        //we can also add the chance to break saving and continue later
        //if we are saving a lot of data

        // like this
        BreakIfLoading();

    }

public:

    void RequestLoading{

        //with this function you ask to load 
        //in this way you can let the thread know
        //that soon you will load data he is keeping

    }

bool LoadingPossible{
   //if is possible read data
}

virtual void Loadingfunction{
    //read data from thread calculation
    //not sure about return type or ByRef arguments
    // maybe a floating point array.
}

void WaitForload{
   //explicitly wait the end of saving in this thread
   //for loading in the thread using the data it needs
}

void LoadingEnd{
   //let the thread know he can start save data again
}

}
so a program using that thread.

Code: Select all

int main{

    while(device->Run()){

        //doing something

        thread.RequestLoading();

        //doing something else

        if(thread.LoadingPossible)
            thread.LoadingFunction();
        else{
            thread.WaitForLoad();
            thread.LoadingFunction();  
        }

        //doing something else or save/load into the thread more
        //than one time

        thread.LoadingEnd();
    }
}

you can add some function to check if a computer has more than one CPU, and give the chance to run thread on separate CPUs, on the same CPU or calling their idle methos as normal procedural routines

Code: Select all

//init code
if(CPU->has1Core)
    Ithread thread1(single);
else{
    Ithread thread1(multy);
    thread1->moveTo(2);//if we don't have 1 cpu we have at least 2 cpu
                                    //ok i know that normally the OS handles 
                                    //threads but this is just an example
}


//doing something

if(thread1->GetMode == single)
    thread1.Calculate(2) //run 2 times the idle function
    thread1.ForceSave() //then save result
else{
   thread1.RequestLoading();
   //calling thread1.Calculate if we are in multy mode will return exception
}

        //doing something else

        if(thread.LoadingPossible)
            thread.LoadingFunction();
        else{
            thread.WaitForLoad();
            thread.LoadingFunction();  
        }



. giving the chance to enable multythreading for example for moving the fast-sorting feature to the 2nd CPU. (better than nothing the fps will increase anyway)

others possible things


to giving the thread time to calculate without having main thread to wait them is possible breaking the drawing functions into 2 or more slices

Code: Select all


//request loading

 smgr->drawAllOne();

//loading from thread 
//let thread now the load is end

smgr->drawAllTwo();

//check for loading the thread that was in late after DrawAllOne

smgr->drawAllThree();

//finally if some thread is still lating wait it, maybe giving him more priority

//set his priority to normal

driver->endScene();

//update with new values

i hope there is something usefull or some good idea to use. sorry for grammar but i am almost falling to sleep. ;-)

Posted: Sun Jun 20, 2010 4:07 am
by BlindSide
thinked about some computers have more than one graphics card?
Irrlicht very recently got the feature to choose the graphics adapter in the device creation options, so you can create several devices each running on a different card.

I somewhat like your idea, Dareltibus. I suppose it would be nice to have something similar to Java's Swing concurrency helpers that would help users defer datauploading to the GPU only when it's "safe" to do so. But since this is already somewhat possible to do without having to modify Irrlicht, my priorities are on other things at the moment.

Posted: Wed Jun 23, 2010 1:03 am
by Insomniacp
something we could look into is C++0X std library which will have a standard for threading and should have a way to make data multi-thread safe relatively easily. I have a lecture on it tomorrow at Fermilab so I will post some more information on it tomorrow night. Yes I know the library isn't released yet but some compilers have already implemented the experimental versions of it (G++ 4.5 i think and visual studios 10?).