Menu
▾
▴
libvisual-devel
|
From: Vitaly V. B. <vit...@us...> - 2004-10-11 09:59:00
|
Hi, I think Libvisual should not be linked to libGL. It's not right to link with libGL anyway - it's a kinda driver and it is different for different hardware (and different driver versions, for NVIdia). I'm not sure if somebody wants (I don't) to recompile GL programs on driver or hardware update. Libvisual itself has nothing to do with OpenGL, right? It would be Much better if, say, Libvisual can dynamicaly load libGL library and import its functions naming them smth like: lvglBegin() etc. Comments? -- Vitaly GPG Key ID: F95A23B9 |
|
From: Burkhard P. <pl...@ip...> - 2004-10-11 13:54:12
|
Vitaly V. Bursov wrote: > Hi, > > I think Libvisual should not be linked to libGL. It's not right > to link with libGL anyway - it's a kinda driver and it is different > for different hardware (and different driver versions, for NVIdia). If the system is set up corrently, you can exchange the OpenGL libraries without breaking binaries. There are MANY OpenGL programs out there, which come dynamically linked with OpenGL and work after you upgraded to the NVidia drivers. > It would be Much better if, say, Libvisual can dynamicaly load libGL > library and import its functions naming them smth like: lvglBegin() > etc. So the plugin authors have to change 100s of OpenGl calls? I wouldn't do that. If there is any "standard" in the Graphics world, it's OpenGl. It's available on many more platforms than libvisual will propably be ported to. Also the API is extremely clean and stable. I don't think that there are any ABI issues with OpenGL. It's a matter of taste, if you link the core lib with OpenGL or some driver. But plugins must assume that OpenGL is linked somehow (not just dlopenend). The only problem I encountered were wrong RPM dependencies if an RPM is built on a machine with the NVIDIA drivers installed. But the Redhat/Fedora people are already aware of this. -- _____________________________ Dr.-Ing. Burkhard Plaum Institut fuer Plasmaforschung Pfaffenwaldring 31 70569 Stuttgart Tel.: +49 711 685-2187 Fax.: -3102 |
|
From: Vitaly V. B. <vit...@us...> - 2004-10-13 20:09:09
|
On Mon, 11 Oct 2004 15:54:52 +0200 Burkhard Plaum <pl...@ip...> wrote: > > I think Libvisual should not be linked to libGL. It's not right > > to link with libGL anyway - it's a kinda driver and it is different > > for different hardware (and different driver versions, for NVIdia). > > If the system is set up corrently, you can exchange the OpenGL > libraries without breaking binaries. Yes, most of the time, yes... > There are MANY OpenGL programs out there, which come dynamically > linked with OpenGL and work after you upgraded to the NVidia > drivers. ./atlantis: /usr/lib/libGL.so.1: no version information available (required by ./atlantis) ... ugly, but it still runs. > > It would be Much better if, say, Libvisual can dynamicaly load libGL > > library and import its functions naming them smth like: lvglBegin() > > etc. > > So the plugin authors have to change 100s of OpenGl calls? > I wouldn't do that. ... by hand. ;) > If there is any "standard" in the Graphics world, it's OpenGl. > It's available on many more platforms than libvisual will propably > be ported to. Also the API is extremely clean and stable. > I don't think that there are any ABI issues with OpenGL. Agree. there should no ABI issues. > It's a matter of taste, if you link the core lib with OpenGL or some > driver. But plugins must assume that OpenGL is linked somehow (not > just dlopenend). One major benefit we'll get if we'll dlopen GL library is the ability to use different hardware at the same time. Suppose there are ATI, NVidia, S3Trio3D ;) hardware in the system, someone want to use it's 3D acceleration abilities and 3 monitors. Just because. To do this gl calls should be "objectised". Like this lvglBegin(video, GL_LINES); ... lvglEnd(video); to call specific function. If it's done nicely it should introduce almost no overhead. In theory ;) I can't see any problems with that. -- Vitaly GPG Key ID: F95A23B9 |
|
From: Burkhard P. <pl...@ip...> - 2004-10-14 10:02:20
|
> One major benefit we'll get if we'll dlopen GL library is the ability > to use different hardware at the same time. Suppose there are > ATI, NVidia, S3Trio3D ;) hardware in the system, someone want to use it's > 3D acceleration abilities and 3 monitors. Just because. But is this possible at all? Did you ever made such a setup working? How do you want to detect (at runtime), which lib should be dlopened? I doubt, that current X11 installations allow this at all. > To do this gl calls should be "objectised". Like this > lvglBegin(video, GL_LINES); > ... > lvglEnd(video); In this case, each lvgl*() function must internally call glXMakeCurrent() or something similar. If you use pure OpenGL, you call glXMakeCurrent() once. > to call specific function. If it's done nicely it should introduce almost > no overhead. In one case lemuria draws more than 5000 triangles in one frame, along with normal vectors and texture coordinates. It already pushes weaker hardware to the limit. Propagating all these (15000+ / frame) function calls through another lib would make it unusable for many people. > In theory ;) I can't see any problems with that. Pratice looks different in this case. Wrapping library calls makes sense in many cases to keep things clean. But here, we are inside the innermost rendering loop, and speed really becomes important. Hard- and Software developers spend a lot of time, to speed optimize OpenGL calls. So it's a bad idea to slow it down again only for supporting some esotheric hardware configurations. -- _____________________________ Dr.-Ing. Burkhard Plaum Institut fuer Plasmaforschung Pfaffenwaldring 31 70569 Stuttgart Tel.: +49 711 685-2187 Fax.: -3102 |
|
From: Dennis S. <sy...@yo...> - 2004-10-14 10:20:54
|
I don't think wrapping ALL gl calls is a good idea, however, it might be good to have some functions within lvdisplay to request glxcontext, pbuffers and the such, or rather make it possible to access the GLX stuff. However, I'm not an expert in this area, so you guys keep on discussing :)! Cheers, Dennis On Thu, 2004-10-14 at 12:05 +0200, Burkhard Plaum wrote: > > One major benefit we'll get if we'll dlopen GL library is the ability > > to use different hardware at the same time. Suppose there are > > ATI, NVidia, S3Trio3D ;) hardware in the system, someone want to use it's > > 3D acceleration abilities and 3 monitors. Just because. > > But is this possible at all? > Did you ever made such a setup working? > How do you want to detect (at runtime), which lib should be dlopened? > > I doubt, that current X11 installations allow this at all. > > > To do this gl calls should be "objectised". Like this > > lvglBegin(video, GL_LINES); > > ... > > lvglEnd(video); > > In this case, each lvgl*() function must internally call > glXMakeCurrent() or something similar. > If you use pure OpenGL, you call glXMakeCurrent() once. > > > to call specific function. If it's done nicely it should introduce almost > > no overhead. > > In one case lemuria draws more than 5000 triangles in one frame, along with > normal vectors and texture coordinates. > It already pushes weaker hardware to the limit. > > Propagating all these (15000+ / frame) function calls through another > lib would make it unusable for many people. > > > In theory ;) I can't see any problems with that. > Pratice looks different in this case. > > Wrapping library calls makes sense in many cases to keep things clean. > But here, we are inside the innermost rendering loop, and speed really > becomes important. > > Hard- and Software developers spend a lot of time, to speed optimize > OpenGL calls. So it's a bad idea to slow it down again > only for supporting some esotheric hardware configurations. > |
|
From: Vitaly V. B. <vit...@us...> - 2004-10-14 12:45:01
|
On Thu, 14 Oct 2004 12:05:11 +0200 Burkhard Plaum <pl...@ip...> wrote: > But is this possible at all? > Did you ever made such a setup working? > How do you want to detect (at runtime), which lib should be dlopened? > > I doubt, that current X11 installations allow this at all. We can run 3 X servers independently. He-he. On different machines! I'll try that later. > > To do this gl calls should be "objectised". Like this > > lvglBegin(video, GL_LINES); > > ... > > lvglEnd(video); > > In this case, each lvgl*() function must internally call > glXMakeCurrent() or something similar. Not actually. It depends... > > to call specific function. If it's done nicely it should introduce almost > > no overhead. > > In one case lemuria draws more than 5000 triangles in one frame, along with > normal vectors and texture coordinates. > It already pushes weaker hardware to the limit. > > Propagating all these (15000+ / frame) function calls through another > lib would make it unusable for many people. Hm, let one function call overhead will be 100 instructions (VERY high overhead). It will be (less than, due to architecture) 15000*100=1.500.000 CPU clocks. On a 1GHz it's 1.5ms. Is that much? > > In theory ;) I can't see any problems with that. > Pratice looks different in this case. > > Wrapping library calls makes sense in many cases to keep things clean. > But here, we are inside the innermost rendering loop, and speed really > becomes important. CPU is not a bottleneck here. Memory, AGP buses, GPU -- yes, maybe. It must be extremly highly optimized software (for _this_ hardware only!) to make CPU a bottleneck. > Hard- and Software developers spend a lot of time, to speed optimize > OpenGL calls. So it's a bad idea to slow it down again > only for supporting some esotheric hardware configurations. Les't support a cluster! :) I'll try this in a few days. -- Vitaly GPG Key ID: F95A23B9 |
|
From: Burkhard P. <pl...@ip...> - 2004-10-14 13:54:30
|
> 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? > Not actually. It depends... If you want to do it right, you must. 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. If you forbid to intermix such calls, you don't need the context pointers and leave things as they are in plain GLX/OpenGL. > 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. > It will be (less than, due to architecture) > 15000*100=1.500.000 CPU clocks. On a 1GHz it's 1.5ms. > Is that much? Ok, I made some errors before: I have 5120 Triangles, 9 OpenGL calls per triangle (3 * (glNormal + glTexCoord + glVertex)) makes 46080 calls per frame. The mesh is much too complicated to make a triangle strip. Overhead becomes then 4.608 ms for 1GHz CPU speed. Assuming the lemuria framerate of ca. 30 fps, it's 13.8 %. And the 46080 calls are not the only ones which are necessary to draw the picture. This time could be used to make better looking animations than enabling features which are useless for 99% of all users. 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. -- _____________________________ Dr.-Ing. Burkhard Plaum Institut fuer Plasmaforschung Pfaffenwaldring 31 70569 Stuttgart Tel.: +49 711 685-2187 Fax.: -3102 |
|
From: Vitaly V. B. <vit...@us...> - 2004-10-15 09:19:07
|
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 |
|
From: Dennis S. <sy...@yo...> - 2004-10-11 22:24:44
|
It really should not indeed, never noticed that it was doing so. If you can fix this for me, please do so! The libvisual core doesn't need any GLness anyway. On Mon, 2004-10-11 at 12:58 +0300, Vitaly V. Bursov wrote: > Hi, > > I think Libvisual should not be linked to libGL. It's not right > to link with libGL anyway - it's a kinda driver and it is different > for different hardware (and different driver versions, for NVIdia). > > I'm not sure if somebody wants (I don't) to recompile GL programs > on driver or hardware update. Libvisual itself has nothing to do > with OpenGL, right? > > It would be Much better if, say, Libvisual can dynamicaly load libGL > library and import its functions naming them smth like: lvglBegin() > etc. > > Comments? > |
|
From: Burkhard P. <pl...@ip...> - 2004-10-14 11:04:11
|
Dennis Smit wrote: > I don't think wrapping ALL gl calls is a good idea, however, it might > be good to have some functions within lvdisplay to request glxcontext, > pbuffers and the such, or rather make it possible to access the GLX > stuff. I agree with Dennis. Something like glxMakeCurrent MUST be wrapped, because it looks different, on systems, which don't have GLX. Making plugins depend on GLX restricts their usage to X11. Other systems MUST have something analogous then, because OpenGL doesn't know about windows, so some glue lib between Window system <-> OpenGL is always needed. But all OpenGL functions must be available directly. This also makes porting plugins to libvisual more easy. -- _____________________________ Dr.-Ing. Burkhard Plaum Institut fuer Plasmaforschung Pfaffenwaldring 31 70569 Stuttgart Tel.: +49 711 685-2187 Fax.: -3102 |
|
From: Vitaly V. B. <vit...@us...> - 2004-10-14 12:35:51
|
On Thu, 14 Oct 2004 13:07:57 +0200 Burkhard Plaum <pl...@ip...> wrote: > Dennis Smit wrote: > > I don't think wrapping ALL gl calls is a good idea, however, it might > > be good to have some functions within lvdisplay to request glxcontext, > > pbuffers and the such, or rather make it possible to access the GLX > > stuff. > > I agree with Dennis. > Something like glxMakeCurrent MUST be wrapped, because it looks different, > on systems, which don't have GLX. Making plugins depend on GLX restricts > their usage to X11. Agree, they will be (alreary are) wrapped with context_create(), context_delete(), context_activate. > Other systems MUST have something analogous then, because OpenGL doesn't > know about windows, so some glue lib between Window system <-> OpenGL > is always needed. Even more. Non gl render targets can have contexts also. -- Vitaly GPG Key ID: F95A23B9 |
|
From: Burkhard P. <pl...@ip...> - 2004-10-15 11:26:02
|
> This is worst case scenario. If you need to intermix different contexts, > you group gl calls anyway, don't you? I wouldn't intermix the calls, because it's nonsense. But as I said, less advanced programmers get strange ideas, when nobody watches them :-) Each API, which uses context pointers suggests, that intermixing is possible (the same way you can intermix fwrite calls with different FILE handles). So it would IMHO the best solution not to use contexts for each GL call, forbid intermixing and call glxMakeCurrent only once per frame/context. And every OpenGL programmer will be happy, because it's the way plain OpenGL works. > 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. And this would be the case, if you would wrap dlsym()ed gl* functions into lvgl* calls? >>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 :) IMHO less brain damaging than renaming and wrapping 100s of OpenGL functions. > 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? There are now 3 options: 1. Link statically 2. Link dynamically 3. dlopen Which of 1 and 2 are used, is beyond control of the libvisual developers. Because it depends on which libs (.a or .so or both) the user has installed when compiling. Normally, the linker will perfer .so until -static is used. So the question is whether to link opengl (i.e. -lGL) or dlopen() it. I strongly believe, that linking is easier, it's the standard way to use libraries and causes little overhead (and the burdon of making this work is transferred to the gcc/glibc/kernel developers). Furthermore, if some new functions appear in a later OpenGL version, plugin developers can play with them without waiting, until a new libvisual version makes them available through dlsym(). -- _____________________________ Dr.-Ing. Burkhard Plaum Institut fuer Plasmaforschung Pfaffenwaldring 31 70569 Stuttgart Tel.: +49 711 685-2187 Fax.: -3102 |
|
From: Vitaly V. B. <vit...@us...> - 2004-10-19 20:47:29
|
On Fri, 15 Oct 2004 13:27:26 +0200
Burkhard Plaum <pl...@ip...> wrote:
> > This is worst case scenario. If you need to intermix different contexts,
> > you group gl calls anyway, don't you?
>
> I wouldn't intermix the calls, because it's nonsense.
> But as I said, less advanced programmers get strange ideas,
> when nobody watches them :-)
:) so as more advanced.
> > 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.
>
> And this would be the case, if you would wrap dlsym()ed gl* functions into
> lvgl* calls?
Yes.
Here are test results.
optimization is off.
$ gcc -g a.c
=======
int main()
{
void *h = dlopen("libm.so.6", RTLD_LAZY);
a = dlsym(h, "sin");
a(0.3);
}
=======
piece of asm code.
// it's a a(0.3) call;
0x08048432 <main+58>: mov %eax,0x8049668
0x08048437 <main+63>: movl $0x3e99999a,(%esp)
0x0804843e <main+70>: mov 0x8049668,%eax
0x08048443 <main+75>: call *%eax
0x08048445 <main+77>: fstp %st(0)
(gdb) stepi
0x0804843e 10 a(0.3);
(gdb)
0x08048443 10 a(0.3);
(gdb)
0x41156760 in __sin () from /lib/libm.so.6
(gdb) print /x $eax
$3 = 0x41156760
> >>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 :)
>
> IMHO less brain damaging than renaming and wrapping 100s of OpenGL
> functions.
Hm, it is possible to not rename them. just declare these glAsdFg()
functions. One problem here is that if plugin gets linked to
libGL.
> > 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?
>
> There are now 3 options:
>
> 1. Link statically
> 2. Link dynamically
> 3. dlopen
>
> Which of 1 and 2 are used, is beyond control of the libvisual developers.
> Because it depends on which libs (.a or .so or both) the user has installed
> when compiling. Normally, the linker will perfer .so until -static is used.
> So the question is whether to link opengl (i.e. -lGL) or dlopen() it.
> I strongly believe, that linking is easier, it's the standard way to use
> libraries and causes little overhead (and the burdon of making this
> work is transferred to the gcc/glibc/kernel developers).
... various X Servers, various GL drivers, various venders.
And everybody has own opinion.
> Furthermore, if some new functions appear in a later OpenGL version,
> plugin developers can play with them without waiting, until a new libvisual
> version makes them available through dlsym().
This can be done automatically during build process. If there's a header
file with declarations it's possible to parse it.
And how should be handled plugins that dlopen() libGL? (hm, are there any
around? except scivi, of course :))
Dennis, what do you think? We have a Holy War here! :)
--
Vitaly
GPG Key ID: F95A23B9
|
|
From: Dennis S. <sy...@yo...> - 2004-10-21 06:09:38
|
On Tue, 2004-10-19 at 22:33 +0300, Vitaly V. Bursov wrote: > > IMHO less brain damaging than renaming and wrapping 100s of OpenGL > > functions. > Hm, it is possible to not rename them. just declare these glAsdFg() > functions. One problem here is that if plugin gets linked to > libGL. > > 1. Link statically > > 2. Link dynamically > > 3. dlopen > > > > Which of 1 and 2 are used, is beyond control of the libvisual developers. > > Because it depends on which libs (.a or .so or both) the user has installed > > when compiling. Normally, the linker will perfer .so until -static is used. > > > So the question is whether to link opengl (i.e. -lGL) or dlopen() it. > > I strongly believe, that linking is easier, it's the standard way to use > > libraries and causes little overhead (and the burdon of making this > > work is transferred to the gcc/glibc/kernel developers). > ... various X Servers, various GL drivers, various venders. > And everybody has own opinion. > > > Furthermore, if some new functions appear in a later OpenGL version, > > plugin developers can play with them without waiting, until a new libvisual > > version makes them available through dlsym(). > This can be done automatically during build process. If there's a header > file with declarations it's possible to parse it. What about binear distributions of libvisual ? > And how should be handled plugins that dlopen() libGL? (hm, are there any > around? except scivi, of course :)) > > Dennis, what do you think? We have a Holy War here! :) Well, I must admit I haven't been following it all, can you summarise what the advantage is off dlopen is, and what the problems are with dynamical linking ? I'd personally go for dynamical linking as long that is possible, when problems arise, we shouldn't go out of the way, and do it the hard way if needed, but only if needed. Cheers, Dennis |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X