Re: [Libvisual-devel] GL library linkage

[Vitaly V. B. <vit...@us...>]

On Thu, 14 Oct 2004 15:58:11 +0200
Burkhard Plaum <pl...@ip...> wrote:

> > We can run 3 X servers independently. He-he. On different machines!
> > I'll try that later.
> 
> If you have them on different machines, the OpenGL calls will be
> tunneled through the X-Protocol to different Servers. X-Protocol
> calls are driver independent.
> Why does the client machine need separate Gl Libs then?
Hm, indeed. They should not.

> > Not actually. It depends...
> 
> If you want to do it right, you must.
glXMakeCurrent is too heavy function to call it every gl call.
It must not be called. Definitely. If we wrap context managing
functions anyway, so it is possible to eliminate this call
if it is not required.

> If you pass a context pointer with each OpenGL call,
> you implicitely allow people intermix calls with different contexts
> (I know that it's nosense, but you never know what programmers do,
> when nobody watches them) And then you must use glxMakeCurrent
> in each call, which adds some cycles to the overhead calculation
> below.
This is worst case scenario. If you need to intermix different contexts,
you group gl calls anyway, don't you?

> If you forbid to intermix such calls, you don't need the context
> pointers and leave things as they are in plain GLX/OpenGL.
OK, I agree. context parameter is not needed. ;)

I was able to run lvdisplay testing app with two independent
actors running in different windows. One thing I had to add is
a context_activate() calls to run() and poll_event() functions. :)

> > Hm, let one function call overhead will be 100 instructions
> > (VERY high overhead). 
> 
> I think 100 is realistic. I'm no assembler/CPU guru, but calling
> functions via dlsym pointers seems a bit slower than direct calls.
The "slow" thing with shared libraries is that the symbols should
be resolved. This is done on library load or on first function call
(it depends on dlopen() parameter). When the library is loaded into
the process' address space the call is simple

	call *<addess of the function pointer>

if library is statically linked it's just

	call <addess of the function>

and if the library is statically shared linked ;)

	call <local_app_address>
...
local_app_address:
	jump *<addess of the function pointer>


If there is malloc()'ed struct with dlsym()'ed function pointers,
call is like this

	mov <struct address>(,%index_reg,4), %eax
	call *%eax

or something alike.

> Overhead becomes then 4.608 ms for 1GHz CPU speed.
> Assuming the lemuria framerate of ca. 30 fps, it's 13.8 %.
Yes, that's a lot.

> If the usage of multiple OpenGL libs cannot be avoided:
> Would it make sense to have them in separate processes? The LD_PRELOAD
> environment variable can easily force a certain libGL.so to be used,
> and OpenGL can be used as we learned it.
That's too drain bamaging, sorry :)

So, as I wrote above, there is almost no difference between staticaly
shared linkage and dlopen()'ed libraries regarding to speed.
Is it OK to load dynamically libGL?

-- 
Vitaly
GPG Key ID: F95A23B9