> On Apr 5, 2014, at 1:14 PM, George Profenza <[email protected]> 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 <[email protected]> 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 <[email protected]> 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
>> > [email protected]
>> > https://lists.sourceforge.net/lists/listinfo/virtualgl-users
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> VirtualGL-Users mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/virtualgl-users
>
> ------------------------------------------------------------------------------
> _______________________________________________
> VirtualGL-Users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/virtualgl-users
------------------------------------------------------------------------------
_______________________________________________
VirtualGL-Users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/virtualgl-users
