Robert Grzeszczuk (rg)
Mon, 26 Apr 1999 12:01:45 -0700 (PDT)
On Apr 26, 9:51am, even.andersen@oslo.pgs.com wrote:
> Subject: Re: Is Volumizer thread safe
>
> Thank you to those that replied,
> I have some more questions.
>
...
>
> Can I download Volumizer 1.1 somewhere (Currently I have 1.0)
Volumizer 1.1 is scheduled to MR this Tuesday. FCS via the Web will follow
shortly (the process typically takes a week).
> If texgenSetEquation does not work, I believe this indicates Volumizer
> 1.0
> is not reentrant either.
texgenSetEquation() does work as specked but it has all the restrictions
imposed by the underlying graphics API (i.e., OpenGL).
>
> I can ofcourse lock each call to volumizer, but I was hoping someone has
> more specific info as to wich calls have to be locked.
Our intention was to document all such cases. For example, the man page for
texgenSetEquation() says:
"... texgenSetEquation()
static void texgenSetEquation (voBrick* aBrick);
If the application did not specify voxel coordinates explicitly the API
will use texgen (see glEnable(3G), glTexGeni(3G)) to generate them on the fly.
texgenSetEquation sets up the equations for the voxel-to-texture coordinate
transformation on a per-brick basis. ..."
This is sufficient to determine that this API call uses the OpenGL context, and
thus all the usual restrictions apply. We'll try to verify that all the
components of the interface state this dependency clearly prior to shipping
1.1. Let us know if you see any omissions.
>
> At the very least it seems like I must provide texturing
> (as opposed to let volumizer handle texture objects, texture
> coordinates,
> etc., ...)
Not really. It all depends on how you decided to parallelize your application.
Suppose, that you have a 3 pipe machine to run a CAVE-like environemt. Your
application can open three windows each with its own context and dedicate a
graphics thread to each one. The threads can share all the read-only data
(e.g., voxel data) but should have a local copy of all the writable data (e.g.,
FaceSets that hold the polygonization results--these will be different for
different views). Each of the treads can issue a texgenSetEquation(), or any
other API call, without any problems, or even much locking. The trick is that
while there are several threads, only one of them accesses any gfx context at
any time. This is true for any OpenGL based application and is not specific to
Volumizer. This is how Chikai's Monster demos handle all the texture
management and other issues. The code is shipping with 1.1.
In a different scenario, you may have two grahics threads collaborating on
rendering the same multi-brick volume into a single window in a
producer-consumer scheme: one of them draws the current brick while the other
downloads the next brick. Each of the threads has a separate context
associated with it. The draw thread uses a texture object defined in its
context to draw the current brick. At the same time the download thread is
dowloading a new texture using the other context. When both threads are done,
the contexts are swapped, so now the draw thread has a context with the newly
downloaded texture, while the download thread starts overriding the obsolete
one.
In general, making a method like texgenSetEquation() re-entrant, implies not
only suitable synchronization, but also context management. I.e., upon
entering the calling thread has to attach to the context and before returning
from the call (and before releasing the locks), it has to issue
glXMakeCurrent(...,NULL) to detach. And this is true for any method that makes
OpenGL calls. Since context switching is one of the most expensive tasks
around, the impact on performance would be tremendous. High overhead of a
context switch is the reason why it is almost always better to have a single
drawing thread per context. This is why you don't want either OpenGL calls or
Volumizer methods to be reentrant in the sense defined above.
>
> > One thing you cannot do in OpenGL is to have more than one thread attached
to
> > the same graphics context (i.e., two treads cannot call glTexGendv()). And
> > even if you could, it would not speed things up. What are you attempting
to
> > do?
>
> I'm working on a mpu based program (MPU ver. 1.1), and I am drawing to
> two
> pipes at the same time. The sample program allocates a copy of the data
> for
> each process. (BTW, I'm using sproc(, PR_SALL, )).
If you are allocating a separate copy of the data for each thread and there is
only one thread per pipe, you should not have any problems. Can you try
writing a simple pure OpenGL test application (e.g., a spinning textured cube)
to verify your design?
Also, I was under (perhaps mistaken) impression that the currently available
versions of MPU forked all the processes.
I also blieve that Patrick Bouchaud has a working version of Volumizer/MPU
demo.
-rg
>
>
>
> Even Oscar Andersen
>
>
>-- End of excerpt from even.andersen@oslo.pgs.com
This archive was generated by hypermail 2.0b2 on Mon Nov 01 1999 - 12:06:41 PST