Another suggestion: "IVideoDriver::setBeginSceneOptions"

[hendu]

Well, swrast would also give that. llvmpipe might not, as AVX might round differently than SSE, etc.

[sunnystormy]

@CuteAlien, Hendu, Mel

So, given my circumstance where I need to do a 3D demo using software rendering on this new chip, are you saying I should just rely on Mesa's LLVMpipe to handle the rendering? Wouldn't that indirection compromise the speed of the rendering, though?

Irrlicht->GLVideoDriver->MesaAPI->LLVMpipe->DRI->Driver->Hardware

Irrlicht->SoftwareVideoDriver->DRI->Driver->Hardware

What are your thoughts?

[CuteAlien]

If software driver works good enough for your case I see no reason not to use it. You get very different results with Mesa I think, so depends on the demo. If you use software driver then use Burnings - not the other one (that is bascially just for 2d).

I don't dare guessing which solution would be faster/better. Depends on scene and features used etc...

[hendu]

Irr's sw drivers don't support most features at all, so if your demo uses those, you have no choice.

If you draw more than a few triangles, llvmpipe should be faster anyway, because of multithreading and optimized code.

BTW since you want software, DRI and hw drivers are not involved.
Irrlicht->GLVideoDriver->MesaAPI->LLVMpipe->screen
Irrlicht->SoftwareVideoDriver->screen

[REDDemon]

Irrlicht doesn't have to be thread safe, but there is nothing against building a multithreaded video driver behind You can defer the whole rendering process to the end scene method, and treat each drawing command as just a job submission that returns immediately, even such approach would be a way to create a sort of "thread-safe" irrlicht?.

Yeah that should be good, however there's one detail I had to work around when I was trying to do the same thing in my custom renderer:

- You should make uniform updates consistent.

Basically that means that if we send some data to the GPU (be it the transform Matrix for a model), we have to do that in the proper way, otherwise the objects will move around in a bad way (something like stuttering). The reasonable way to do that would be interpolate that data inside the video driver. The problem is that not everything can be interpolated. (we can interpolate Quaternions, Colors, Vectors, but not matrices: well unless the matrices are pure Scale or pure Translation, unless of course you extract Matrix components, interpolate components and rebuild the Matrix, a bit more expensive than really needed).

If you expose an API where you expose only interpolable values and you build non-interpolable values on the other thread that's ok, but I fear that would be a API break. (basically we should add a threaded Tween engine just for that, and possibly some breaking change in ISceneNode).

The stuttering is caused by the following

Assumes main thread finish updating when the rendering thread just has started to render next frame, the updated values will not be used for a Whole frame => causing 1 frame delay, then frame is rendered with the late values, and the next update happens just before the renderer finish rendering meaning the values will be used almost istantly => stutter.

Of course I'm assuming you want to let both threads run in a independent way, if one thread wait for the other then we would fix that issue, but in that case we would jsut stop having most advantages of being multithreaded.

[Mel]

Yeah, i get what you mean, But that precisely is how some engines work. While they display a frame, they're working on the next on the background, they work with a couple of uniform buffers: you process frame N while you render frame N-1, Also, working independently doesn't mean they're working without a proper synchronization, and they stop the threads when they have to, for instance not feeding them commands to work, the background threads remain locked until there is something to do. Multithreading normally comes either in the form of producer-consumers or in the form of collaborative execution, you work only when you have all what you need to work, and you have to make sure you're not stepping on others work.

[REDDemon]

there is one pitfall, you will never know if there is nothing to do anymore It is like delaying some job because there is no hurry, and after some time suddendly comes extra job, and you wished you already had finished your previous taks XD, that's why both threads should run indipendently and at maximum rate possible (I'm not saying that's easy to implement XD). If you are good at gambling and betting you could even win the game anyway!

Actually I have the feeling that you get stuttering in some games, exactly because they had unluck in timing when one thread wait the other.

[Mel]

You have synchronization primitives for that, (semaphores, from c++11 on there are standard mutexes) But synchronization is one heck of a problem in itself. In fact the threads are never really left on their own completely, on certain steps of the program execution, they must reach some "safe" state to continue running. There is never 100% scalability when adding more processing units, you have to sacrifice a bit of power for them to work together.

[REDDemon]

Global

Code: Select all

void * buffer1; //main thread write commands here
Void* buffer2;
Void * buffer3; //render thread executes commands here
MutexOrSpinlock mylock;

Main thread

Code: Select all

 
//Commands ready
mylock.lock():
std::swap(buffer1,buffer2);
Mylock.unlock();

Render thread

Code: Select all

 
//finished rendering 
mylock.lock();
std::swap(buffer2, buffer3);
mylock.unlock();