TPD + control host

9 messages Options
Embed this post
Permalink
Paul Melis

TPD + control host

Reply Threaded More More options
Print post
Permalink
Hi,

I'm trying to make Equalizer work with a 3x3 TPD and so far it has been working great, nice work! The eq sources contain an example configuration, layout.wall.operator.eqc, that specifies a display wall
plus an operator station. This is the setup that I'm aiming for, but I'm unsure about the following.

The control host in my case may be a bit poor in graphics performance, while the TPD nodes are beefy machines. Is there a way to make sure that the equalizer application running on the control host uses somewhat simpler rendering (e.g. display a bounding box instead of a real volume)? I read in the programmer's manual about the 3 roles of the eqPly executable (application, auto-launched render client and resident render client). The application role sounds what I'm looking for, but it seems this only handles events and not rendering. The latter seems to be done using another auto-launched render client.

Is there a way to tell the client launched by the application how to behave w.r.t. render quality?
Perhaps simply setting the relevant Channel name to something like "operator" and making the draw operations in Channel::frameDraw() depend on that is enought, but I was wondering if there was a any feature I had missed for this use case.

Thanks,
Paul
Stefan Eilemann

Re: [eq-dev] TPD + control host

Reply Threaded More More options
Print post
Permalink

Hello Paul,

On 21. Oct 2009, at 11:12, Paul Melis [via Software] wrote:

> The control host in my case may be a bit poor in graphics  
> performance, while the TPD nodes are beefy machines. Is there a way  
> to make sure that the equalizer application running on the control  
> host uses somewhat simpler rendering (e.g. display a bounding box  
> instead of a real volume)? I read in the programmer's manual about  
> the 3 roles of the eqPly executable (application, auto-launched  
> render client and resident render client). The application role  
> sounds what I'm looking for, but it seems this only handles events  
> and not rendering. The latter seems to be done using another auto-
> launched render client.

> Is there a way to tell the client launched by the application how to  
> behave w.r.t. render quality?

The application might also be a render client, i.e., the appNode in  
the config. Then you will have pipe render threads in your application  
process.

You can set a bool variable in your config class after Config::init,  
which will only be executed on the appNode. This way you can detect  
from Channel::frameDraw if you're on the appNode or not.

You might also use a period on the appNode channel compound (only  
render every nth frame) or use a monitor equalizer to copy the  
rendering from the wall to the control host. The latter is still  
somewhat limited in its implementation, e.g., it does not preserve the  
aspect ratio - patches are welcome. ;)


Cheers,

Stefan.

Paul Melis

Re: [eq-dev] TPD + control host

Reply Threaded More More options
Print post
Permalink
Hi Stefan,

Thanks for the quick answer, see below...

Stefan Eilemann [via Software] wrote:

>
> On 21. Oct 2009, at 11:12, Paul Melis [via Software] wrote:
>
> > The control host in my case may be a bit poor in graphics  
> > performance, while the TPD nodes are beefy machines. Is there a way  
> > to make sure that the equalizer application running on the control  
> > host uses somewhat simpler rendering (e.g. display a bounding box  
> > instead of a real volume)? I read in the programmer's manual about  
> > the 3 roles of the eqPly executable (application, auto-launched  
> > render client and resident render client). The application role  
> > sounds what I'm looking for, but it seems this only handles events  
> > and not rendering. The latter seems to be done using another auto-
> > launched render client.
>
> > Is there a way to tell the client launched by the application how to  
> > behave w.r.t. render quality?
>
> The application might also be a render client, i.e., the appNode in  
> the config. Then you will have pipe render threads in your application  
> process.
Right, understood
> You can set a bool variable in your config class after Config::init,  
> which will only be executed on the appNode. This way you can detect  
> from Channel::frameDraw if you're on the appNode or not.
This I'm not sure I understand. If I look at eqPly do you mean that the
call to config->init() in EqPly::run() only returns for the appNode (or
in case of an init error)? So this boolean flag could be set right in
front of step 4 "Run main loop"? And is it guaranteed that the spawning
of the render client for the appNode happens in the while
(config->running() ...) loop after setting the flag (so that the
rendering doesn't start before the flag is correctly set)?
>
> You might also use a period on the appNode channel compound (only  
> render every nth frame) or use a monitor equalizer to copy the  
> rendering from the wall to the control host. The latter is still  
> somewhat limited in its implementation, e.g., it does not preserve the  
> aspect ratio - patches are welcome. ;)
>
That's a bit too advanced for what I want to do :)

Paul

P.S. My forum post is marked with "This message was sent to the
[hidden email] mailing list 0 days, 1 hours and 35 minutes
ago but has not yet been accepted. [...]", but you did reply so it was
obviously posted on the forum. Is the eq-dev list broken?
Stefan Eilemann

