virtualgl-users — VirtualGL User Discussion and Support (moved to Google Groups-- see http://www.VirtualGL.org/About/MailingLists)

[VirtualGL-Users] vglrun on a single machine

[Guinnup, C. D. <Chr...@jh...>]

Hi,

How is installing VirtualGL and then launching my application with 'vglrun' fixing an x11grab (screen capture) overlay-flickering issue?  I came upon the solution online, but with no explanation for why it works, and now I'm very curious.

After pouring over the VirtualGL documentation, I've gathered that it's using X11 Transport since the connection is local. If I were to hazard I guess: the flickering (which was never visible on the monitor, just the captured video) may've been caused by grabbing a frame from X11 before the GPU completely rendered the overlays. And now that X11 Transport is painting full images with XPutImage(), it can't grab mid-render anymore?

Is my explanation totally off-base?

I imagine running this way (vs. without VirtualGL) has at least a small performance impact.  But if it's the best way to solve the issue, would be worth it!

Chris Guinnup

[VirtualGL-Users] SC15

[DRC <dco...@us...>]

If any of you will be at SuperComputing 2015 and would like to meet with 
me personally (particularly if you'll be showing off VirtualGL, 
TurboVNC, or libjpeg-turbo in your booth), please shoot me an e-mail 
off-list.  I'll have access to the convention floor, courtesy of one of 
our project sponsors.

DRC

Re: [VirtualGL-Users] ERROR: in FBX -- XCopyArea symbol not loaded

[DRC <dco...@us...>]

A fix for the XCopyArea symbol error that you reported in 2.5 alpha has 
been checked into git master.  2.5 beta should land sometime this month.


On 9/3/15 5:33 PM, Michael Mirsky wrote:
> I'm very sorry for not including the version. If I had, I might have realized I wasn't building with version I thought I was.
>
> I found I was building with VirtualGL-2.4.80.x86_64 (not certain where I originally found that tar). The official binary I was testing is VirtualGL-2.4.1.x86_64.rpm. I picked up the correct source for VirtualGL-2.4.1.x86_64 and compiled that. With the new source, I do not receive the '-c proxy' error any more. So egg on my face...
>
> To answer your question, yes. Previously, when I was building the incorrect version, '-c proxy' failed on Cygwin but not with TurboVNC.
>
> Even now with 2.4.1, Cygwin '-c proxy' still performs better than '-c jpeg' or '-c rgb'. With TurboVNC, I cannot tell the difference between any of the compression types -- they all seem very fluid.
>
> Perhaps, I've setup something incorrectly with Cygwin\X. I will re-investigate that, and re-read the documentation.
>
> Once again, sorry for my inaccuracy & false alarm.
>
> -----Original Message-----
> From: DRC [mailto:dco...@us...]
> Sent: Thursday, September 03, 2015 3:58 PM
> To: vir...@li...
> Subject: Re: [VirtualGL-Users] ERROR: in FBX -- XCopyArea symbol not loaded
>
> Which version of VirtualGL?  That is literally the most important detail to include in any bug report.
>
> Also, if you're observing that '-c proxy' performs better than the default '-c jpeg', then something is terribly wrong.  "Proxy mode" is intended for X proxies, e.g. TurboVNC.  It sends the images uncompressed through the X11 protocol, which means that, even on gigabit, the most you'll see is 30 Megapixels/sec (JPEG can easily achieve twice that on a
> 100 Mbit network.)
>
> Also, just to clarify, '-c proxy' fails only with Cygwin but works with TurboVNC?  Definitely something amiss there as well.  You're going to need to provide a lot more details before I can even begin to figure out what's going on.
>
>
> On 9/3/15 2:28 PM, Michael Mirsky wrote:
>> Hello,
>>
>> I’m new to VirtualGL and I’ve been testing it with my Qt5 app. For the
>> most part, it works flawlessly! However, I have run into one issue.
>> Specifically, my build of VirtualGL fails with the following error if
>> I try to launch my app with the “-c proxy” compression option:
>>
>> [VGL] ERROR: in FBX—
>>
>> [VGL]         510: [FBX] ERROR: XCopyArea symbol not loaded
>>
>> Any ideas of what this error means or what I might have missed during
>> compilation? Running with “-c rgb” or the default works.
>>
>> I first tested with the “official” VirtualGL binary package, and
>> vglrun with the “-c proxy” option performs with the least lag. Thus,
>> it would be nice to combine that with the xcb interposer so that resize works.
>>
>> As some background, my VirtualGL server is running on Linux (RHEL6)
>> and my client is Windows with Cygwin\X. I’ve tested using TurboVNC and
>> that works great, but I’d prefer to get Cygwin\X to work if possible.
>
> ------------------------------------------------------------------------------
> Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
> Get real-time metrics from all of your servers, apps and tools in one place.
> SourceForge users - Click here to start your Free Trial of Datadog now!
> http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140
> _______________________________________________
> VirtualGL-Users mailing list
> Vir...@li...
> https://lists.sourceforge.net/lists/listinfo/virtualgl-users
> ------------------------------------------------------------------------------
> Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
> Get real-time metrics from all of your servers, apps and tools
> in one place.
> SourceForge users - Click here to start your Free Trial of Datadog now!
> http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140
> _______________________________________________
> VirtualGL-Users mailing list
> Vir...@li...
> https://lists.sourceforge.net/lists/listinfo/virtualgl-users
>

[VirtualGL-Users] Putting out feelers for new funded development work

[DRC <dco...@us...>]

I have a couple of funded projects in the works for TurboVNC 2.1, but 
there is no funded work on the horizon for VirtualGL and TurboVNC after 
the end of 2015.  As you know, I rely on funded development 
opportunities in order to stay afloat as an independent developer, which 
allows me to develop VirtualGL and TurboVNC in a manner that serves the 
needs of all of its users (instead of being focused on just one 
organization's agenda) and allows me to devote my full resources to the 
projects.  Please take a moment to review some proposed features for 
TurboVNC that are in need of funding:

https://github.com/TurboVNC/turbovnc/labels/funding%20needed

If your organization would be willing to fund the development of one or 
more of these features, or if you have other ideas in mind for VirtualGL 
and TurboVNC enhancements, please contact me.  There are a great deal of 
other possibilities for future work, such as Wayland support, H.264 
support, etc., that are yet to be fully fleshed out.

I also provide professional support contracts and ad hoc consulting 
services for VirtualGL and TurboVNC (or any other remote display 
software, for that matter) at reasonable hourly rates.

Darrell

Re: [VirtualGL-Users] ERROR: in FBX -- XCopyArea symbol not loaded

[DRC <dco...@us...>]

It's not a false alarm.  2.4.80 = 2.5 alpha, so that means there's a bug 
in the evolving VGL 2.5 code that needs to be fixed before it goes into 
beta.  That's why I needed to know which version you were using.  I 
strongly suspected that you were using the 2.5 alpha version, which has 
a lot of changes to how symbols are loaded.  You probably got the 
tarball from our pre-releases page.

I would not expect there to be much noticeable difference in the three 
VGL compression options within the TurboVNC environment, because 
TurboVNC is actually doing the compression.  When you use -c jpeg in 
TurboVNC, you are just wasting CPU cycles, because VirtualGL is 
compressing the images, vglclient is decompressing them, and TurboVNC is 
compressing them again.  But it still doesn't explain why JPEG would be 
slower in Cygwin.  That definitely should not be the case.

I will investigate the bug in 2.5 alpha.


On 9/3/15 5:33 PM, Michael Mirsky wrote:
> I'm very sorry for not including the version. If I had, I might have realized I wasn't building with version I thought I was.
>
> I found I was building with VirtualGL-2.4.80.x86_64 (not certain where I originally found that tar). The official binary I was testing is VirtualGL-2.4.1.x86_64.rpm. I picked up the correct source for VirtualGL-2.4.1.x86_64 and compiled that. With the new source, I do not receive the '-c proxy' error any more. So egg on my face...
>
> To answer your question, yes. Previously, when I was building the incorrect version, '-c proxy' failed on Cygwin but not with TurboVNC.
>
> Even now with 2.4.1, Cygwin '-c proxy' still performs better than '-c jpeg' or '-c rgb'. With TurboVNC, I cannot tell the difference between any of the compression types -- they all seem very fluid.
>
> Perhaps, I've setup something incorrectly with Cygwin\X. I will re-investigate that, and re-read the documentation.
>
> Once again, sorry for my inaccuracy & false alarm.
>
> -----Original Message-----
> From: DRC [mailto:dco...@us...]
> Sent: Thursday, September 03, 2015 3:58 PM
> To: vir...@li...
> Subject: Re: [VirtualGL-Users] ERROR: in FBX -- XCopyArea symbol not loaded
>
> Which version of VirtualGL?  That is literally the most important detail to include in any bug report.
>
> Also, if you're observing that '-c proxy' performs better than the default '-c jpeg', then something is terribly wrong.  "Proxy mode" is intended for X proxies, e.g. TurboVNC.  It sends the images uncompressed through the X11 protocol, which means that, even on gigabit, the most you'll see is 30 Megapixels/sec (JPEG can easily achieve twice that on a
> 100 Mbit network.)
>
> Also, just to clarify, '-c proxy' fails only with Cygwin but works with TurboVNC?  Definitely something amiss there as well.  You're going to need to provide a lot more details before I can even begin to figure out what's going on.
>
>
> On 9/3/15 2:28 PM, Michael Mirsky wrote:
>> Hello,
>>
>> I’m new to VirtualGL and I’ve been testing it with my Qt5 app. For the
>> most part, it works flawlessly! However, I have run into one issue.
>> Specifically, my build of VirtualGL fails with the following error if
>> I try to launch my app with the “-c proxy” compression option:
>>
>> [VGL] ERROR: in FBX—
>>
>> [VGL]         510: [FBX] ERROR: XCopyArea symbol not loaded
>>
>> Any ideas of what this error means or what I might have missed during
>> compilation? Running with “-c rgb” or the default works.
>>
>> I first tested with the “official” VirtualGL binary package, and
>> vglrun with the “-c proxy” option performs with the least lag. Thus,
>> it would be nice to combine that with the xcb interposer so that resize works.
>>
>> As some background, my VirtualGL server is running on Linux (RHEL6)
>> and my client is Windows with Cygwin\X. I’ve tested using TurboVNC and
>> that works great, but I’d prefer to get Cygwin\X to work if possible.
>
> ------------------------------------------------------------------------------
> Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
> Get real-time metrics from all of your servers, apps and tools in one place.
> SourceForge users - Click here to start your Free Trial of Datadog now!
> http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140
> _______________________________________________
> VirtualGL-Users mailing list
> Vir...@li...
> https://lists.sourceforge.net/lists/listinfo/virtualgl-users
> ------------------------------------------------------------------------------
> Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
> Get real-time metrics from all of your servers, apps and tools
> in one place.
> SourceForge users - Click here to start your Free Trial of Datadog now!
> http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140
> _______________________________________________
> VirtualGL-Users mailing list
> Vir...@li...
> https://lists.sourceforge.net/lists/listinfo/virtualgl-users
>

Re: [VirtualGL-Users] ERROR: in FBX -- XCopyArea symbol not loaded

[Michael M. <mm...@po...>]

I'm very sorry for not including the version. If I had, I might have realized I wasn't building with version I thought I was.

I found I was building with VirtualGL-2.4.80.x86_64 (not certain where I originally found that tar). The official binary I was testing is VirtualGL-2.4.1.x86_64.rpm. I picked up the correct source for VirtualGL-2.4.1.x86_64 and compiled that. With the new source, I do not receive the '-c proxy' error any more. So egg on my face...

To answer your question, yes. Previously, when I was building the incorrect version, '-c proxy' failed on Cygwin but not with TurboVNC.

Even now with 2.4.1, Cygwin '-c proxy' still performs better than '-c jpeg' or '-c rgb'. With TurboVNC, I cannot tell the difference between any of the compression types -- they all seem very fluid.

Perhaps, I've setup something incorrectly with Cygwin\X. I will re-investigate that, and re-read the documentation.

Once again, sorry for my inaccuracy & false alarm.

-----Original Message-----
From: DRC [mailto:dco...@us...] 
Sent: Thursday, September 03, 2015 3:58 PM
To: vir...@li...
Subject: Re: [VirtualGL-Users] ERROR: in FBX -- XCopyArea symbol not loaded

Which version of VirtualGL?  That is literally the most important detail to include in any bug report.

Also, if you're observing that '-c proxy' performs better than the default '-c jpeg', then something is terribly wrong.  "Proxy mode" is intended for X proxies, e.g. TurboVNC.  It sends the images uncompressed through the X11 protocol, which means that, even on gigabit, the most you'll see is 30 Megapixels/sec (JPEG can easily achieve twice that on a
100 Mbit network.)

Also, just to clarify, '-c proxy' fails only with Cygwin but works with TurboVNC?  Definitely something amiss there as well.  You're going to need to provide a lot more details before I can even begin to figure out what's going on.


On 9/3/15 2:28 PM, Michael Mirsky wrote:
> Hello,
>
> I’m new to VirtualGL and I’ve been testing it with my Qt5 app. For the 
> most part, it works flawlessly! However, I have run into one issue.
> Specifically, my build of VirtualGL fails with the following error if 
> I try to launch my app with the “-c proxy” compression option:
>
> [VGL] ERROR: in FBX—
>
> [VGL]         510: [FBX] ERROR: XCopyArea symbol not loaded
>
> Any ideas of what this error means or what I might have missed during 
> compilation? Running with “-c rgb” or the default works.
>
> I first tested with the “official” VirtualGL binary package, and 
> vglrun with the “-c proxy” option performs with the least lag. Thus, 
> it would be nice to combine that with the xcb interposer so that resize works.
>
> As some background, my VirtualGL server is running on Linux (RHEL6) 
> and my client is Windows with Cygwin\X. I’ve tested using TurboVNC and 
> that works great, but I’d prefer to get Cygwin\X to work if possible.

------------------------------------------------------------------------------
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140
_______________________________________________
VirtualGL-Users mailing list
Vir...@li...
https://lists.sourceforge.net/lists/listinfo/virtualgl-users

Re: [VirtualGL-Users] ERROR: in FBX -- XCopyArea symbol not loaded

[DRC <dco...@us...>]

Which version of VirtualGL?  That is literally the most important detail 
to include in any bug report.

Also, if you're observing that '-c proxy' performs better than the 
default '-c jpeg', then something is terribly wrong.  "Proxy mode" is 
intended for X proxies, e.g. TurboVNC.  It sends the images uncompressed 
through the X11 protocol, which means that, even on gigabit, the most 
you'll see is 30 Megapixels/sec (JPEG can easily achieve twice that on a 
100 Mbit network.)

Also, just to clarify, '-c proxy' fails only with Cygwin but works with 
TurboVNC?  Definitely something amiss there as well.  You're going to 
need to provide a lot more details before I can even begin to figure out 
what's going on.


On 9/3/15 2:28 PM, Michael Mirsky wrote:
> Hello,
>
> I’m new to VirtualGL and I’ve been testing it with my Qt5 app. For the
> most part, it works flawlessly! However, I have run into one issue.
> Specifically, my build of VirtualGL fails with the following error if I
> try to launch my app with the “-c proxy” compression option:
>
> [VGL] ERROR: in FBX—
>
> [VGL]         510: [FBX] ERROR: XCopyArea symbol not loaded
>
> Any ideas of what this error means or what I might have missed during
> compilation? Running with “-c rgb” or the default works.
>
> I first tested with the “official” VirtualGL binary package, and vglrun
> with the “-c proxy” option performs with the least lag. Thus, it would
> be nice to combine that with the xcb interposer so that resize works.
>
> As some background, my VirtualGL server is running on Linux (RHEL6) and
> my client is Windows with Cygwin\X. I’ve tested using TurboVNC and that
> works great, but I’d prefer to get Cygwin\X to work if possible.

[VirtualGL-Users] ERROR: in FBX -- XCopyArea symbol not loaded

[Michael M. <mm...@po...>]

Hello,

I'm new to VirtualGL and I've been testing it with my Qt5 app. For the most part, it works flawlessly! However, I have run into one issue. Specifically, my build of VirtualGL fails with the following error if I try to launch my app with the "-c proxy" compression option:

[VGL] ERROR: in FBX-
[VGL]         510: [FBX] ERROR: XCopyArea symbol not loaded

Any ideas of what this error means or what I might have missed during compilation? Running with "-c rgb" or the default works.

I first tested with the "official" VirtualGL binary package, and vglrun with the "-c proxy" option performs with the least lag. Thus, it would be nice to combine that with the xcb interposer so that resize works.

As some background, my VirtualGL server is running on Linux (RHEL6) and my client is Windows with Cygwin\X. I've tested using TurboVNC and that works great, but I'd prefer to get Cygwin\X to work if possible.

Thanks!

Re: [VirtualGL-Users] Starting non-interactive remote program

[Heiko K. <Hei...@me...>]

Hi,

thanks for your new script, but I didn't get it working:

heikok@pc4027:~$ bash ./vglconnect -s -C -e "vglrun tseries" vglserver1

VirtualGL Client 64-bit v2.4 (Build 20150126)
vglclient is already running on this X display and accepting unencrypted
   connections on port 4242.

Making preliminary SSH connection to find a free port on the server ...
Bad escape character 'vglrun tseries'.
[VGL] ERROR: The server does not appear to have VirtualGL 2.1 or later
[VGL]    installed.




Ah, wait, after a bit of debugging:


heikok@pc4027:~$ bash ./vglconnect -s -e "vglrun tseries" -C vglserver1

-s and -e are vglconnect options, -C is an ssh option and will stop any
other vglconnect options. Since the order of options is so important, it
might be a good idea to add a debug line like

Runnging vglconnect with options '-s -e "vglrun tseries"' on
  ssh command with options  '-C vglserver1'

My attached version adds these debug-lines.


Heiko




On 2015-08-15 00:07, DRC wrote:
> This already works if you don't use the -s switch to vglconnect.  Why
> it's failing with -s is that -s causes vglconnect to run vgllogin on the
> server, so any additional arguments are interpreted as SSH options
> instead of as a remote command.  I added a new vglconnect option, per
> your suggestion, that allows you to specify a program to run on the server:
> 
> e.g.
> vglconnect -s -C -e 'vglrun /opt/VirtualGL/bin/glxspheres64' myserver
> 
> New script is attached.  Let me know if it works, and if so, I'll check
> it in.
> 
> 
> On 8/5/15 6:43 AM, DRC wrote:
>> I don't think it would be very difficult to add that functionality,
>> given that vglconnect is basically just a wrapper for SSH. Let me look
>> at it further and get back to you.
>>
>>> On Aug 5, 2015, at 3:15 AM, Heiko Klein <Hei...@me...> wrote:
>>>
>>> Hi,
>>>
>>> we're currently successfully using vgl to start our applications like:
>>>
>>> myclient$ vglconnect -s -C myserver
>>> myserver$ vglrun glprog
>>>
>>>
>>> We cannot sell our users a program which requires using the
>>> command-line, so we need to create a startup button. Thus we need a
>>> non-interactive startup of 'vglrun glprog', e.g. (not working!)
>>>
>>> myclient$ vglconnect -s -C myserver vglrun glprog
>>>
>>>
>>>
>>> Does there exist a vgl-program/option which allows starting
>>> vglconnect/vglrun from the client-machine?
>>>
>>>
>>> If not, is there some interest to add that functionality, e.g.
>>>
>>> myclient$ vglconnect -s -C  -E 'glprog' myserver
>>>
>>>
>>> (I checked the vglconnect/vgllogins skript and it doesn't seem to hard
>>> to add these parameters, so I could volunteer.)
>>>
>>>
>>> Best regards,
>>>
>>> Heiko
> 
> 
> 
> ------------------------------------------------------------------------------
> 
> 
> 
> _______________________________________________
> VirtualGL-Users mailing list
> Vir...@li...
> https://lists.sourceforge.net/lists/listinfo/virtualgl-users
> 

-- 
Dr. Heiko Klein                   Norwegian Meteorological Institute
Tel. + 47 22 96 32 58             P.O. Box 43 Blindern
http://www.met.no                 0313 Oslo NORWAY

[VirtualGL-Users] Signed binaries

[DRC <dco...@us...>]

All of the VirtualGL binaries back to 2.3 have been digitally signed.

See

http://www.virtualgl.org/Downloads/DigitalSignatures

for instructions on how to verify the signatures.

Re: [VirtualGL-Users] Starting non-interactive remote program

[DRC <dco...@us...>]

This already works if you don't use the -s switch to vglconnect.  Why 
it's failing with -s is that -s causes vglconnect to run vgllogin on the 
server, so any additional arguments are interpreted as SSH options 
instead of as a remote command.  I added a new vglconnect option, per 
your suggestion, that allows you to specify a program to run on the server:

e.g.
vglconnect -s -C -e 'vglrun /opt/VirtualGL/bin/glxspheres64' myserver

New script is attached.  Let me know if it works, and if so, I'll check 
it in.


On 8/5/15 6:43 AM, DRC wrote:
> I don't think it would be very difficult to add that functionality, given that vglconnect is basically just a wrapper for SSH. Let me look at it further and get back to you.
>
>> On Aug 5, 2015, at 3:15 AM, Heiko Klein <Hei...@me...> wrote:
>>
>> Hi,
>>
>> we're currently successfully using vgl to start our applications like:
>>
>> myclient$ vglconnect -s -C myserver
>> myserver$ vglrun glprog
>>
>>
>> We cannot sell our users a program which requires using the
>> command-line, so we need to create a startup button. Thus we need a
>> non-interactive startup of 'vglrun glprog', e.g. (not working!)
>>
>> myclient$ vglconnect -s -C myserver vglrun glprog
>>
>>
>>
>> Does there exist a vgl-program/option which allows starting
>> vglconnect/vglrun from the client-machine?
>>
>>
>> If not, is there some interest to add that functionality, e.g.
>>
>> myclient$ vglconnect -s -C  -E 'glprog' myserver
>>
>>
>> (I checked the vglconnect/vgllogins skript and it doesn't seem to hard
>> to add these parameters, so I could volunteer.)
>>
>>
>> Best regards,
>>
>> Heiko

Re: [VirtualGL-Users] Starting non-interactive remote program

[DRC <dco...@us...>]

I don't think it would be very difficult to add that functionality, given that vglconnect is basically just a wrapper for SSH. Let me look at it further and get back to you.

> On Aug 5, 2015, at 3:15 AM, Heiko Klein <Hei...@me...> wrote:
> 
> Hi,
> 
> we're currently successfully using vgl to start our applications like:
> 
> myclient$ vglconnect -s -C myserver
> myserver$ vglrun glprog
> 
> 
> We cannot sell our users a program which requires using the 
> command-line, so we need to create a startup button. Thus we need a 
> non-interactive startup of 'vglrun glprog', e.g. (not working!)
> 
> myclient$ vglconnect -s -C myserver vglrun glprog
> 
> 
> 
> Does there exist a vgl-program/option which allows starting 
> vglconnect/vglrun from the client-machine?
> 
> 
> If not, is there some interest to add that functionality, e.g.
> 
> myclient$ vglconnect -s -C  -E 'glprog' myserver
> 
> 
> (I checked the vglconnect/vgllogins skript and it doesn't seem to hard 
> to add these parameters, so I could volunteer.)
> 
> 
> Best regards,
> 
> Heiko
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> VirtualGL-Users mailing list
> Vir...@li...
> https://lists.sourceforge.net/lists/listinfo/virtualgl-users

[VirtualGL-Users] Starting non-interactive remote program

[Heiko K. <Hei...@me...>]

Hi,

we're currently successfully using vgl to start our applications like:

myclient$ vglconnect -s -C myserver
myserver$ vglrun glprog


We cannot sell our users a program which requires using the 
command-line, so we need to create a startup button. Thus we need a 
non-interactive startup of 'vglrun glprog', e.g. (not working!)

myclient$ vglconnect -s -C myserver vglrun glprog



Does there exist a vgl-program/option which allows starting 
vglconnect/vglrun from the client-machine?


If not, is there some interest to add that functionality, e.g.

myclient$ vglconnect -s -C  -E 'glprog' myserver


(I checked the vglconnect/vgllogins skript and it doesn't seem to hard 
to add these parameters, so I could volunteer.)


Best regards,

Heiko

[VirtualGL-Users] VirtualGL code migration to GitHub is complete

[DRC <dco...@us...>]

I'm not sure whether all of my previous messages regarding the 
SourceForge outage got through, so forgive me if any of this is old news.

Let me start by saying that I think (hope) that the rumors of 
SourceForge's demise have been greatly exaggerated.  They have largely 
owned up to their mistakes regarding the DevShare program and have taken 
steps to mitigate misleading ads (i.e. ads with fake download buttons) 
that were being served up by Google.  I also feel that they handled this 
outage in the best way they could.  I've been using SourceForge since 
2004-- you know, back when they were in pretty much exactly the same 
position that GitHub is in now.  I've been around this block enough 
times to be wary of jumping onto the latest & greatest platform just 
because it's the latest & greatest.

That being said, while I have had no major issues with SourceForge 
(before now), this outage made me finally admit that the advantages of a 
DVCS (such as git) far outweigh the pain of learning a new system.  To 
that end, I took advantage of the downtime to get familiar enough with 
Git that I can be productive with it.  When our subversion repository 
came back online on Sunday, I immediately started the (somewhat 
painstaking) task of migrating our code to GitHub.  I could just as 
easily have migrated it to SourceForge's Git or Hg servers, but I am a 
believer in using the best tool for the job.  Part of maintaining a 
healthy open source community is making it easy for developers to 
contribute, and GitHub's popularity and rich collaboration tools make it 
a clear winner in that department.

The code migration is now complete, and you can find our main repository at:
https://github.com/VirtualGL/virtualgl

Supporting repositories (build scripts, etc.) can be found at
https://github.com/VirtualGL

Please update any sandboxes you may have.  The subversion repository is 
frozen and will eventually be decommissioned.

The following provides a comprehensive list of project services and 
where to find them, going forward:

-- Code hosting:  GitHub only (https://github.com/VirtualGL/virtualgl)
    I double-checked and triple-checked the new repository against the 
old, but please let me know if you find any issues with it.

-- Issue/feature tracking:  Either GitHub 
(https://github.com/VirtualGL/virtualgl/issues) or SourceForge 
(https://sourceforge.net/p/virtualgl/_list/tickets)
    There are advantages and disadvantages to both (for instance, you 
can't attach files with GitHub), so for the time being at least, use 
whichever one you prefer.  I have moved the open feature requests to 
GitHub, but all other items are still on SourceForge.  If, at some point 
in the future, the SourceForge tracker stops being used or the GitHub 
tracker improves its feature set, I will consider freezing the SF tracker.

-- Patches:  Either GitHub 
(https://github.com/VirtualGL/virtualgl/pulls) or SourceForge 
(https://sourceforge.net/p/virtualgl/patches/)
    If, at some point in the future, the SourceForge tracker stops being 
used, I will consider freezing it.

-- Official Releases:  SourceForge 
(https://sourceforge.net/projects/virtualgl/files/)
    My automated pre-release and release scripts are heavily tied to the 
SourceForge file release system, I like certain features of that system 
(such as the statistics it provides), and there are a lot of links to 
those files out there, so at least for now, I will continue using 
SourceForge to distribute official releases.  I will, however, sign all 
RPMs and DEBs on that site with my GPG key and all Windows installers 
with my code signing certificate, in order to ease any concerns about 
binary tampering.  Look for a follow-up message announcing the 
completion of that project (SourceForge has not yet restored the file 
upload and SSH features, so access to the file release system is 
currently read-only.)
    This article 
http://michaeltunnell.com/blog/15-miscellaneous/53-14-potential-alternatives-to-sourceforge-for-binary-downloads 
echoes my thoughts on the decision to stick with SF for file releases.
    Note that GitHub includes metadata and automatically-generated 
tarballs for all of the release tags 
(https://github.com/VirtualGL/virtualgl/releases.)  For VirtualGL 2.0 
and newer, these tarballs should match the ones on SourceForge (the 
pre-2.0 tarballs on GitHub are missing the license files, due to an 
issue with the old CVS repository that was never resolved prior to 
converting it to subversion.)

-- Web site:  hosted on an external web server (http://www.VirtualGL.org)
    All of the links mentioned in this message can be found there.

-- Mailing lists:  SourceForge 
(https://sourceforge.net/p/virtualgl/mailman/)

-- Discussion forums:  SourceForge 
(https://sourceforge.net/p/virtualgl/discussion/)


As always, please send me any questions or concerns you may have.

DRC

Re: [VirtualGL-Users] VirtualGL - reduce bandwidth with compression

[Marco M. <mar...@gm...>]

2015-06-15 22:17 GMT+02:00 DRC <dco...@us...>:

> If you have any further questions of this nature, please send them to
> VirtualGL-Devel, not to this list.
>
> Ok, sorry. Next questions on VirtualGL-Devel



>
> On 6/15/15 3:07 PM, Marco Marino wrote:
> > Hi Nathan, thank you for your answer.
> > I read the code of the plugin (a good way to fun in the sunday....)....
> > some consideration and few questions here:
> >
> > - in server/testplugin.cpp there are 2 functions, RRTransSendFrame and
> > RRTransGetFrame. These 2 functions should be the important part of the
> > transport plugin because they are called respectively from the server
> > and the client, right?
>
> No, they are both called from the server.  VirtualGL calls
> RRTransGetFrame() in order to get a new frame from the plugin, and it
> calls RRTransSendFrame() to send it.
>
> Ok, but now: where is the "receive" part?



>
> > - In RRTransSendFrame i have "vglconn->sendFrame". But vglconn is the
> > "handle" and hence is the VGLTrans() (in the case of testplugin.cpp, so
> > i think the important part of the sendFrame resides in the VGLTrans
> > class. But the VGLTrans class calls _VGLTrans_spoilfct method and it
> > seems that lock and the unlock the thread using the method
> > signalComplete. What happens here? I don't understand the signalComplete
> > method. Can you help me please?
>
> The test plugins use the existing transport classes (VGLTrans for the
> VGL Transport, or X11Trans for the X11 Transport.)  Your plugin will be
> providing its own transport, so you should not use those existing
> transport classes, although you might want to base your own transport
> class on one of them.  Please do not expect this to be a quick project.
>   You're going to have to spend many hours digging into how this stuff
> works before you can successfully write your own transport.
>

I do not expect this to be a quick project and I'm happy to pass many hours
on the VirtualGL source code. This doesn't scare me.
However i need to first understand how VirtualGL works, and for this reason
i'm trying to read the testplugin code. My difficult is related to the
getFrame method inside the transport. Moreover, i need to understand the
"receive part" on the client.
I told that documentation is important because I want to avoid getting
bored with obvious questions. If I can ask many (also trivial) questions on
the VirtualGL-Devel, ok, i will do it. Unfortunately, for a beginner
VirtualGL is a difficult task.

Thanks,
MM


> > Thanks,
> > MM
> >
> >
> >
> > 2015-06-15 21:40 GMT+02:00 Nathan Kidd <nat...@sp...
> > <mailto:nat...@sp...>>:
> >
> >     On 13/06/15 09:56 AM, Marco Marino wrote:
> >     > I understand your point of view, but without any documentation
> (and a
> >     > bit of help) is impossible for me develop such transport plugin.
> >
> >     Hi Marco,
> >
> >     Having used the plugin API and put my own transport layer in VGL
> >     directly in the past, my free and unsolicited advice is:
> >
> >     1) using the API is simple, just copy the existing examples
> >
> >     2) if you're up for making H.264 work then the work to grok the
> plugin
> >     system is a minor blip in the workload.  Don't let lack of
> documentation
> >     stop you; you don't really need it.
> >
> >     Cheers,
> >
> >     -Nathan
> >
> >
>  ------------------------------------------------------------------------------
> >     _______________________________________________
> >     VirtualGL-Users mailing list
> >     Vir...@li...
> >     <mailto:Vir...@li...>
> >     https://lists.sourceforge.net/lists/listinfo/virtualgl-users
> >
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> >
> >
> >
> > _______________________________________________
> > VirtualGL-Users mailing list
> > Vir...@li...
> > https://lists.sourceforge.net/lists/listinfo/virtualgl-users
> >
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> VirtualGL-Users mailing list
> Vir...@li...
> https://lists.sourceforge.net/lists/listinfo/virtualgl-users
>

Re: [VirtualGL-Users] Fwd: virtualgl with a client running application

[DRC <dco...@us...>]

It is very unclear what you are trying to do, so please clarify.  I 
don't understand what a virtual machine or Android has to do with anything.

On 6/16/15 5:17 AM, Igor Itkin wrote:
> Hi all
> Do I understand correctly, that application should run on the server,
> and there is no way to run it on the client (I mean the application that
> installed on on client)
> We have virtual machine that can to run android somehow (emulation is
> very slow)
> In advance - thank you for an answer
> Best
> Igor (Yehuda)

[VirtualGL-Users] Fwd: virtualgl with a client running application

[Igor I. <ig....@gm...>]

Hi all
Do I understand correctly, that application should run on the server, and
there is no way to run it on the client (I mean the application that
installed on on client)
We have virtual machine that can to run android somehow (emulation is very
slow)
In advance - thank you for an answer
Best
Igor (Yehuda)

Re: [VirtualGL-Users] VirtualGL - reduce bandwidth with compression

[DRC <dco...@us...>]

If you have any further questions of this nature, please send them to 
VirtualGL-Devel, not to this list.


On 6/15/15 3:07 PM, Marco Marino wrote:
> Hi Nathan, thank you for your answer.
> I read the code of the plugin (a good way to fun in the sunday....)....
> some consideration and few questions here:
>
> - in server/testplugin.cpp there are 2 functions, RRTransSendFrame and
> RRTransGetFrame. These 2 functions should be the important part of the
> transport plugin because they are called respectively from the server
> and the client, right?

No, they are both called from the server.  VirtualGL calls 
RRTransGetFrame() in order to get a new frame from the plugin, and it 
calls RRTransSendFrame() to send it.


> - In RRTransSendFrame i have "vglconn->sendFrame". But vglconn is the
> "handle" and hence is the VGLTrans() (in the case of testplugin.cpp, so
> i think the important part of the sendFrame resides in the VGLTrans
> class. But the VGLTrans class calls _VGLTrans_spoilfct method and it
> seems that lock and the unlock the thread using the method
> signalComplete. What happens here? I don't understand the signalComplete
> method. Can you help me please?

The test plugins use the existing transport classes (VGLTrans for the 
VGL Transport, or X11Trans for the X11 Transport.)  Your plugin will be 
providing its own transport, so you should not use those existing 
transport classes, although you might want to base your own transport 
class on one of them.  Please do not expect this to be a quick project. 
  You're going to have to spend many hours digging into how this stuff 
works before you can successfully write your own transport.

> Thanks,
> MM
>
>
>
> 2015-06-15 21:40 GMT+02:00 Nathan Kidd <nat...@sp...
> <mailto:nat...@sp...>>:
>
>     On 13/06/15 09:56 AM, Marco Marino wrote:
>     > I understand your point of view, but without any documentation (and a
>     > bit of help) is impossible for me develop such transport plugin.
>
>     Hi Marco,
>
>     Having used the plugin API and put my own transport layer in VGL
>     directly in the past, my free and unsolicited advice is:
>
>     1) using the API is simple, just copy the existing examples
>
>     2) if you're up for making H.264 work then the work to grok the plugin
>     system is a minor blip in the workload.  Don't let lack of documentation
>     stop you; you don't really need it.
>
>     Cheers,
>
>     -Nathan
>
>     ------------------------------------------------------------------------------
>     _______________________________________________
>     VirtualGL-Users mailing list
>     Vir...@li...
>     <mailto:Vir...@li...>
>     https://lists.sourceforge.net/lists/listinfo/virtualgl-users
>
>
>
>
> ------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> VirtualGL-Users mailing list
> Vir...@li...
> https://lists.sourceforge.net/lists/listinfo/virtualgl-users
>

Re: [VirtualGL-Users] VirtualGL - reduce bandwidth with compression

[DRC <dco...@us...>]

Yes, I would say that figuring out the API is a bit of a "squirrel 
catcher"-- meaning that if you can't get past that part, you are 
unlikely to get very far with the rest of the project.  As Nathan said, 
the API is easy.  Figuring out how to make the plugin encode and stream 
H.264, communicate with the client, etc. is going to be the hard part.

On 6/15/15 2:40 PM, Nathan Kidd wrote:
> On 13/06/15 09:56 AM, Marco Marino wrote:
>> I understand your point of view, but without any documentation (and a
>> bit of help) is impossible for me develop such transport plugin.
>
> Hi Marco,
>
> Having used the plugin API and put my own transport layer in VGL
> directly in the past, my free and unsolicited advice is:
>
> 1) using the API is simple, just copy the existing examples
>
> 2) if you're up for making H.264 work then the work to grok the plugin
> system is a minor blip in the workload.  Don't let lack of documentation
> stop you; you don't really need it.
>
> Cheers,
>
> -Nathan

Re: [VirtualGL-Users] VirtualGL - reduce bandwidth with compression

[Marco M. <mar...@gm...>]

Hi Nathan, thank you for your answer.
I read the code of the plugin (a good way to fun in the sunday....)....
some consideration and few questions here:

- in server/testplugin.cpp there are 2 functions, RRTransSendFrame and
RRTransGetFrame. These 2 functions should be the important part of the
transport plugin because they are called respectively from the server and
the client, right?
- In RRTransSendFrame i have "vglconn->sendFrame". But vglconn is the
"handle" and hence is the VGLTrans() (in the case of testplugin.cpp, so i
think the important part of the sendFrame resides in the VGLTrans class.
But the VGLTrans class calls _VGLTrans_spoilfct method and it seems that
lock and the unlock the thread using the method signalComplete. What
happens here? I don't understand the signalComplete method. Can you help me
please?

Thanks,
MM



2015-06-15 21:40 GMT+02:00 Nathan Kidd <nat...@sp...>:

> On 13/06/15 09:56 AM, Marco Marino wrote:
> > I understand your point of view, but without any documentation (and a
> > bit of help) is impossible for me develop such transport plugin.
>
> Hi Marco,
>
> Having used the plugin API and put my own transport layer in VGL
> directly in the past, my free and unsolicited advice is:
>
> 1) using the API is simple, just copy the existing examples
>
> 2) if you're up for making H.264 work then the work to grok the plugin
> system is a minor blip in the workload.  Don't let lack of documentation
> stop you; you don't really need it.
>
> Cheers,
>
> -Nathan
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> VirtualGL-Users mailing list
> Vir...@li...
> https://lists.sourceforge.net/lists/listinfo/virtualgl-users
>

Re: [VirtualGL-Users] VirtualGL - reduce bandwidth with compression

[Nathan K. <nat...@sp...>]

On 13/06/15 09:56 AM, Marco Marino wrote:
> I understand your point of view, but without any documentation (and a
> bit of help) is impossible for me develop such transport plugin.

Hi Marco,

Having used the plugin API and put my own transport layer in VGL
directly in the past, my free and unsolicited advice is:

1) using the API is simple, just copy the existing examples

2) if you're up for making H.264 work then the work to grok the plugin
system is a minor blip in the workload.  Don't let lack of documentation
stop you; you don't really need it.

Cheers,

-Nathan

Re: [VirtualGL-Users] VirtualGL 2.4.1 has been released

[Morgan R. <mor...@ro...>]

Thank you very much for your response. That makes perfect sense, I had
forgot about all that Sourceforge offered, and I've never really thought
critically of github but its the not and end all be all. Thank you again.

On Fri, Jun 12, 2015 at 4:03 PM, DRC <dco...@us...>
wrote:

> What "recent behavior"?  I've been hosting VirtualGL and TurboVNC on SF
> for 10+ years, and apart from a little bit of growing pain associated
> with migrating to Allura, I've had no major issues with that platform.
> Github is hot right now, but in the 20 years I've been doing
> professional software development, I've seen sites like that come and
> go.  Give it a couple of more years before I fully trust it.
>
> Github definitely does do a lot of things better than SourceForge.  I
> love its web interface-- I just wish it weren't built around git.  :)  I
> just can't stand working with git on a day-to-day basis.  It's very
> non-intuitive for me, and this article echoes a few of the reasons why:
>
> http://www.peterlundgren.com/blog/on-gits-shortcomings/
>
> On the rare occasions that I've tried to do any serious development with
> git, I've managed to screw things up pretty badly, mostly vis-a-vis
> branching and merging (managed to accidentally delete hours of work on
> more than one occasion.)  I am just more comfortable with a centralized
> repository and a bare-metal connection with the revision control server.
>   When I tell subversion to do something, I am confident that it does
> exactly what I instruct.  When I check something in, I'm confident that
> it is stored in the database and can't be accidentally deleted.  Git
> seems to want to second-guess me too much.  I find some operations in
> git (such as merging) to be more difficult than they really should be.
> There are some workflows for which I prefer using git-svn as a client,
> but I prefer subversion on the back end, and I usually prefer it as a
> client as well.  I am used to working with revision numbers.  I like
> being able to edit revision logs after the fact, if information changed
> that was relevant to the revision.
>
> I get why it's a lot easier to collaborate with git, but with a project
> like this that has one main developer and only one or two occasional
> contributors, there is no real need for that kind of collaboration.  I
> don't think moving to github would make VirtualGL developers magically
> appear.  It's a niche product, at the end of the day.
>
> Also, I like the integrated nature of SourceForge, in that we can host
> mailing lists and discussion forums and bug trackers and file releases
> and revision control from the same site.
>
>
> On 6/12/15 3:47 PM, Morgan Ross wrote:
> > Have you considered migrating to github from sourceforge, in light of
> > their recent behavior? Sorry if this has already been addressed.
> >
> > On Fri, Jun 12, 2015 at 8:19 AM, DRC <dco...@us...
> > <mailto:dco...@us...>> wrote:
> >
> >     http://sourceforge.net/projects/virtualgl/files/2.4.1/
> >
> >     Packaging changes:
> >     These packages were built with libjpeg-turbo 1.4.1:
> >     http://sourceforge.net/projects/libjpeg-turbo/files/1.4.1/
> >     This improves performance on 64-bit Mac clients, relative to
> >     VirtualGL 2.4.
> >
> >     Significant changes since 2.4:
> >
> >     [1] When an application doesn't explicitly specify its visual
> >     requirements by calling glXChooseVisual()/glXChooseFBConfig(), the
> >     default GLX framebuffer config that VirtualGL assigns to it now
> contains
> >     a stencil buffer.  This eliminates the need to specify
> >     VGL_DEFAULTFBCONFIG=GLX_STENCIL_SIZE,8 with certain applications
> >     (previously necessary when running Abaqus v6 and MAGMA5.)
> >
> >     [2] VirtualGL will no longer advertise that it supports the
> >     GLX_ARB_create_context and GLX_ARB_create_context_profile extensions
> >     unless the underlying OpenGL library exports the
> >     glXCreateContextAttribsARB() function.
> >
> >     [3] Fixed "Invalid MIT-MAGIC-COOKIE-1" errors that would prevent
> >     VirtualGL from working when vglconnect was used to connect to a
> >     VirtualGL server from a client running Cygwin/X.
> >
> >     [4] If a 3D application is rendering to the front buffer and one of
> the
> >     end-of-frame trigger functions (glFlush()/glFinish()/glXWaitGL()) is
> >     called, VirtualGL will no longer read back the framebuffer unless the
> >     render mode is GL_RENDER.  Reading back the front buffer when the
> render
> >     mode is GL_SELECT or GL_FEEDBACK is not only unnecessary, but it was
> >     known to cause a GLXBadContextState error with newer nVidia drivers
> >     (340.xx and later) in certain cases.
> >
> >     [5] Fixed a deadlock that occurred in the multi-threaded rendering
> test
> >     of fakerut when it was run with the XCB interposer enabled.  This was
> >     due to VirtualGL attempting to handle XCB events when Xlib owned the
> >     event queue.  It is possible that this issue affected or would have
> >     affected real-world applications as well.
> >
> >     [6] Fixed an issue that caused certain 3D applications (observed with
> >     CAESES/FFW, although others were possibly affected as well) to abort
> >     with "ERROR: in TempContext-- Could not bind OpenGL context to window
> >     (window may may have disappeared)".  When the 3D application called
> >     glXChooseVisual(), VirtualGL was choosing a corresponding FB config
> with
> >     GLX_DRAWABLE_TYPE=GLX_PBUFFER_BIT (assuming that
> VGL_DRAWABLE=pbuffer,
> >     which is the default.)  This is incorrect, however, because
> regardless
> >     of the value of VGL_DRAWABLE, VirtualGL still uses Pixmaps on the 3D
> X
> >     server to represent GLX Pixmaps (necessary in order to make
> >     GLX_EXT_texture_from_pixmap work properly.)  Thus, VGL needs to
> choose
> >     an FB config that supports both Pbuffers and Pixmaps.  This was
> >     generally only a problem with nVidia drivers, because they export
> >     different FB configs for GLX_PBUFFER_BIT and
> >     GLX_PBUFFER_BIT|GLX_PIXMAP_BIT.
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> VirtualGL-Users mailing list
> Vir...@li...
> https://lists.sourceforge.net/lists/listinfo/virtualgl-users
>

Re: [VirtualGL-Users] VirtualGL - reduce bandwidth with compression

[Marco M. <mar...@gm...>]

I understand your point of view, but without any documentation (and a bit
of help) is impossible for me develop such transport plugin. Actually i'm
also working (part-time) for an ISP as openstack administrator, so i do not
have much time. VirtualGL is an interesting software for the cloud, because
my (personal) idea is that in the future also GPU will be an integrated
part of vms. So i need a way to stream 3d applications and VirtualGL is
fantastic (except for the bandwidth). Another (personal) idea is that in
the near (i hope) future, OpenGL will be re-evaluated for what it is: the
best API for 3d in the world.
So, if you find a little time, please reconsider the idea of expand the
documentation of virtualgl for developers and make more easy the transport
plugin development.
Thanks,
MM


2015-06-13 0:23 GMT+02:00 DRC <dco...@us...>:

> No, the plugin framework was developed specifically for a customer.  The
> only documentation for it is in the API headers.  I wish I could be of
> more help.  This project interests me, but the only way I make money is
> by consulting and doing custom development for companies regarding
> VirtualGL and TurboVNC (and occasionally libjpeg-turbo), so I just can't
> devote a lot of free time to research projects like this, particularly
> given that gaming companies historically haven't been money makers for me.
>
>
> On 6/12/15 4:13 PM, Marco Marino wrote:
> > Ok, thanks. Is there some technical documentation for virtualgl
> > developers? I need to understand the code, if i have to write a plugin.
> > And the code is not trivial. I have no experience, and i never read
> > virtualgl code before.
> > However, thanks again for you answers.
> > MM
> >
> > 2015-06-12 22:42 GMT+02:00 DRC <dco...@us...
> > <mailto:dco...@us...>>:
> >
> >     OK, then yes, with the qualifications that you mention (a workload
> that
> >     updates a predictable area of the screen in a predictable way, i.e.
> >     games & video applications; low-bandwidth; reasonable image quality),
> >     then a video codec such as H.264 is definitely going to be the best
> >     solution.
> >
> >     I am working with some engineers at nVidia to look into how to
> integrate
> >     H.264 with VirtualGL and TurboVNC, but we are still just bouncing
> ideas
> >     around at this point.  I don't know if we'll come up with anything
> >     concrete in the timeframe you need.  And since you're a student,
> writing
> >     a transport plugin would be a good exercise.
> >
> >     Study testplugin.cpp.  Some things you'll have to consider:
> >
> >     -- how to handle the delivery of images over the network.  The VGL
> >     Transport is really designed for use along with a remote X server, so
> >     it's probably not the right protocol for you to use.  What would be
> >     Really Cool(TM) is if you could leverage an existing streaming video
> >     protocol.
> >
> >     -- how to handle the delivery of keyboard/mouse events from the
> client
> >     to the server.  When you're dealing with an immersive application,
> such
> >     as a game, for which window and GUI management are irrelevant, you
> could
> >     do something clever, such as using an Xvfb instance on the server
> side
> >     to act as a 2D X server.  Xvfb would be used solely for event
> >     management.  Your plugin would intercept keyboard/mouse events from
> the
> >     client and inject them into the Xvfb instance so that the 3D
> application
> >     will receive them via its X event queue.  No actual pixels will be
> drawn
> >     into that X server-- the pixels will be intercepted by the VGL plugin
> >     and sent directly to the client.
> >
> >     You are not required to open source any of your work (VGL plugins
> can be
> >     proprietary), but if you choose to do so, I'll be happy to review it
> for
> >     possible inclusion in VirtualGL.
> >
> >     Also, you should investigate whether libx264 is a faster solution
> than
> >     FFmpeg for compressing H.264.
> >
> >     Please feel free to ask follow-up questions on the virtualgl-devel
> list.
> >
> >
> >     On 6/12/15 12:17 PM, Marco Marino wrote:
> >     > Thanks for your answer.
> >     > As you told "H.264 doesn't benefit all applications-- mainly it
> will
> >     > only improve the situation for games and other very video-like
> >     > workloads". And this is my purpose! I need a reliable, high latency
> >     > network compatible "transport". I'm interested in gaming, and video
> >     > reproduction but i want (!)  to use linux, and i thought that
> VirtualGL
> >     > could be an option.
> >     > Use a low JPEG quality is not a solution for me, I need good image
> quality.
> >     > Write a transport plugin could be a solution? What i have to study
> >     > before I can write a transport plugin? Have you some example (yes,
> i
> >     > know testplugin.cpp) ?
> >     > Thank you,
> >     > MM
> >     >
> >     > 2015-05-27 9:42 GMT+02:00 DRC <dco...@us...
> >     <mailto:dco...@us...>
> >     > <mailto:dco...@us...
> >     <mailto:dco...@us...>>>:
> >     >
> >     >     Depending on what you really need to do, it may not be
> necessary to get
> >     >     that fancy.  Most users of VirtualGL use it with an X11
> proxy.  TurboVNC
> >     >     is the X proxy that our project provides and which has
> features and
> >     >     performance specifically targeted at 3D applications, but
> there are
> >     >     other X proxies that work with VGL as well (although usually
> not as fast
> >     >     as TurboVNC.)  The X proxy, when combined with VirtualGL, will
> cause all
> >     >     of the 2D (X11) as well as 3D (OpenGL) rendering commands from
> the
> >     >     application to be rendered on the server and sent to the
> client as image
> >     >     updates.  TurboVNC specifically has a feature called
> "automatic lossless
> >     >     refresh", which allows you to use a very low JPEG quality for
> most
> >     >     updates, but when the server senses that you have stopped
> moving things
> >     >     around (such as when you stop rotating a 3D scene, etc.), it
> will send a
> >     >     lossless update of the screen.  X proxies also do a much
> better job of
> >     >     handling high-latency networks, since they are sending more
> >     >     coarse-grained image updates instead of very fine-grained and
> chatty X11
> >     >     updates over the network.
> >     >
> >     >     VirtualGL can also operate without an X proxy, but this is
> less useful
> >     >     on high-latency networks, because it requires that the
> non-3D-related
> >     >     X11 commands be sent over the network to the client machine.
> Even
> >     >     though the 3D-related X11 commands are being redirected by
> VirtualGL and
> >     >     are being rendered on the server, the 2D-related X11 commands
> used to
> >     >     draw the application GUI, etc. are still sent over the
> network, and that
> >     >     can create performance problems on wide-area networks.
> >     >
> >     >     Now, to more specifically answer your question-- you can
> reduce the JPEG
> >     >     quality in VirtualGL, which will significantly reduce the
> bandwidth.
> >     >     Using TurboVNC will likely reduce the bandwidth as well, not
> only
> >     >     because the X11 stuff is being rendered on the server but
> because
> >     >     TurboVNC has a more adaptive compression scheme, whereas
> VirtualGL uses
> >     >     plain motion-JPEG.  I'm currently working with nVidia to
> research
> >     >     possible ways of leveraging their NVENC library to do H.264
> compression
> >     >     in VirtualGL, but there are a lot of technical hurdles we
> haven't
> >     >     figured out yet vis-a-vis how that would interact with X
> proxies such as
> >     >     TurboVNC.  Also, H.264 doesn't benefit all applications--
> mainly it will
> >     >     only improve the situation for games and other very video-like
> >     >     workloads.  More tradition 3D applications (CAD,
> visualization, etc.)
> >     >     are already quite optimal with TurboVNC's existing compression
> scheme.
> >     >
> >     >     VirtualGL does have a transport plugin API, so you could
> conceivably use
> >     >     that to write your own transport plugin based on the existing
> VGL
> >     >     Transport code (see server/testplugin.cpp for an example) but
> which uses
> >     >     ffmpeg instead of libjpeg-turbo to do the 3D image
> compression.  Whether
> >     >     or not that would really improve bandwidth usage would depend
> a lot on
> >     >     your specific workload.
> >     >
> >     >
> >     >     On 5/27/15 1:31 AM, Marco Marino wrote:
> >     >     > Hi,
> >     >     > i'm a student and i'm trying virtualgl for education
> purposes. From my
> >     >     > tests with vglrun I saw that huge amount of bandwidth is
> required for
> >     >     > acceptable image quality (eg: -c jpeg with quality 90
> requires peaks of
> >     >     > 50/60 Mbits). Is there a way to compress the video flow? Can
> i do
> >     >     > something like: "VGLSOCKET" -> My compression library (like
> ffmpeg or
> >     >     > similar) -> TCP/UDP socket ? In practice i want try to
> compress with my
> >     >     > own code the output of VGL. Is this possible? I'm sorry if
> this is a
> >     >     > stupid question, but I don't have knowledge about virtualgl.
> >     >     > Thanks
> >     >
> >     >
>  ------------------------------------------------------------------------------
> >     >     _______________________________________________
> >     >     VirtualGL-Users mailing list
> >     >Vir...@li...
> >     <mailto:Vir...@li...>
> >     >     <mailto:Vir...@li...
> >     <mailto:Vir...@li...>>
> >     >https://lists.sourceforge.net/lists/listinfo/virtualgl-users
> >     >
> >     >
> >     >
> >     >
> >     >
> ------------------------------------------------------------------------------
> >     >
> >     >
> >     >
> >     > _______________________________________________
> >     > VirtualGL-Users mailing list
> >     >Vir...@li...
> >     <mailto:Vir...@li...>
> >     >https://lists.sourceforge.net/lists/listinfo/virtualgl-users
> >     >
> >
> >
>  ------------------------------------------------------------------------------
> >     _______________________________________________
> >     VirtualGL-Users mailing list
> >     Vir...@li...
> >     <mailto:Vir...@li...>
> >     https://lists.sourceforge.net/lists/listinfo/virtualgl-users
> >
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> >
> >
> >
> > _______________________________________________
> > VirtualGL-Users mailing list
> > Vir...@li...
> > https://lists.sourceforge.net/lists/listinfo/virtualgl-users
> >
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> VirtualGL-Users mailing list
> Vir...@li...
> https://lists.sourceforge.net/lists/listinfo/virtualgl-users
>

Re: [VirtualGL-Users] VirtualGL 2.4.1 has been released

[DRC <dco...@us...>]

What "recent behavior"?  I've been hosting VirtualGL and TurboVNC on SF 
for 10+ years, and apart from a little bit of growing pain associated 
with migrating to Allura, I've had no major issues with that platform. 
Github is hot right now, but in the 20 years I've been doing 
professional software development, I've seen sites like that come and 
go.  Give it a couple of more years before I fully trust it.

Github definitely does do a lot of things better than SourceForge.  I 
love its web interface-- I just wish it weren't built around git.  :)  I 
just can't stand working with git on a day-to-day basis.  It's very 
non-intuitive for me, and this article echoes a few of the reasons why:

http://www.peterlundgren.com/blog/on-gits-shortcomings/

On the rare occasions that I've tried to do any serious development with 
git, I've managed to screw things up pretty badly, mostly vis-a-vis 
branching and merging (managed to accidentally delete hours of work on 
more than one occasion.)  I am just more comfortable with a centralized 
repository and a bare-metal connection with the revision control server. 
  When I tell subversion to do something, I am confident that it does 
exactly what I instruct.  When I check something in, I'm confident that 
it is stored in the database and can't be accidentally deleted.  Git 
seems to want to second-guess me too much.  I find some operations in 
git (such as merging) to be more difficult than they really should be. 
There are some workflows for which I prefer using git-svn as a client, 
but I prefer subversion on the back end, and I usually prefer it as a 
client as well.  I am used to working with revision numbers.  I like 
being able to edit revision logs after the fact, if information changed 
that was relevant to the revision.

I get why it's a lot easier to collaborate with git, but with a project 
like this that has one main developer and only one or two occasional 
contributors, there is no real need for that kind of collaboration.  I 
don't think moving to github would make VirtualGL developers magically 
appear.  It's a niche product, at the end of the day.

Also, I like the integrated nature of SourceForge, in that we can host 
mailing lists and discussion forums and bug trackers and file releases 
and revision control from the same site.


On 6/12/15 3:47 PM, Morgan Ross wrote:
> Have you considered migrating to github from sourceforge, in light of
> their recent behavior? Sorry if this has already been addressed.
>
> On Fri, Jun 12, 2015 at 8:19 AM, DRC <dco...@us...
> <mailto:dco...@us...>> wrote:
>
>     http://sourceforge.net/projects/virtualgl/files/2.4.1/
>
>     Packaging changes:
>     These packages were built with libjpeg-turbo 1.4.1:
>     http://sourceforge.net/projects/libjpeg-turbo/files/1.4.1/
>     This improves performance on 64-bit Mac clients, relative to
>     VirtualGL 2.4.
>
>     Significant changes since 2.4:
>
>     [1] When an application doesn't explicitly specify its visual
>     requirements by calling glXChooseVisual()/glXChooseFBConfig(), the
>     default GLX framebuffer config that VirtualGL assigns to it now contains
>     a stencil buffer.  This eliminates the need to specify
>     VGL_DEFAULTFBCONFIG=GLX_STENCIL_SIZE,8 with certain applications
>     (previously necessary when running Abaqus v6 and MAGMA5.)
>
>     [2] VirtualGL will no longer advertise that it supports the
>     GLX_ARB_create_context and GLX_ARB_create_context_profile extensions
>     unless the underlying OpenGL library exports the
>     glXCreateContextAttribsARB() function.
>
>     [3] Fixed "Invalid MIT-MAGIC-COOKIE-1" errors that would prevent
>     VirtualGL from working when vglconnect was used to connect to a
>     VirtualGL server from a client running Cygwin/X.
>
>     [4] If a 3D application is rendering to the front buffer and one of the
>     end-of-frame trigger functions (glFlush()/glFinish()/glXWaitGL()) is
>     called, VirtualGL will no longer read back the framebuffer unless the
>     render mode is GL_RENDER.  Reading back the front buffer when the render
>     mode is GL_SELECT or GL_FEEDBACK is not only unnecessary, but it was
>     known to cause a GLXBadContextState error with newer nVidia drivers
>     (340.xx and later) in certain cases.
>
>     [5] Fixed a deadlock that occurred in the multi-threaded rendering test
>     of fakerut when it was run with the XCB interposer enabled.  This was
>     due to VirtualGL attempting to handle XCB events when Xlib owned the
>     event queue.  It is possible that this issue affected or would have
>     affected real-world applications as well.
>
>     [6] Fixed an issue that caused certain 3D applications (observed with
>     CAESES/FFW, although others were possibly affected as well) to abort
>     with "ERROR: in TempContext-- Could not bind OpenGL context to window
>     (window may may have disappeared)".  When the 3D application called
>     glXChooseVisual(), VirtualGL was choosing a corresponding FB config with
>     GLX_DRAWABLE_TYPE=GLX_PBUFFER_BIT (assuming that VGL_DRAWABLE=pbuffer,
>     which is the default.)  This is incorrect, however, because regardless
>     of the value of VGL_DRAWABLE, VirtualGL still uses Pixmaps on the 3D X
>     server to represent GLX Pixmaps (necessary in order to make
>     GLX_EXT_texture_from_pixmap work properly.)  Thus, VGL needs to choose
>     an FB config that supports both Pbuffers and Pixmaps.  This was
>     generally only a problem with nVidia drivers, because they export
>     different FB configs for GLX_PBUFFER_BIT and
>     GLX_PBUFFER_BIT|GLX_PIXMAP_BIT.

Re: [VirtualGL-Users] VirtualGL - reduce bandwidth with compression

[DRC <dco...@us...>]

No, the plugin framework was developed specifically for a customer.  The 
only documentation for it is in the API headers.  I wish I could be of 
more help.  This project interests me, but the only way I make money is 
by consulting and doing custom development for companies regarding 
VirtualGL and TurboVNC (and occasionally libjpeg-turbo), so I just can't 
devote a lot of free time to research projects like this, particularly 
given that gaming companies historically haven't been money makers for me.


On 6/12/15 4:13 PM, Marco Marino wrote:
> Ok, thanks. Is there some technical documentation for virtualgl
> developers? I need to understand the code, if i have to write a plugin.
> And the code is not trivial. I have no experience, and i never read
> virtualgl code before.
> However, thanks again for you answers.
> MM
>
> 2015-06-12 22:42 GMT+02:00 DRC <dco...@us...
> <mailto:dco...@us...>>:
>
>     OK, then yes, with the qualifications that you mention (a workload that
>     updates a predictable area of the screen in a predictable way, i.e.
>     games & video applications; low-bandwidth; reasonable image quality),
>     then a video codec such as H.264 is definitely going to be the best
>     solution.
>
>     I am working with some engineers at nVidia to look into how to integrate
>     H.264 with VirtualGL and TurboVNC, but we are still just bouncing ideas
>     around at this point.  I don't know if we'll come up with anything
>     concrete in the timeframe you need.  And since you're a student, writing
>     a transport plugin would be a good exercise.
>
>     Study testplugin.cpp.  Some things you'll have to consider:
>
>     -- how to handle the delivery of images over the network.  The VGL
>     Transport is really designed for use along with a remote X server, so
>     it's probably not the right protocol for you to use.  What would be
>     Really Cool(TM) is if you could leverage an existing streaming video
>     protocol.
>
>     -- how to handle the delivery of keyboard/mouse events from the client
>     to the server.  When you're dealing with an immersive application, such
>     as a game, for which window and GUI management are irrelevant, you could
>     do something clever, such as using an Xvfb instance on the server side
>     to act as a 2D X server.  Xvfb would be used solely for event
>     management.  Your plugin would intercept keyboard/mouse events from the
>     client and inject them into the Xvfb instance so that the 3D application
>     will receive them via its X event queue.  No actual pixels will be drawn
>     into that X server-- the pixels will be intercepted by the VGL plugin
>     and sent directly to the client.
>
>     You are not required to open source any of your work (VGL plugins can be
>     proprietary), but if you choose to do so, I'll be happy to review it for
>     possible inclusion in VirtualGL.
>
>     Also, you should investigate whether libx264 is a faster solution than
>     FFmpeg for compressing H.264.
>
>     Please feel free to ask follow-up questions on the virtualgl-devel list.
>
>
>     On 6/12/15 12:17 PM, Marco Marino wrote:
>     > Thanks for your answer.
>     > As you told "H.264 doesn't benefit all applications-- mainly it will
>     > only improve the situation for games and other very video-like
>     > workloads". And this is my purpose! I need a reliable, high latency
>     > network compatible "transport". I'm interested in gaming, and video
>     > reproduction but i want (!)  to use linux, and i thought that VirtualGL
>     > could be an option.
>     > Use a low JPEG quality is not a solution for me, I need good image quality.
>     > Write a transport plugin could be a solution? What i have to study
>     > before I can write a transport plugin? Have you some example (yes, i
>     > know testplugin.cpp) ?
>     > Thank you,
>     > MM
>     >
>     > 2015-05-27 9:42 GMT+02:00 DRC <dco...@us...
>     <mailto:dco...@us...>
>     > <mailto:dco...@us...
>     <mailto:dco...@us...>>>:
>     >
>     >     Depending on what you really need to do, it may not be necessary to get
>     >     that fancy.  Most users of VirtualGL use it with an X11 proxy.  TurboVNC
>     >     is the X proxy that our project provides and which has features and
>     >     performance specifically targeted at 3D applications, but there are
>     >     other X proxies that work with VGL as well (although usually not as fast
>     >     as TurboVNC.)  The X proxy, when combined with VirtualGL, will cause all
>     >     of the 2D (X11) as well as 3D (OpenGL) rendering commands from the
>     >     application to be rendered on the server and sent to the client as image
>     >     updates.  TurboVNC specifically has a feature called "automatic lossless
>     >     refresh", which allows you to use a very low JPEG quality for most
>     >     updates, but when the server senses that you have stopped moving things
>     >     around (such as when you stop rotating a 3D scene, etc.), it will send a
>     >     lossless update of the screen.  X proxies also do a much better job of
>     >     handling high-latency networks, since they are sending more
>     >     coarse-grained image updates instead of very fine-grained and chatty X11
>     >     updates over the network.
>     >
>     >     VirtualGL can also operate without an X proxy, but this is less useful
>     >     on high-latency networks, because it requires that the non-3D-related
>     >     X11 commands be sent over the network to the client machine.  Even
>     >     though the 3D-related X11 commands are being redirected by VirtualGL and
>     >     are being rendered on the server, the 2D-related X11 commands used to
>     >     draw the application GUI, etc. are still sent over the network, and that
>     >     can create performance problems on wide-area networks.
>     >
>     >     Now, to more specifically answer your question-- you can reduce the JPEG
>     >     quality in VirtualGL, which will significantly reduce the bandwidth.
>     >     Using TurboVNC will likely reduce the bandwidth as well, not only
>     >     because the X11 stuff is being rendered on the server but because
>     >     TurboVNC has a more adaptive compression scheme, whereas VirtualGL uses
>     >     plain motion-JPEG.  I'm currently working with nVidia to research
>     >     possible ways of leveraging their NVENC library to do H.264 compression
>     >     in VirtualGL, but there are a lot of technical hurdles we haven't
>     >     figured out yet vis-a-vis how that would interact with X proxies such as
>     >     TurboVNC.  Also, H.264 doesn't benefit all applications-- mainly it will
>     >     only improve the situation for games and other very video-like
>     >     workloads.  More tradition 3D applications (CAD, visualization, etc.)
>     >     are already quite optimal with TurboVNC's existing compression scheme.
>     >
>     >     VirtualGL does have a transport plugin API, so you could conceivably use
>     >     that to write your own transport plugin based on the existing VGL
>     >     Transport code (see server/testplugin.cpp for an example) but which uses
>     >     ffmpeg instead of libjpeg-turbo to do the 3D image compression.  Whether
>     >     or not that would really improve bandwidth usage would depend a lot on
>     >     your specific workload.
>     >
>     >
>     >     On 5/27/15 1:31 AM, Marco Marino wrote:
>     >     > Hi,
>     >     > i'm a student and i'm trying virtualgl for education purposes. From my
>     >     > tests with vglrun I saw that huge amount of bandwidth is required for
>     >     > acceptable image quality (eg: -c jpeg with quality 90 requires peaks of
>     >     > 50/60 Mbits). Is there a way to compress the video flow? Can i do
>     >     > something like: "VGLSOCKET" -> My compression library (like ffmpeg or
>     >     > similar) -> TCP/UDP socket ? In practice i want try to compress with my
>     >     > own code the output of VGL. Is this possible? I'm sorry if this is a
>     >     > stupid question, but I don't have knowledge about virtualgl.
>     >     > Thanks
>     >
>     >     ------------------------------------------------------------------------------
>     >     _______________________________________________
>     >     VirtualGL-Users mailing list
>     >Vir...@li...
>     <mailto:Vir...@li...>
>     >     <mailto:Vir...@li...
>     <mailto:Vir...@li...>>
>     >https://lists.sourceforge.net/lists/listinfo/virtualgl-users
>     >
>     >
>     >
>     >
>     > ------------------------------------------------------------------------------
>     >
>     >
>     >
>     > _______________________________________________
>     > VirtualGL-Users mailing list
>     >Vir...@li...
>     <mailto:Vir...@li...>
>     >https://lists.sourceforge.net/lists/listinfo/virtualgl-users
>     >
>
>     ------------------------------------------------------------------------------
>     _______________________________________________
>     VirtualGL-Users mailing list
>     Vir...@li...
>     <mailto:Vir...@li...>
>     https://lists.sourceforge.net/lists/listinfo/virtualgl-users
>
>
>
>
> ------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> VirtualGL-Users mailing list
> Vir...@li...
> https://lists.sourceforge.net/lists/listinfo/virtualgl-users
>