From: Andrew J. R. <and...@uc...> - 2001-08-24 10:50:05
|
> >My thoughts on parrallellising openGL. > > > >A client is a game or other 3D app. There are 3 distinct situations. > >The computational effort in getting ONE frame onto the screen is the > >sum of > >the client ,C, and the renderer(openGL) ,G. > > > >1) > > > > |============================| |======| > > > > C G > >2) > > > > |=======| |============================| > > > > C G > >3) > > > > |==================| |=================| > > > > C G > > > >Situation 1: then best we can do is put G in another thread (other > >CPU) as > >unless C is multithreaded C has todo the work on one CPU. > > > >Situation 2: the best we can do is G in one thread and C in another > >and when > >C completes (before G) the C thread helps out G (load balancing). > > > >Situation 3: C in one thread G in another. > > 1. OpenGL has to set glError after each operation ! > 2. Good OpenGL api precache everything, in resonable part just till > glFlush() is called; 3. We cannot put everything to just another thread, > LoadBalancing and Parallel execution means that few (depends on number of > CPUs) are doing something, and work on calculations toughether > (supplementary execution). > 4. Another api on OpenGL ???? we have few now.... (see pt.1 ); > The goal is to fe calculate tables (for next poligon, object, etc.) , > while another thread is drawing stuff (calculated) AND CALCULATES WHAT HE > NEEDS NOW (parallel !!!!!). We need to talk about this stuff more, to even > start to write it. > OK, but it doesn't matter that glError gets set every api call, if the client polls the error condition then we sync the client the rendering threads and do the call (as if there were no multithreading). Another thing that this design only addresses senario 3 (but as I said theres not much you can do with senario 1 either; apart from putting the renderer in another thread). The sencond stage of the implementation is to enable the vertex transformation stuff (t_pipeline.c calls all these stages) to be done in parralell if required, Ive done a bit of this already and it seems to scale very well, getting 1.8 or better scaling on 2 CPU's, this IS inside Mesa (of course). The idea is that the client thread stuffs openGL commands into the shared area and the rendering thread takes them out (the two are synced when neccecary). If the client is waiting for the rendering thread to complete after a sync then it will try to help out the rendering thread by interfacing with the parrallell vertex transformation code. This also means that syncing should occur at least once a frame (glFlush). But the first bite (or is that byte:) ) I think is to get the cheap and cheerful client thread->render thread working. Once that works one can start to think about doing more syphiticated stuff, like specifying how arguements are apssed over to the renderer or whether glError always returns true (or false), hence not requiring a sync. Now before Brian says "hey now lads thats REALLY damgerous" I know! but one can taylor the return vals to the application, a performance tune if you like (the basic structure will always work properly though). At its most basic its just a wrapper, that makes the client think that its using a very fast openGL renderer. Andy |