I don't know if it helps, but another approach might be to replace one huge
networks with a bunch of small networks, actually macros, invoked by name
through DXLink, that communicate by GetGloballing and SetGloballing named
objects in the cache. (There are hidden inputs to GetGlobal and SetGlobal
that allow you to explicitly give them a string to use as a cache
identifier, rather than linking them). For example, you could create three
macros: one that creates geometry, adding geometry (isosurfaces, etc) to a
group cached as "Geometry", one that renders geometry, retrieving geometry
from "Geometry" and caching images in a group cached as "Images", and one
that plays back the images in "Images":
macro CreateGeometry(frameNumber, parameters)
{
geom = ...
geomGroup = GetGlobal(NULL, 0, "GEOMETRY");
ChangeGroupMember(geomGroup, "replace", frameNumber, geom);
SetGlobal(geomGroup, NULL, "GEOMETRY");
}
macro RenderGeometry(frameNumber, camera)
{
geomGroup = GetGlobal(NULL, 0, "GEOMETRY");
geom = Select(geomGroup, frameNumber);
image = Render(geom, camera);
imageGroup = GetGlobal(NULL, 0, "IMAGES");
ChangeGroupMember(imageGroup, "replace", frameNumber, image);
SetGlobal(imageGroup, NULL, "IMAGES");
}
macro DisplayImage(frameNumber)
{
imageGroup = GetGlobal(NULL, 0, "IMAGES");
image = Select(imageGroup, frameNumber);
Display(image);
}
and all sorts of combinations:
macro DoItAll(frameNumber, parameters, camera)
{
CreateGeometry(frameNumber, parameters);
RenderGeometry(frameNumber, camera);
DisplayImage(frameNumber);
}
macro JustRender(frameNumber, camera)
etc. including versions that run loops.
I think this is not quite what ChangeGroupMember does; I think you'd have
to format a tag string from the frame number.
Hope this helps, let me know if you have any questions.
Greg
Randall Hopper <[EMAIL PROTECTED]>@opendx.watson.ibm.com on 05/31/2000
08:34:37 AM
Please respond to [email protected]
Sent by: [EMAIL PROTECTED]
To: [email protected]
cc:
Subject: [opendx-dev] Re: Optimizing DX
Chris Pelkie:
|> I'm faced with a 3000 module DX network used in a production app
which
|>must be sped up (too slow).
|
|You inherited Mark's Mother of All Nets, I'm guessing? (:-)
Oh, you've heard of it? ;-) Guess it's reached urban legand status (and
it's still growing).
|I think I understand that it's the final playback that's the bottleneck
|from the user's point of view, correct? How about writing multiple frames
|out to MIFF (on the first pass)
That may be the way to go if the first pass times can't be improved much.
|So there's definitely hope if you want to locate loops and rewrite them
as
|modules.
Thanks for the suggestions. In addition to what you've suggested, I've got
a number of other speed-up options to explore in mind:
1) Profiling/optimizing dxexec
Results show that locking, pixel packing, and malloc'ing appear to
be the biggest CPU hogs for "all-cached" net executions.
2) Semi-automatic translation to pure C (no DXLink)
Swapping mail with Mike Zeleznik sold me that a C-only dataflow
would
solve this net's performance problems (with trade-offs).
3) The Switch/Route problem
DX apparently has to touch all of these on cached executions, for
reasons I don't appreciate. Address this, or reduce the number of
Switches and Routes in the main flow.
4) DXLink
Much of the network bulk associated with interactor scalar/string/
error processing can move into a client. Also this may make it
possible to segment the net into separately-executable nets.
5) Macros
Hide modules from the main flow.
And as you mentioned:
6) Custom modules
To handle loops and network chunks requiring a large number of
native DX modules.
7) Second-pass optimizations
Thanks again for the advice.
Randall
--
Randall Hopper (mailto:[EMAIL PROTECTED])
EPA Scientific Visualization Center
US EPA MD/24 ERC-1A; RTP, NC 27711
