On 31. Oct 2011, at 19:06, Michael Pope [via Software] wrote:
> I would. But I"m sure I'm doing something wrong. I'm attempting to map
> objects on the render node side and I request the config using getConfig().
> This returns the same pointer as the config on the application(server /
> whatever you call the node that loads the config file) side. This can't be
> right.
No, that's right. The config structure except nodes belongs to the application,
the node and downwards to the render client - the application process can be
both, in which case the the node is attached to the application's config
instance.
> I'm almost positive the problem isn't with Equalizer but with something
> stupid I'm doing.
I'm not yet convinced of that.
> I'm looking at eqPly. I've configured it such that I run one instance as a
> client and listening on localhost:2002. Then I run another instance which
> loads a config file that connects to that client. Now, VertexBufferDist is
> registering and mapping. I can't figure out what is causing getInstanceData
> and applyInstanceData to be called.
Anytime the instance data (all app data) is needed: During mapping for
unbuffered/static objects, during registration for all others and once per
commit.
> I understand that there are some packets being sent. I see that
> objectStore.cpp has a _cmdMapObject() function which I believe is handling
> the mapping from master to slave - somehow.
Correct.
> But again, I'm not sure how this is happening. I've checked the programmer's
> guide and it doesn't really make it any clearer to me.
Because this is internals which should just work. It's not really documented in
the PG. There is a sequence diagram here:
https://github.com/Eyescale/Equalizer/wiki/Runtime-Failure-Tolerance
> I'm pretty sure that what you are doing with mapping the vertexBufferDist is
> exactly what I need to do. Where are the commands being sent in eqPly which
> cause the vertexBufferDists to be mapped? I just can't seem to pinpoint it.
eqPly::Config::getModel -> VertexBufferDist::mapModel
> There are multiple worker threads. Each render node has it's own worker
> thread pool.
Could be a race if you have multiple concurrent mapObject going on - I would
need the information from my last email to pinpoint this.
HTH,
Stefan.
--
View this message in context:
http://software.1713.n2.nabble.com/Sending-packets-containing-std-wstring-tp6845178p6949384.html
Sent from the Equalizer - Parallel Rendering mailing list archive at Nabble.com.
_______________________________________________
eq-dev mailing list
[email protected]
http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev
http://www.equalizergraphics.com
