Re: [Gl4java-development] problems with gljMakeCurrent/gljFree

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

well I have:
	linux-2.4.1 + i686,
	XFree86 4.0.2 + GeForce256 +nvidia 0.96-nda-binary-driver (at 32bpp)

.X.err:
=====
(II) [GLX]: Updating NV driver (scrn 0) with 5 contexts, 0 drawables, 4 
clients
(II) [GLX]: Updating NV driver (scrn 0) with 5 contexts, 0 drawables, 5 
clients

...

(II) [GLX]: Updating NV driver (scrn 0) with 5 contexts, 7758 drawables, 5 
clients
(II) [GLX]: Updating NV driver (scrn 0) with 5 contexts, 7757 drawables, 5 
clients
(II) [GLX]: Updating NV driver (scrn 0) with 5 contexts, 0 drawables, 5 
clients
(II) [GLX]: Updating NV driver (scrn 0) with 5 contexts, 0 drawables, 5 
clients

...

! no exception !

The problem - you are right - is the call of the gljFree() method, which calls
	glXMakeCurrent( (Display *)disp, None, NULL )
to free the GLXContext !
The NVidia driver makes a stderr printout of the context numbers ..

The reason is, that if you have bound one GLXContext to one thread,
and another thread wants to use it, it will fail.
There can be only one current GLX context per thread.

The reason in the demo's and for the advice to encapsulate
your frame renderings within gljMakeCurrent/gljFree
is to make the GLX context avaiable for possible other threads.
This is more safe.

Well, I do not know why the NVidia driver is that verbose :-).
The OpenGL manual says, that a call of MakeCurrent should not be
very time consuming !

The implementation of gljMakeCurrent only changes the GLXContext,
if the current GLXContext is not the one we want to make current !

I have just testet with gears.java (>java gears -perftest):
	With gljFree() call in end of display method:
		loading libs(gl, glu): null, null: true
		useFpsSleep: false
		useRepaint: false
		GL VERSION : 1.2.1
		GL RENDERER: GeForce 256/AGP/SSE
		GL VENDOR  : NVIDIA Corporation
		280 frames in 5.005 seconds = 55.94405594405595 FPS
		670 frames in 5.001 seconds = 133.9732053589282 FPS
		656 frames in 5.006 seconds = 131.0427487015581 FPS
		607 frames in 5.005 seconds = 121.27872127872128 FPS
		587 frames in 5.008 seconds = 117.21246006389777 FPS

	Without gljFree() call in end of display method:
		loading libs(gl, glu): null, null: true
		useFpsSleep: false
		useRepaint: false
		GL VERSION : 1.2.1
		GL RENDERER: GeForce 256/AGP/SSE
		GL VENDOR  : NVIDIA Corporation
		3491 frames in 5.0 seconds = 698.2 FPS
		4945 frames in 5.0 seconds = 989.0 FPS
		4973 frames in 5.0 seconds = 994.6 FPS
		4940 frames in 5.0 seconds = 988.0 FPS
		4919 frames in 5.001 seconds = 983.6032793441311 FPS
		4903 frames in 5.0 seconds = 980.6 FPS
		4944 frames in 5.0 seconds = 988.8 FPS

Well, this looks like a need to think things over !

This is a performance task and a call for thinking the 
thread-safe mechanism over !

Ideas ?

sven

