Re: Muti-Threading JOGL Problem
Locked
Re: Muti-Threading JOGL Problem
 
Administrator
|
On 10/09/2012 02:35 AM, moeabdol [via jogamp] wrote:
> I'm writing a simple OpenGL application in Java that implements the Monte > Carlo method for estimating the value of PI. The method is pretty easy. > Simply, you draw a circle inside a unit square and then plot random points > over the scene. Now, for each point that is inside the circle you increment > the counter for in points. After determining for all the random points wither > they are inside the circle or not you divide the number of in points over the > total number of points you have plotted all multiplied by 4 to get an > estimation of PI. It goes something like this PI = (inPoints / totalPoints) * > 4. This is because mathematically the ratio of a circle's area to a square's > area is PI/4, so when we multiply it by 4 we get PI. > > My problem doesn't lie in the algorithm itself; however, I'm having problems > trying to plot the points as they are being generated instead of just plotting > everything at once when the program finishes executing. I want to give the > application a sense of real-time display where the user would see the points > as they are being plotted. I'm a beginner at OpenGL and I'm pretty sure there > is a multi-threading feature built into it. Non the less, I tried to manually > create my own thread. Each worker thread plots one point at a time. Following > is the psudo-code: > > To view the original post and the psudo-code kindly visit the following link, > and I would really appreciate if you can post back over there. > > http://gamedev.stackexchange.com/questions/38529/multi-threaded-jogl-problem#comment64911_38529 > > Thanks :) finally I can elaborate on multithreading and HPC a bit :) <http://gamedev.stackexchange.com/a/38576/20659>: Multithreaded use of _one_ OpenGL context is not supported by the specs, since one OpenGL context can only be made current by one thread at a time. To use your pseudo code w/ multiple threads and one drawable target, you want to use shared context, see my answer to a related OpenGL multithreading question <http://stackoverflow.com/a/12765071/1725943>. The shared context would need to be bound to a common drawable, which is a quite different scenario than any use case we have covered so far. Wade is right here, that it is quite possible to do so by the spec, at least not forbidden :) However OpenGL driver implementations usually bind the context to one drawable (as it is true w/ Mesa DRI) and locking will be performed. This is also true w/ JOGL, i.e. we claim the drawable lock when make the context current to ensure that no other thread is using it concurrently. Using a drawable concurrently usually produce undefined results anyways, as described in the OpenGL spec in regards to FBO (framebuffer objects). Another OpenGL implementation sideffect is the emulation of fixed function pipeline, i.e. constructs like - glBegin(..) .. glVertex(..) .. glEnd() will only - create an VBO - send it to the shader and render it at some point in time when it needs to be done (swapBuffer() is the latest point here). Impact of the above means that your multiple threads will fight at least for the GPU's shader engine, but the impl. also for the drawable lock. Even if you use OpenCL, which is designed for such a cause, i.e. HPC, your workflow is not suitable, since the data to be processed should be readily available before starting the kernel. Hence OpenGL or OpenCL would make no difference here. There is one little light at the end of the tunnel though :) If you would use a fragment shader using the noise function (random) and render the circle solely in it - you might get what you are heading at, a GPU accelerated 'estimation'. ~Sven |
signature.asc (907 bytes) | Free forum by Nabble | Edit this page |