Another suggestion: "IVideoDriver::setBeginSceneOptions"

Discuss about anything related to the Irrlicht Engine, or read announcements about any significant features or usage changes.

Re: Another suggestion: "IVideoDriver::setBeginSceneOptions"

Postby hendu » Tue Dec 20, 2016 2:31 pm

Well, swrast would also give that. llvmpipe might not, as AVX might round differently than SSE, etc.
hendu
 
Posts: 2587
Joined: Sat Dec 18, 2010 12:53 pm

Re: Another suggestion: "IVideoDriver::setBeginSceneOptions"

Postby sunnystormy » Tue Dec 20, 2016 3:22 pm

@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://osgdp.wordpress.com "The Open-Source Game Development Pipeline"
sunnystormy
 
Posts: 98
Joined: Mon Jun 02, 2014 2:32 am
Location: Washington, D.C.

Re: Another suggestion: "IVideoDriver::setBeginSceneOptions"

Postby CuteAlien » Tue Dec 20, 2016 4:30 pm

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.freenode.net
Code snippets, patches&stuff: http://www.michaelzeilfelder.de/irrlicht.htm
Free racer created with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
User avatar
CuteAlien
Admin
 
Posts: 8363
Joined: Mon Mar 06, 2006 2:25 pm
Location: Tübingen, Germany

Re: Another suggestion: "IVideoDriver::setBeginSceneOptions"

Postby hendu » Wed Dec 21, 2016 10:08 am

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
hendu
 
Posts: 2587
Joined: Sat Dec 18, 2010 12:53 pm

Re: Another suggestion: "IVideoDriver::setBeginSceneOptions"

Postby REDDemon » Wed Dec 21, 2016 5:30 pm

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

Re: Another suggestion: "IVideoDriver::setBeginSceneOptions"

Postby Mel » Thu Dec 22, 2016 12:41 am

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

Re: Another suggestion: "IVideoDriver::setBeginSceneOptions"

Postby REDDemon » Thu Dec 22, 2016 2:47 am

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

Re: Another suggestion: "IVideoDriver::setBeginSceneOptions"

Postby Mel » Thu Dec 22, 2016 12:39 pm

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

Re: Another suggestion: "IVideoDriver::setBeginSceneOptions"

Postby REDDemon » Thu Dec 22, 2016 7:47 pm

Global
cpp Code: Select all
void * buffer1; //main thread write commands here
Void* buffer2;
Void * buffer3; //render thread executes commands here
MutexOrSpinlock mylock;


Main thread
cpp Code: Select all
 
//Commands ready
mylock.lock():
std::swap(buffer1,buffer2);
Mylock.unlock();


Render thread
cpp 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
User avatar
REDDemon
Developer
 
Posts: 1044
Joined: Tue Aug 31, 2010 8:06 pm
Location: Genova (Italy)

Previous

Return to Open Discussion and Dev Announcements

Who is online

Users browsing this forum: Exabot [Bot] and 1 guest