On Friday 09 February 2001 01:35, you wrote:
> Hi *,
>
> here comes rather a feedback than a question... Have fun with my bad
> english... 8-)
> (I hope it's not off-topic)
>(II) [GLX]: Updating NV driver (scrn 0) with 5 contexts, 0 drawables, 4 
clients
(II) [GLX]: Updating NV driver (scrn 0) with 5 contexts, 0 drawables, 5 
clients
> I wonder if somebody else has the same problems:
>
> I've wrote a tiny test-application, doing nothing but "swapping" front and
> back buffer.
> (ok, copying back to front buffer via "gljSwap()" - have a look at the
> attachment)
>
> I've got the following log:
>
> === schnipp ===
>
> [...<java emptyLoop_GLCanvas>...]
>
> (II) [GLX]: Updating NV driver (scrn 0) with 1 contexts, 0 drawables, 0
> clients
> (II) NVIDIA(0): purgeCache: Free=0x198f000 Total=0x1fd0000
> (II) [GLX]: Updating NV driver (scrn 0) with 1 contexts, 0 drawables, 1
> clients
> (II) [GLX]: Updating NV driver (scrn 0) with 0 contexts, 0 drawables, 1
> clients
> (II) [GLX]: Updating NV driver (scrn 0) with 1 contexts, 0 drawables, 1
> clients
> (II) [GLX]: Updating NV driver (scrn 0) with 0 contexts, 0 drawables, 1
> clients
> (II) [GLX]: Updating NV driver (scrn 0) with 1 contexts, 0 drawables, 1
> clients
> (II) [GLX]: Updating NV driver (scrn 0) with 1 contexts, 1 drawables, 1
> clients
> emptyLoop_canvas.init
> emptyLoop_canvas.reshape
> ..(II) [GLX]: Updating NV driver (scrn 0) with 1 contexts, 2 drawables, 1
> clients
> .(II) [GLX]: Updating NV driver (scrn 0) with 1 contexts, 3 drawables, 1
> clients
> .(II) [GLX]: Updating NV driver (scrn 0) with 1 contexts, 4 drawables, 1
> clients
>
> [...<counting "drawables" 5-3888> ...]
>
> (II) [GLX]: Updating NV driver (scrn 0) with 1 contexts, 3889 drawables, 1
> clients
> # # An unexpected exception has been detected in native code outside the
> VM.# Program counter=0x48c3cf8c
> #
> # Problematic Thread: prio=5 tid=0x81f1498 nid=0x581 runnable
> #
> Aborted
> [thr@elite thr]$ (II) [GLX]: Updating NV driver (scrn 0) with 1 contexts,
> 3888 drawables, 1 clients
> (II) [GLX]: Updating NV driver (scrn 0) with 1 contexts, 0 drawables, 1
> clients
>
> [...<last line repeats ~20 times> ...]
> [...<auto re-init of X/nvidia-driver> ...]
>
> === schnipp ===
>
> Configuration:
>
> 	PC
> 	- AMD Athlon 600MHz
> 	- Asus K7M Mainboard
> 	- 256MB Ram
> 	- Asus GeForce2 32MB V7700
> 	- SBLive Player 1024
>
> 	Linux Red Hat 7.0
> 	- XFree 4.01
> 	- Gnome (default version on redhat 7.0)
> 	- KDE (default version on redhat 7.0)
>
> 	OpenGL
> 	- gl4java 2.5.0.0
> 	- nVidia Drivers 0.94 - 0.96
>
> 	also tried
> 	- Kernel 2.2.18
> 	- kde 2.01
> 	- no window manager at all
>
> So I wrote a tiny "GLAnimCanvas" class for my own. As a result there is no
> need to call "gljMakeCurrent()" and "gljFree()" in the display() method
> anymore (both are called only once at initialization time). Via a
> SwingUtilities like method "invokeLater" and "invokeAndWait" other Threads
> are able to use OpenGL commands getting executed in the main Render-Thread.
> Now no more crashes after two days of running tests. Then I studied the
> differences between the class implementations.
>
> My thesis: It look's like something (i.e. the nvidia driver, X, or
> whatever) doesn't "like" the gljMakeCurrent()/gljFree() combination called
> to often. What is the reason having to call both methods in
> GLAnimCanvas.display() every frame?
>
> Any comments ?
> [ ] what a hero! ;-)
> [ ] nice to know
> [ ] what a pain to read
> [ ] text to long
> [ ] never send attachments
> [ ] just get away
>
> ciao, Thorsten

- ----------------------------------------
Content-Type: application/octet-stream; charset="iso-8859-1"; 
name="emptyLoop_GLCanvas.java"
Content-Transfer-Encoding: quoted-printable
Content-Description: 
- ----------------------------------------

- -- 
mailto:sgo...@ja...
www   : http://www.jausoft.com ; pgp: http://www.jausoft.com/gpg/
voice : +49-521-2399440, +49-170-2115963; fax: +49-521-2399442
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE6g17rHdOA30NoFAARAnG2AKCykVtWJdRe+wwuYlG8cuBnlpgx1wCgiPNZ
2apDQPgaBYGFrRB+Cs6wlxA=
=mQed
-----END PGP SIGNATURE-----