Re: [eq-dev] TPD + control host

Reply Threaded More More options
Print post
Permalink

On 21. Oct 2009, at 12:50, Paul Melis [via Software] wrote:

> > You can set a bool variable in your config class after Config::init,
> > which will only be executed on the appNode. This way you can detect
> > from Channel::frameDraw if you're on the appNode or not.
> This I'm not sure I understand. If I look at eqPly do you mean that  
> the
> call to config->init() in EqPly::run() only returns for the appNode  
> (or
> in case of an init error)?

Almost, it never returns from client->initLocal() on render clients.

> So this boolean flag could be set right in
> front of step 4 "Run main loop"?

Yes.

> And is it guaranteed that the spawning
> of the render client for the appNode happens in the while
> (config->running() ...) loop after setting the flag (so that the
> rendering doesn't start before the flag is correctly set)?

No, it happens in Config::init(). So you should set the flag before  
this, but after Client::initLocal.

> P.S. My forum post is marked with "This message was sent to the
> [hidden email] mailing list 0 days, 1 hours and 35 minutes
> ago but has not yet been accepted. [...]", but you did reply so it was
> obviously posted on the forum. Is the eq-dev list broken?

Yes, we're working on it:

http://n2.nabble.com/Mailing-List-delivery-stopped-working-around-Jul-21-tt3389600.html#a3389600


Cheers,

Stefan.

Paul Melis

Re: [eq-dev] TPD + control host

Reply Threaded More More options
Print post
Permalink

Stefan Eilemann wrote:
On 21. Oct 2009, at 12:50, Paul Melis [via Software] wrote:

> > You can set a bool variable in your config class after Config::init,
> > which will only be executed on the appNode. This way you can detect
> > from Channel::frameDraw if you're on the appNode or not.
> This I'm not sure I understand. If I look at eqPly do you mean that  
> the
> call to config->init() in EqPly::run() only returns for the appNode  
> (or
> in case of an init error)?

Almost, it never returns from client->initLocal() on render clients.

> So this boolean flag could be set right in
> front of step 4 "Run main loop"?

Yes.

> And is it guaranteed that the spawning
> of the render client for the appNode happens in the while
> (config->running() ...) loop after setting the flag (so that the
> rendering doesn't start before the flag is correctly set)?

No, it happens in Config::init(). So you should set the flag before  
this, but after Client::initLocal.
Well, it got this to work, thanks. However, I'm basing my stuff on eqOSG, which loads the scenegraph from Pipe::configInit(). At that point the flag hasn't been set yet, but I don't want to load stuff any later (e.g. in Channel::frameDraw). So I guess I will try to use the Pipe name as a way to determine how to render.

Paul
Stefan Eilemann

Re: [eq-dev] TPD + control host

Reply Threaded More More options
Print post
Permalink

On 22. Oct 2009, at 9:52, Paul Melis [via Software] wrote:

> Well, it got this to work, thanks. However, I'm basing my stuff on  
> eqOSG, which loads the scenegraph from Pipe::configInit(). At that  
> point the flag hasn't been set yet, but I don't want to load stuff  
> any later (e.g. in Channel::frameDraw). So I guess I will try to use  
> the Pipe name as a way to determine how to render.

If you set the flag before Config::init, it should be set in  
Pipe::configInit.


HTH,

Stefan.

Paul Melis

Re: [eq-dev] TPD + control host

Reply Threaded More More options
Print post
Permalink

Stefan Eilemann wrote:
On 22. Oct 2009, at 9:52, Paul Melis [via Software] wrote:

> Well, it got this to work, thanks. However, I'm basing my stuff on  
> eqOSG, which loads the scenegraph from Pipe::configInit(). At that  
> point the flag hasn't been set yet, but I don't want to load stuff  
> any later (e.g. in Channel::frameDraw). So I guess I will try to use  
> the Pipe name as a way to determine how to render.

If you set the flag before Config::init, it should be set in  
Pipe::configInit.
Err yes, but won't it be set for all nodes then, not just the appNode?

Paul
Stefan Eilemann

Re: [eq-dev] TPD + control host

Reply Threaded More More options
Print post
Permalink

On 22. Oct 2009, at 9:56, Paul Melis [via Software] wrote:

> Err yes, but won't it be set for all nodes then, not just the appNode?

Not if you set it before Config::init, but after Client::initLocal.


Stefan.

Paul Melis

Re: [eq-dev] TPD + control host

Reply Threaded More More options
Print post
Permalink

Stefan Eilemann wrote:
On 22. Oct 2009, at 9:56, Paul Melis [via Software] wrote:

> Err yes, but won't it be set for all nodes then, not just the appNode?

Not if you set it before Config::init, but after Client::initLocal.
Ahhh, and Application::run() is of course only executed by the appNode.

Paul