On 4/6/14 5:06 AM, George Profenza wrote: > Thank you very much for the detailed explanations and your patience. > > Using ldd on vglserver_config yelds:"not a dynamic executable" > For the gl apps I see all the linked libraries and > "libGL.so.1 => /usr/lib/arm-linux-gnueabihf/libGL.so.1 (0xb6f21000) > libGLU.so.1 => /usr/lib/arm-linux-gnueabihf/libGLU.so.1 (0xb6ec5000) > libX11.so.6 => /usr/lib/arm-linux-gnueabihf/libX11.so.6 (0xb6db1000)l > " > I can't run the demos though (E.g. glxspheres), I get this output: > " > Polygons in scene: 62464 > ERROR (603): Could not obtain RGB visual with requested properties > " > > So I guess the GL code in the sources need to be ported to GLES > and it sure doesn't look simple to me :)
I really don't know anything about Raspberry Pi, but if it has libX11, then apparently it does support a regular X server. Also, if you're getting that error message, then apparently it supports GLX as well (otherwise, GLXspheres wouldn't even run.) I suspect that EGL may be implemented as a wrapper to GLX, which means that you're going to have to get a "3D X server" up and running just like you would when using VirtualGL with a "regular" PC. This would at least allow you to test VirtualGL as-is and verify that it works on that platform. There is a remote chance that EGL is implemented as a GLX wrapper and that the implementation is done in such a way that EGL applications could be made to work with VirtualGL as-is. Basically, this would be the case if the EGL API was in a separate library that made GLX calls into libGL. I suspect, however, that that's not how it works. It's more likely that the EGL calls are exposed in libGL itself, in which case VirtualGL would have to specifically interpose those calls. And GLXspheres and the other "toy" applications in the VGL source would need to be ported to EGL. The other aspect of this is the windowing system. VirtualGL's basic job is to split OpenGL and X11 rendering. VirtualGL redirects the OpenGL rendering to a "local" X server (the "3D X server") that is attached to a GPU. It then reads back the rendered 3D pixels at the appropriate time and uses 2D drawing commands to composite those pixels back into the appropriate X window, which is displayed to a remote X server or X proxy (the "2D X server".) Meanwhile, the other X11 drawing commands from the application go directly to the 2D X server. Thus, it goes without saying that, if an OpenGL ES application is not using X windows as a means of drawing its GUI, then VirtualGL will not be applicable. This doesn't mean that the application has to directly call X windows. It could be using a toolkit, such as GTK or Qt, that calls X windows "behind the scenes", but ultimately, there has to be some underlying communication between the application and libX11 in order for VirtualGL to work-- as well as VNC, since VNC is a virtual X server. > I'm guessing by "science fair" you mean too localized Yes. The funding aspect is a sort of filter. If someone wants a feature badly enough to pay for it, then the feature usually tends to be broadly applicable. It's quite often the case that one organization will pay me to implement a feature, and another organization will start using the feature and pay me for follow-up work down the road. It is extremely rare that an organization will pay for a feature that is only narrowly applicable. VirtualGL does have a "general fund" that pays for 200 hours/year of my labor, but I have to be judicious with that, since it has to cover any time I spend doing releases and answering e-mails on the mailing lists and doing code cleanup, etc. I have, on occasion, used that fund to pay for new feature implementations, but it really has to be something that is very compelling and something that I feel will move the project forward. > The project looks very useful. It must be pretty hard code for you being > the only maintainer. > I'm wondering if crowd funding would work to help with the financial > support needed. > My guess is OpenGL ES support would be useful for people using Raspberry PI, > beagle bone,Odroid,UDOO,etc. but perhaps to smart phone game developers, > but I shoould do my homework on this instead of making asssumptions. Crowd funding might be useful. It would definitely be a good indicator of whether enough people are interested in this to pay for its implementation. I suspect, however, that this feature is not broadly applicable enough to attract the kind of money that would pay for my labor to implement it. The problem, as above, is that implementing OpenGL ES support in VGL would only allow a very narrow class of OpenGL ES applications-- those that use X11 to do their drawing-- to be supported. Most mobile applications aren't going to fall into that category. > Thanks again, > George > > > > On Sun, Apr 6, 2014 at 7:55 AM, DRC <dcomman...@users.sourceforge.net > <mailto:dcomman...@users.sourceforge.net>> wrote: > > > > On Apr 5, 2014, at 1:14 PM, George Profenza <orgi...@gmail.com > <mailto:orgi...@gmail.com>> wrote: > >> Hi, >> >> I'm new to this so want to make sure I understood what you just >> explained :) >> >> Currently, "out of the box", just compiled, as-is I won't be able >> to use VirtualGL to serve an OpenGL ES window to TurboVNC, correct ? > > Correct > >> "LD_PRELOAD exists in the underlying O/S and applications are >> dynamically linked with the OpenGL ES library" and - is there a >> quick way to test this ? >> I'm hoping the application got linked with OpenGL ES. > > ldd {application binary} > > will tell you whether the app is dynamically linked with OpenGL ES. > Testing LD_PRELOAD is more of an advanced topic. > > >> Regarding intercepting and modifying EGL calls, that would be >> something I would need to modify in the VirtualGL sources ? >> If so, any hints on how I could get started ? > > Yeah, spend 8 years dealing with various OpenGL, high-performance > computing, and video streaming problems, then another 10 doing > nothing but developing remote 3D software, and the problem will seem > straightforward. :) Otherwise, it would be difficult for me to > bring you up to speed on the types of issues you are likely to > encounter. > > This is why (and how) I make my living doing contract development > and consulting around this stuff. I don't earn a salary, so I rely > on financial sponsorship to keep this project afloat, and that > usually takes the form of organizations paying me to add features. I > do things that way for two reasons: (1) it allows the project to > respond to the needs of various different (and sometimes competing) > organizations rather than being co-opted for one specific > organization's agenda, and (2) the expectation that new features > will usually require financial sponsorship means that there will be > a well-defined need for any new feature that goes in (thus > preventing VGL from becoming a "science fair" project.) > > I created VirtualGL from scratch more than 10 years ago. I've been > the sole maintainer of the project and have developed probably 99% > of its code. I am not trying to sound arrogant, but it's just not > possible for me to teach you or anyone else what I know, because I > myself was not taught it. I discovered how to do it on my own > through years of experimentation and research. Even if I brought > someone else up to speed on this code, it would take them twice as > long to develop a feature as it would take me, and the result would > not be as good, so I'd end up having to spend my free time cleaning > up the contributed patches. I am willing to do that if the feature > is something that I feel will be broadly applicable. I don't get > that sense here, though. Without understanding more about why you're > trying to bring up VGL in this environment, I'm getting a very > strong "science fair" vibe here. > > >> Thank you, >> George >> >> >> On Sat, Apr 5, 2014 at 2:20 PM, DRC >> <dcomman...@users.sourceforge.net >> <mailto:dcomman...@users.sourceforge.net>> wrote: >> >> Not currently. I don't know of any technical reason why it >> couldn't, assuming that LD_PRELOAD exists in the underlying >> O/S and applications are dynamically linked with the OpenGL ES >> library. Conceptually, it would just require intercepting and >> modifying the EGL calls in much the same way that we currently >> modify the GLX calls. Straightforward but would probably >> require a lot of testing in order to get right. >> >> > On Apr 5, 2014, at 4:01 AM, George Profenza <orgi...@gmail.com >> <mailto:orgi...@gmail.com>> wrote: >> > >> > Hello, >> > >> > I'm new to VirtualGL and I was wondering if I could use it on a >> Raspberry PI. >> > (arm v6 cpu with a broadcom gpu) >> > >> > I've compiled libjpeg-turbo and VirtualGL from source and ran >> vglserver_config >> > but I can't seem to get an OpenGL ES window showing up in TurboVNC. >> > Is it possible to use OpenGL ES on VirtualGL ? If so, how ? >> > >> > Thank you for your time, >> > George >> > >> ------------------------------------------------------------------------------ >> > _______________________________________________ >> > VirtualGL-Users mailing list >> >VirtualGL-Users@lists.sourceforge.net >> <mailto:VirtualGL-Users@lists.sourceforge.net> >> >https://lists.sourceforge.net/lists/listinfo/virtualgl-users >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> VirtualGL-Users mailing list >> VirtualGL-Users@lists.sourceforge.net >> <mailto:VirtualGL-Users@lists.sourceforge.net> >> https://lists.sourceforge.net/lists/listinfo/virtualgl-users >> >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> VirtualGL-Users mailing list >> VirtualGL-Users@lists.sourceforge.net >> <mailto:VirtualGL-Users@lists.sourceforge.net> >> https://lists.sourceforge.net/lists/listinfo/virtualgl-users > > > ------------------------------------------------------------------------------ > > _______________________________________________ > VirtualGL-Users mailing list > VirtualGL-Users@lists.sourceforge.net > <mailto:VirtualGL-Users@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/virtualgl-users > > > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > VirtualGL-Users mailing list > VirtualGL-Users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/virtualgl-users > ------------------------------------------------------------------------------ _______________________________________________ VirtualGL-Users mailing list VirtualGL-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-users
