Another suggestion: "IVideoDriver::setBeginSceneOptions"

Discuss about anything related to the Irrlicht Engine, or read announcements about any significant features or usage changes.
hendu
Posts: 2600
Joined: Sat Dec 18, 2010 12:53 pm

Re: Another suggestion: "IVideoDriver::setBeginSceneOptions"

Post by hendu »

Well, swrast would also give that. llvmpipe might not, as AVX might round differently than SSE, etc.
sunnystormy
Posts: 105
Joined: Mon Jun 02, 2014 2:32 am
Location: Washington, D.C.
Contact:

Re: Another suggestion: "IVideoDriver::setBeginSceneOptions"

Post by 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?
My blog: http://fsgdp.wordpress.com "The Free Software Game Development Pipeline"
CuteAlien
Admin
Posts: 9628
Joined: Mon Mar 06, 2006 2:25 pm
Location: Tübingen, Germany
Contact:

Re: Another suggestion: "IVideoDriver::setBeginSceneOptions"

Post by 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...
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
hendu
Posts: 2600
Joined: Sat Dec 18, 2010 12:53 pm

Re: Another suggestion: "IVideoDriver::setBeginSceneOptions"

Post by 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
Developer
Posts: 1044
Joined: Tue Aug 31, 2010 8:06 pm
Location: Genova (Italy)

Re: Another suggestion: "IVideoDriver::setBeginSceneOptions"

Post by REDDemon »

Mel wrote:
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
Competition winner
Posts: 2292
Joined: Wed May 07, 2008 11:40 am
Location: Granada, Spain

Re: Another suggestion: "IVideoDriver::setBeginSceneOptions"

Post by 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.
"There is nothing truly useless, it always serves as a bad example". Arthur A. Schmitt
REDDemon
Developer
Posts: 1044
Joined: Tue Aug 31, 2010 8:06 pm
Location: Genova (Italy)

Re: Another suggestion: "IVideoDriver::setBeginSceneOptions"

Post by REDDemon »

there is one pitfall, you will never know if there is nothing to do anymore :D 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.
Junior Irrlicht Developer.
Real value in social networks is not about "increasing" number of followers, but about getting in touch with Amazing people.
- by Me
Mel
Competition winner
Posts: 2292
Joined: Wed May 07, 2008 11:40 am
Location: Granada, Spain

Re: Another suggestion: "IVideoDriver::setBeginSceneOptions"

Post by 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.
"There is nothing truly useless, it always serves as a bad example". Arthur A. Schmitt
REDDemon
Developer
Posts: 1044
Joined: Tue Aug 31, 2010 8:06 pm
Location: Genova (Italy)

Re: Another suggestion: "IVideoDriver::setBeginSceneOptions"

Post by 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();
 
Junior Irrlicht Developer.
Real value in social networks is not about "increasing" number of followers, but about getting in touch with Amazing people.
- by Me
Post Reply