[VirtualGL-Devel] [PATCH] glxspheres: support specifying window size and max frames to draw

[Nathan Kidd <nathan-ml@sp...>]

This is mostly trivial, but I've personally found it useful when I want 
to compare how long a fixed amount of work takes (-f option) or want to 
see OpenGL vs. bandwidth bottlenecks (-ww, -wh).

-Nathan

Re: [VirtualGL-Devel] [PATCH] Print version information in verbose mode

[Nathan Kidd <nathan-ml@sp...>]

On 11-05-26 02:08 AM, DRC wrote:
> I checked in the version output line.  Unless you can tell me why it
> hurts anything for the shared memory segment ID to be printed first, I'm
> going to file that under "things that aren't going to be perfect."

If the aesthetic isn't interesting then the other benefit I can see is 
it means we don't have two separate places to determine if verbose mode 
is enabled.  To me that's a useful code improvement, but I won't argue. :)

-Nathan

Re: [VirtualGL-Devel] [PATCH] Implement automatic lossless refresh in VNCviewer

[DRC <dcommander@us...>]

On 5/26/11 1:10 AM, Arthur Huillet wrote:
> Indeed my code is not going to do a refresh in this case, as the image is
> not idle. My position is that if an application behaves incorrectly it
> should be fixed, and a terminal with a blinking cursor is not an
> interesting use case for ALR anyway (if you're running just a terminal, increase
> the JPEG quality or don't use JPEG).
> 
> (About "should be fixed": this is very serious, not just because of VNC
> but because of power management issues.)

There are many 3D applications that have a terminal with a blinking
cursor integrated into them.  If I just threw up my hands and said "the
application needs to be fixed" every time I encountered an issue like
this, VirtualGL would still just be a science fair project.  A good
portion of my work in the past 7 years has been spent working around
aberrant application behavior-- moreso with VirtualGL than TurboVNC, but
TurboVNC is certainly not immune from this.  After 7 years of existence
as an open source project, I feel like we finally have enough traction
to where we can reasonably expect application vendors to work with us,
rather than us working around them, but that level of engagement takes time.

The specific issues with ill-behaved taskbars are with several different
O/S distributions which shall remain nameless.  It isn't as simple as
just saying "you can't use ALR with that distro."


>> I'm being paid to come up with an automatic lossless refresh solution
>> for TigerVNC, so I'll be revisiting some of these assumptions over the
>> next few months.  At the moment, my inclination is to leave TurboVNC as-is.
> 
> I'm looking forward to that. In the meantime I will give more testing to my
> patches, evaluate whether they are fit to my use cases, and distribute them if
> so.

I would say that the odds of them being incorporated into TurboVNC are
slim.  I need to open a dialog with the TigerVNC developers as to the
best way to implement ALR in that code base.  I really don't like the
idea of implementing it on the server, because it requires a separate
thread (I expect push-back from TigerVNC on that as well.)  However, I
don't know of any other way of being able to enable ALR for only a
specific type of X request.  At the end of the day, the implementation
of ALR in TurboVNC is stable, and people are successfully using it, so I
don't want to replace it unless there's something much more compelling
to replace it with.

At the end of the day, the client-driven nature of the RFB protocol is
pretty nasty, and the reasons why it is client-driven are no longer
valid.  Setting up a separate compress/send thread on the server for
each connected client and setting up a true back buffer for the client
display would eliminate the need for the client to send framebuffer
update requests.  A proof of concept for this is implemented in the
TurboVNC CVS Head (the "Continuous Updates" feature.)  However, it is
still a bit science-fair.  It has to make some simplifying assumptions,
such as only making certain types of requests eligible for CU
(currently, PutImage or XCopyArea requests of >= 65 kpixels.)  It's a
bit of a hack to attempt to improve the performance of TurboVNC on
high-latency networks when using VirtualGL, but there are still some
fundamental architectural aspects of VNC that need to change.  How to
make those changes without breaking compatibility with other VNC
implementations is the challenge.

Re: [VirtualGL-Devel] [PATCH] Implement automatic lossless refresh in VNCviewer

[Arthur Huillet <arthur.huillet@fr...>]

Hi,

On Wed, 25 May 2011 16:38:44 -0500
DRC <dcommander@...> wrote:

> Probably the biggest reason is what I call the "blinking cursor dilemma."
> There are some ill-behaved window managers out there that continuously update
> their taskbar widgets using small XCopyArea operations, and similarly, if you
> have a console window open, it will create a similar phenomenon because
> of the blinking cursor.  

Indeed my code is not going to do a refresh in this case, as the image is
not idle. My position is that if an application behaves incorrectly it
should be fixed, and a terminal with a blinking cursor is not an
interesting use case for ALR anyway (if you're running just a terminal, increase
the JPEG quality or don't use JPEG).

(About "should be fixed": this is very serious, not just because of VNC
but because of power management issues.)

> Additionally, ALR maintains a list of tiles and only sends lossless
> updates for the ones that were previously sent using JPEG.

My ALR is going to do more traffic than that indeed. Most of my tests were
applications that refreshed the whole screen as JPEG all the time, so this
didn't apply.

> I'm being paid to come up with an automatic lossless refresh solution
> for TigerVNC, so I'll be revisiting some of these assumptions over the
> next few months.  At the moment, my inclination is to leave TurboVNC as-is.

I'm looking forward to that. In the meantime I will give more testing to my
patches, evaluate whether they are fit to my use cases, and distribute them if
so.

Thanks
-- 
Greetings, 
A. Huillet

Re: [VirtualGL-Devel] [PATCH] Print version information in verbose mode

[DRC <dcommander@us...>]

I checked in the version output line.  Unless you can tell me why it
hurts anything for the shared memory segment ID to be printed first, I'm
going to file that under "things that aren't going to be perfect."


On 5/25/11 9:34 AM, Nathan Kidd wrote:
> On 11-05-24 10:24 PM, DRC wrote:
>> This belongs in __vgl_fakerinit().
> 
> Heh, where it was till I didn't like the line
> 
>   [VGL] Shared memory segment ID for vglconfig: 510853141
> 
> always getting printed first.  The attached patch achieves this instead
> by not printing the shared memory segment line till __vgl_fakerinit().
> 
> Again, not a simple one-liner to achieve this:
> 
>    [VGL] VirtualGL v2.2.80 64-bit (Build 20110524)
>    [VGL] Shared memory segment ID for vglconfig: 510853141
> 
> instead of:
> 
>    [VGL] Shared memory segment ID for vglconfig: 510853141
>    [VGL] VirtualGL v2.2.80 64-bit (Build 20110524)
> 
> -Nathan
> 
> 
> 
> ------------------------------------------------------------------------------
> vRanger cuts backup time in half-while increasing security.
> With the market-leading solution for virtual backup and recovery, 
> you get blazing-fast, flexible, and affordable data protection.
> Download your free trial now. 
> http://p.sf.net/sfu/quest-d2dcopy1
> 
> 
> 
> _______________________________________________
> VirtualGL-Devel mailing list
> VirtualGL-Devel@...
> https://lists.sourceforge.net/lists/listinfo/virtualgl-devel

Re: [VirtualGL-Devel] [PATCH] Implement automatic lossless refresh in VNCviewer

[DRC <dcommander@us...>]

Hi.  There are several problems with this, as implemented, and now that
I think about the problem in more detail, I am remembering some of the
reasons why I implemented ALR on the server side.  Probably the biggest
reason is what I call the "blinking cursor dilemma."  There are some
ill-behaved window managers out there that continuously update their
taskbar widgets using small XCopyArea operations, and similarly, if you
have a console window open, it will create a similar phenomenon because
of the blinking cursor.  Thus, the default ALR behavior is currently to
only make PutImage() operations eligible for ALR, and the only way to do
that is to hook into the PutImage handler in the server-side VNC code.
Additionally, ALR maintains a list of tiles and only sends lossless
updates for the ones that were previously sent using JPEG.  That could
potentially be done from the client side as well, but it would be
problematic on high-latency networks, because it would require a round
trip (potentially several, because we might have to send a new
framebuffer update request for each JPEG tile for which we're requesting
a lossless copy.)

I'm being paid to come up with an automatic lossless refresh solution
for TigerVNC, so I'll be revisiting some of these assumptions over the
next few months.  At the moment, my inclination is to leave TurboVNC as-is.


On 5/12/11 5:07 AM, Arthur Huillet wrote:
> Hi,
> 
> The attached patch implements ALR, based on a Xt timeout that is reset after
> each framebuffer update.
> 
> I have added -alrjpeg to enable use of JPEG Q95 for "ALR", because in some
> cases I do not want to use truly lossless (low bandwidth).
> 
> If you're happy, please apply.
> 
> Next in line: add both options to the F8 menu, and factorize the code with the
> "request ALR" feature.
> 

Re: [VirtualGL-Devel] [PATCH] Print version information in verbose mode

[Nathan Kidd <nathan-ml@sp...>]

On 11-05-24 10:24 PM, DRC wrote:
> This belongs in __vgl_fakerinit().

Heh, where it was till I didn't like the line

   [VGL] Shared memory segment ID for vglconfig: 510853141

always getting printed first.  The attached patch achieves this instead 
by not printing the shared memory segment line till __vgl_fakerinit().

Again, not a simple one-liner to achieve this:

    [VGL] VirtualGL v2.2.80 64-bit (Build 20110524)
    [VGL] Shared memory segment ID for vglconfig: 510853141

instead of:

    [VGL] Shared memory segment ID for vglconfig: 510853141
    [VGL] VirtualGL v2.2.80 64-bit (Build 20110524)

-Nathan

Re: [VirtualGL-Devel] [PATCH] Print version information in verbose mode

[DRC <dcommander@us...>]

This belongs in __vgl_fakerinit().


On 5/24/11 3:41 PM, Nathan Kidd wrote:
> Even if the user is competent, the number of ways one could accidentally
> load a different librrfaker.so make this information invaluable.
> 
> This isn't a one-liner to gain the aesthetic of printing the version
> info first, before anything else.
> 
> -Nathan
> 
> 
> 
> ------------------------------------------------------------------------------
> vRanger cuts backup time in half-while increasing security.
> With the market-leading solution for virtual backup and recovery, 
> you get blazing-fast, flexible, and affordable data protection.
> Download your free trial now. 
> http://p.sf.net/sfu/quest-d2dcopy1
> 
> 
> 
> _______________________________________________
> VirtualGL-Devel mailing list
> VirtualGL-Devel@...
> https://lists.sourceforge.net/lists/listinfo/virtualgl-devel

[VirtualGL-Devel] [PATCH] Print version information in verbose mode

[Nathan Kidd <nathan-ml@sp...>]

Even if the user is competent, the number of ways one could accidentally 
load a different librrfaker.so make this information invaluable.

This isn't a one-liner to gain the aesthetic of printing the version 
info first, before anything else.

-Nathan

Re: [VirtualGL-Devel] Problem with vglrun and tcsh

[Lee Whatley, Contractor <lwhatley.ctr@na...>]

Ok so I'm told even if the script doesn't do anything other than 
launching the app it still doesn't work.  In fact, "Simply executing 
'vglrun tcsh' will not return a prompt, it simply stalls until 
ctrl-c'ed."  Unless of course we use the tcsh that has that 
previously-mentioned RHEL patch removed.

Would it be possible for our developer to contact you off-list (or 
vice-versa)?  It might make things easier if the middle-man (me) is 
removed from the discussion?

Again, I really appreciate the response.  Based on your feedback it 
sounds like there might just be some problem with our particular 
environment that is preventing this from working.

Thanks!
-Lee

DRC wrote:
> Still can't reproduce.  Is the script doing anything other than
> launching the app?  I would assume it must be-- otherwise, why write a
> script?!
> 
> 
> On 5/19/11 2:56 PM, Lee Whatley, Contractor wrote:
>> I'm told he is trying to use TurboVNC with VirtualGL, if that answers
>> your question.
>>
>> Thanks for the response!
>> -Lee
>>
>> DRC wrote:
>>> I can't seem to reproduce it.  If I create, for instance, ~/test.csh
>>> with the following contents:
>>>
>>>   #!/bin/tcsh
>>>   /opt/VirtualGL/bin/glxspheres64
>>>
>>> I can do
>>>
>>>   vglrun ~/test.csh
>>>
>>> or
>>>
>>>   vglrun tcsh ~/test.csh
>>>
>>> with no issues.  I'm running 5.6 as well.
>>>
>>> Are you trying to use VGLClient or an X proxy?
>>>
>>>
>>> On 5/19/11 12:28 PM, Lee Whatley, Contractor wrote:
>>>> Greetings,
>>>>
>>>> I have a developer who is trying to use VirtualGL 2.2 on RHEL 5.6 x86_64
>>>> to launch applications that are wrapped inside of tcsh scripts, but is
>>>> running into problems.  Doing something like "vglrun tcsh" or "vglrun
>>>> <tcsh_script>" just gives him a "blank screen" whereas "vglrun
>>>> <bash_script>" or "vglrun <other_application>" works fine.
>>>>
>>>> After some digging, he found that he could get everything to work
>>>> correctly if he rebuilt RHEL's tcsh rpm without a patch that Red Hat
>>>> includes.  The patch description says that it "Change config_f.h to use
>>>> system malloc()".
>>>>
>>>> Has anyone else ever experienced this issue with vglrun and tcsh under
>>>> RHEL5?  A google search (and search of the virtualgl mailing lists
>>>> archives) did not turn up anything.
>>>>
>>>> FWIW I have also opened a bug with Red Hat, found here:
>>>>
>>>> https://bugzilla.redhat.com/show_bug.cgi?id=706144
>>>>
>>>> but I have a feeling they are going to be of the opinion that the
>>>> problem is with VirtualGL and not with their tcsh.
>>>>
>>>> Any advise, comments, etc. would be greatly appreciated.
>>>>
>>>> Thanks!
>>>> -Lee
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>>
>>>> What Every C/C++ and Fortran developer Should Know!
>>>> Read this article and learn how Intel has extended the reach of its
>>>> next-generation tools to help Windows* and Linux* C/C++ and Fortran
>>>> developers boost performance applications - including clusters.
>>>> http://p.sf.net/sfu/intel-dev2devmay
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> VirtualGL-Devel mailing list
>>>> VirtualGL-Devel@...
>>>> https://lists.sourceforge.net/lists/listinfo/virtualgl-devel
>>> ------------------------------------------------------------------------------
>>>
>>> What Every C/C++ and Fortran developer Should Know!
>>> Read this article and learn how Intel has extended the reach of its
>>> next-generation tools to help Windows* and Linux* C/C++ and Fortran
>>> developers boost performance applications - including clusters.
>>> http://p.sf.net/sfu/intel-dev2devmay
>>> _______________________________________________
>>> VirtualGL-Devel mailing list
>>> VirtualGL-Devel@...
>>> https://lists.sourceforge.net/lists/listinfo/virtualgl-devel
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> What Every C/C++ and Fortran developer Should Know!
>> Read this article and learn how Intel has extended the reach of its 
>> next-generation tools to help Windows* and Linux* C/C++ and Fortran 
>> developers boost performance applications - including clusters. 
>> http://p.sf.net/sfu/intel-dev2devmay
>>
>>
>>
>> _______________________________________________
>> VirtualGL-Devel mailing list
>> VirtualGL-Devel@...
>> https://lists.sourceforge.net/lists/listinfo/virtualgl-devel
> 
> ------------------------------------------------------------------------------
> What Every C/C++ and Fortran developer Should Know!
> Read this article and learn how Intel has extended the reach of its 
> next-generation tools to help Windows* and Linux* C/C++ and Fortran 
> developers boost performance applications - including clusters. 
> http://p.sf.net/sfu/intel-dev2devmay
> _______________________________________________
> VirtualGL-Devel mailing list
> VirtualGL-Devel@...
> https://lists.sourceforge.net/lists/listinfo/virtualgl-devel
> 


-- 
Lee S. Whatley, Contractor
Navy DSRC
Lockheed Martin
1002 Balch Boulevard
Stennis Space Center, MS 39522
Phone: 228-688-4999	DSN: 828-4999

Re: [VirtualGL-Devel] Problem with vglrun and tcsh

[DRC <dcommander@us...>]

Still can't reproduce.  Is the script doing anything other than
launching the app?  I would assume it must be-- otherwise, why write a
script?!


On 5/19/11 2:56 PM, Lee Whatley, Contractor wrote:
> I'm told he is trying to use TurboVNC with VirtualGL, if that answers
> your question.
> 
> Thanks for the response!
> -Lee
> 
> DRC wrote:
>> I can't seem to reproduce it.  If I create, for instance, ~/test.csh
>> with the following contents:
>>
>>   #!/bin/tcsh
>>   /opt/VirtualGL/bin/glxspheres64
>>
>> I can do
>>
>>   vglrun ~/test.csh
>>
>> or
>>
>>   vglrun tcsh ~/test.csh
>>
>> with no issues.  I'm running 5.6 as well.
>>
>> Are you trying to use VGLClient or an X proxy?
>>
>>
>> On 5/19/11 12:28 PM, Lee Whatley, Contractor wrote:
>>> Greetings,
>>>
>>> I have a developer who is trying to use VirtualGL 2.2 on RHEL 5.6 x86_64
>>> to launch applications that are wrapped inside of tcsh scripts, but is
>>> running into problems.  Doing something like "vglrun tcsh" or "vglrun
>>> <tcsh_script>" just gives him a "blank screen" whereas "vglrun
>>> <bash_script>" or "vglrun <other_application>" works fine.
>>>
>>> After some digging, he found that he could get everything to work
>>> correctly if he rebuilt RHEL's tcsh rpm without a patch that Red Hat
>>> includes.  The patch description says that it "Change config_f.h to use
>>> system malloc()".
>>>
>>> Has anyone else ever experienced this issue with vglrun and tcsh under
>>> RHEL5?  A google search (and search of the virtualgl mailing lists
>>> archives) did not turn up anything.
>>>
>>> FWIW I have also opened a bug with Red Hat, found here:
>>>
>>> https://bugzilla.redhat.com/show_bug.cgi?id=706144
>>>
>>> but I have a feeling they are going to be of the opinion that the
>>> problem is with VirtualGL and not with their tcsh.
>>>
>>> Any advise, comments, etc. would be greatly appreciated.
>>>
>>> Thanks!
>>> -Lee
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> What Every C/C++ and Fortran developer Should Know!
>>> Read this article and learn how Intel has extended the reach of its
>>> next-generation tools to help Windows* and Linux* C/C++ and Fortran
>>> developers boost performance applications - including clusters.
>>> http://p.sf.net/sfu/intel-dev2devmay
>>>
>>>
>>>
>>> _______________________________________________
>>> VirtualGL-Devel mailing list
>>> VirtualGL-Devel@...
>>> https://lists.sourceforge.net/lists/listinfo/virtualgl-devel
>>
>> ------------------------------------------------------------------------------
>>
>> What Every C/C++ and Fortran developer Should Know!
>> Read this article and learn how Intel has extended the reach of its
>> next-generation tools to help Windows* and Linux* C/C++ and Fortran
>> developers boost performance applications - including clusters.
>> http://p.sf.net/sfu/intel-dev2devmay
>> _______________________________________________
>> VirtualGL-Devel mailing list
>> VirtualGL-Devel@...
>> https://lists.sourceforge.net/lists/listinfo/virtualgl-devel
>>
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> What Every C/C++ and Fortran developer Should Know!
> Read this article and learn how Intel has extended the reach of its 
> next-generation tools to help Windows* and Linux* C/C++ and Fortran 
> developers boost performance applications - including clusters. 
> http://p.sf.net/sfu/intel-dev2devmay
> 
> 
> 
> _______________________________________________
> VirtualGL-Devel mailing list
> VirtualGL-Devel@...
> https://lists.sourceforge.net/lists/listinfo/virtualgl-devel

Re: [VirtualGL-Devel] Problem with vglrun and tcsh

[Lee Whatley, Contractor <lwhatley.ctr@na...>]

I'm told he is trying to use TurboVNC with VirtualGL, if that answers 
your question.

Thanks for the response!
-Lee

DRC wrote:
> I can't seem to reproduce it.  If I create, for instance, ~/test.csh
> with the following contents:
> 
>   #!/bin/tcsh
>   /opt/VirtualGL/bin/glxspheres64
> 
> I can do
> 
>   vglrun ~/test.csh
> 
> or
> 
>   vglrun tcsh ~/test.csh
> 
> with no issues.  I'm running 5.6 as well.
> 
> Are you trying to use VGLClient or an X proxy?
> 
> 
> On 5/19/11 12:28 PM, Lee Whatley, Contractor wrote:
>> Greetings,
>>
>> I have a developer who is trying to use VirtualGL 2.2 on RHEL 5.6 x86_64
>> to launch applications that are wrapped inside of tcsh scripts, but is
>> running into problems.  Doing something like "vglrun tcsh" or "vglrun
>> <tcsh_script>" just gives him a "blank screen" whereas "vglrun
>> <bash_script>" or "vglrun <other_application>" works fine.
>>
>> After some digging, he found that he could get everything to work
>> correctly if he rebuilt RHEL's tcsh rpm without a patch that Red Hat
>> includes.  The patch description says that it "Change config_f.h to use
>> system malloc()".
>>
>> Has anyone else ever experienced this issue with vglrun and tcsh under
>> RHEL5?  A google search (and search of the virtualgl mailing lists
>> archives) did not turn up anything.
>>
>> FWIW I have also opened a bug with Red Hat, found here:
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=706144
>>
>> but I have a feeling they are going to be of the opinion that the
>> problem is with VirtualGL and not with their tcsh.
>>
>> Any advise, comments, etc. would be greatly appreciated.
>>
>> Thanks!
>> -Lee
>>
>>
>>
>> ------------------------------------------------------------------------------
>> What Every C/C++ and Fortran developer Should Know!
>> Read this article and learn how Intel has extended the reach of its 
>> next-generation tools to help Windows* and Linux* C/C++ and Fortran 
>> developers boost performance applications - including clusters. 
>> http://p.sf.net/sfu/intel-dev2devmay
>>
>>
>>
>> _______________________________________________
>> VirtualGL-Devel mailing list
>> VirtualGL-Devel@...
>> https://lists.sourceforge.net/lists/listinfo/virtualgl-devel
> 
> ------------------------------------------------------------------------------
> What Every C/C++ and Fortran developer Should Know!
> Read this article and learn how Intel has extended the reach of its 
> next-generation tools to help Windows* and Linux* C/C++ and Fortran 
> developers boost performance applications - including clusters. 
> http://p.sf.net/sfu/intel-dev2devmay
> _______________________________________________
> VirtualGL-Devel mailing list
> VirtualGL-Devel@...
> https://lists.sourceforge.net/lists/listinfo/virtualgl-devel
> 


-- 
Lee S. Whatley, Contractor
Navy DSRC
Lockheed Martin
1002 Balch Boulevard
Stennis Space Center, MS 39522
Phone: 228-688-4999	DSN: 828-4999

Re: [VirtualGL-Devel] Problem with vglrun and tcsh

[DRC <dcommander@us...>]

I can't seem to reproduce it.  If I create, for instance, ~/test.csh
with the following contents:

  #!/bin/tcsh
  /opt/VirtualGL/bin/glxspheres64

I can do

  vglrun ~/test.csh

or

  vglrun tcsh ~/test.csh

with no issues.  I'm running 5.6 as well.

Are you trying to use VGLClient or an X proxy?


On 5/19/11 12:28 PM, Lee Whatley, Contractor wrote:
> Greetings,
> 
> I have a developer who is trying to use VirtualGL 2.2 on RHEL 5.6 x86_64
> to launch applications that are wrapped inside of tcsh scripts, but is
> running into problems.  Doing something like "vglrun tcsh" or "vglrun
> <tcsh_script>" just gives him a "blank screen" whereas "vglrun
> <bash_script>" or "vglrun <other_application>" works fine.
> 
> After some digging, he found that he could get everything to work
> correctly if he rebuilt RHEL's tcsh rpm without a patch that Red Hat
> includes.  The patch description says that it "Change config_f.h to use
> system malloc()".
> 
> Has anyone else ever experienced this issue with vglrun and tcsh under
> RHEL5?  A google search (and search of the virtualgl mailing lists
> archives) did not turn up anything.
> 
> FWIW I have also opened a bug with Red Hat, found here:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=706144
> 
> but I have a feeling they are going to be of the opinion that the
> problem is with VirtualGL and not with their tcsh.
> 
> Any advise, comments, etc. would be greatly appreciated.
> 
> Thanks!
> -Lee
> 
> 
> 
> ------------------------------------------------------------------------------
> What Every C/C++ and Fortran developer Should Know!
> Read this article and learn how Intel has extended the reach of its 
> next-generation tools to help Windows* and Linux* C/C++ and Fortran 
> developers boost performance applications - including clusters. 
> http://p.sf.net/sfu/intel-dev2devmay
> 
> 
> 
> _______________________________________________
> VirtualGL-Devel mailing list
> VirtualGL-Devel@...
> https://lists.sourceforge.net/lists/listinfo/virtualgl-devel

[VirtualGL-Devel] Problem with vglrun and tcsh

[Lee Whatley, Contractor <lwhatley.ctr@na...>]

Greetings,

I have a developer who is trying to use VirtualGL 2.2 on RHEL 5.6 x86_64 
to launch applications that are wrapped inside of tcsh scripts, but is 
running into problems.  Doing something like "vglrun tcsh" or "vglrun 
<tcsh_script>" just gives him a "blank screen" whereas "vglrun 
<bash_script>" or "vglrun <other_application>" works fine.

After some digging, he found that he could get everything to work 
correctly if he rebuilt RHEL's tcsh rpm without a patch that Red Hat 
includes.  The patch description says that it "Change config_f.h to use 
system malloc()".

Has anyone else ever experienced this issue with vglrun and tcsh under 
RHEL5?  A google search (and search of the virtualgl mailing lists 
archives) did not turn up anything.

FWIW I have also opened a bug with Red Hat, found here:

https://bugzilla.redhat.com/show_bug.cgi?id=706144

but I have a feeling they are going to be of the opinion that the 
problem is with VirtualGL and not with their tcsh.

Any advise, comments, etc. would be greatly appreciated.

Thanks!
-Lee

-- 
Lee S. Whatley, Contractor
Navy DSRC
Lockheed Martin
1002 Balch Boulevard
Stennis Space Center, MS 39522
Phone: 228-688-4999	DSN: 828-4999

Re: [VirtualGL-Devel] [PATCH] Implement automatic lossless refresh in VNCviewer

[DRC <dcommander@us...>]

I am very busy, not to mention that it is the weekend here. Please be patient! 

On May 15, 2011, at 2:46 PM, Arthur Huillet <arthur.huillet@...> wrote:

> Hi,
> 
> those patches are perhaps too simplistic, but my testing wasn't able to
> find any problem.
> 
> Is there something wrong with the patches?
> 
> Thanks
> -- 
> Greetings, 
> A. Huillet
> 

Re: [VirtualGL-Devel] [PATCH] Implement automatic lossless refresh in VNCviewer

[Arthur Huillet <arthur.huillet@fr...>]

Hi,

those patches are perhaps too simplistic, but my testing wasn't able to
find any problem.

Is there something wrong with the patches?

Thanks
-- 
Greetings, 
A. Huillet

Re: [VirtualGL-Devel] [PATCH] Make glXGetConfig/glXGetFBConfigAttrib return errors instead of dying

[Nathan Kidd <nathan-ml@sp...>]

On 11-05-13 03:15 PM, DRC wrote:
> However, a failure in MatchConfig() and MatchVisual() needs to remain fatal.
...
> (2) We're not a GL driver.  There are certain things in VirtualGL that
> are non-recoverable that would probably be recoverable in a regular GLX
> implementation.  Visual matching is one of them.  If MatchConfig() or
> MatchVisual() are failing, it usually means that there is a deeper
> interaction issue with the app, and if the function fails silently and
> only causes the app to render incorrectly, it's really hard to track
> down what's going on.

If its in the trace log then I can't see it being any harder to know it 
happened, or where it happened. But...

> Fatal errors will get reported, whereas non-fatal
> errors will just lead to the user saying "well, this solution is flaky"
> and never reporting the issue.

...this convinces me. :)  However, it suggests that the ideal approach 
would be to pop up a "fatal error" X dialog. It makes absolutely sure 
the user knows the problem. In my experience most users launch apps from 
a GUI and will never see the log.  For me, at least, having an app 
suddenly disappear (with no chance to save) sets off my this-solution-is 
flaky-o'meter even more than getting wrong drawing does.

> I take a very reactive approach to developing VirtualGL, as you may have
> noticed.  Everything that is done to that code is done in response to
> the needs of a specific app.  I don't fix that which isn't broken yet,
> as a general rule, because it's been my experience that doing that often
> breaks something else.

Duly noted.  The only reason I sent this at all is that it is very hard 
to imagine how it could *break* an existing app; if the app hits the 
error now it dies.  But the issue of encouraging error reporting is 
definitely important.

Attached patch doesn't touch the _Match* calls.  Ah, and now I see I was 
too slow and you already modified it...

-Nathan

Re: [VirtualGL-Devel] [PATCH] Make glXGetConfig/glXGetFBConfigAttrib return errors instead of dying

[DRC <dcommander@us...>]

Committed with modifications (MatchConfig() and MatchVisual() failures
remain fatal, and also I made it so that the invalid arguments will
appear in the tracing output, thus making them easier to pinpoint in
cases where the app doesn't check the return value.)  Your test app
should work correctly now.

On 5/13/11 12:11 PM, Nathan Kidd wrote:
> Rather than ripping out the rug from under the user, worst-case the app
> doesn't draw correctly but at least the user has a chance to save.  The
> trace logs will still give necessary info to know something went wrong.
> 
> This is the logical follow-up to the previous patch.  Given enough time,
> I suggest an app that triggers one of these cases will be encountered.
> While we don't want to start baby-sitting bad applications, we should at
> least be as lenient as other known GL drivers.
> 
> -Nathan
> 
> 
> 
> ------------------------------------------------------------------------------
> Achieve unprecedented app performance and reliability
> What every C/C++ and Fortran developer should know.
> Learn how Intel has extended the reach of its next-generation tools
> to help boost performance applications - inlcuding clusters.
> http://p.sf.net/sfu/intel-dev2devmay
> 
> 
> 
> _______________________________________________
> VirtualGL-Devel mailing list
> VirtualGL-Devel@...
> https://lists.sourceforge.net/lists/listinfo/virtualgl-devel

Re: [VirtualGL-Devel] Trace Indentation [was Re: New VGL_ALLOWINDIRECT option for Mathematica 7]

[Nathan Kidd <nathan-ml@sp...>]

On 11-05-13 03:19 PM, DRC wrote:
> Except for the fact that you pushed over the nested lines by four too
> many spaces, this is fine.  Checked into HEAD.

Oops, thanks.

Re: [VirtualGL-Devel] Trace Indentation [was Re: New VGL_ALLOWINDIRECT option for Mathematica 7]

[DRC <dcommander@us...>]

Except for the fact that you pushed over the nested lines by four too
many spaces, this is fine.  Checked into HEAD.

On 5/13/11 10:38 AM, Nathan Kidd wrote:
> On 11-05-10 10:06 PM, DRC wrote:
>> On 5/3/11 10:53 AM, Nathan Kidd wrote:
>>> Yeah, the nested calls are annoying enough as it is. The attached
>>> trivial patch fixes the issue for glXIsDirect().  There are a number of
>>> other nested traces though.  For readability probably a simple "static
>>> int tracedepth" could be added to the starttrace/stoptrace macros to
>>> give automatic indenting for the nested calls.  Let me see how that
>>> looks...
>>
>> I checked in a patch to CVS head which should line up the nested calls
>> on new lines in the trace output.  See how it works for you.
> 
> Current CVS gives me:
> 
>> [VGL] glXMakeCurrent (dpy=0x7f6cf813eb40(:0.0) drawable=0x0700145e
>> ctx=0x7f6cf8c421c8
>>         XQueryExtension (dpy=0x7f6cf813eb40(:0.0) name=XVideo
>> *major_opcode=132 *first_event=72 *first_error=140 ) 0.051022 ms
>>
>>         glXCreatePbuffer (dpy=0x7f6cf8131000(:0.0)
>> config=0x00000105(0x105) attrib_list=[0x8041=0x0168 0x8040=0x0121
>> 0x801b=0x0001 ] pb=0x06e00008 ) 0.403166 ms
>>       config=0x00000105(0x105) drawable=0x06e00008 ) 38.542032 ms
>> [VGL] glViewport (x=0 y=0 width=360 height=289 ) 0.010014 ms
> 
> 
> With the attached patch we get:
> 
>> [VGL] glXMakeCurrent (dpy=0x7fcc6c13cd90(:0.0) drawable=0x070011c9
>> ctx=0x7fcc6d5b42e8
>> [VGL]        XQueryExtension (dpy=0x7fcc6c13cd90(:0.0) name=XVideo
>> *major_opcode=132 *first_event=72 *first_error=140 ) 0.051022 ms
>> [VGL]
>> [VGL]        glXCreatePbuffer (dpy=0x7fcc6c12f250(:0.0)
>> config=0x00000105(0x105) attrib_list=[0x8041=0x0168 0x8040=0x0121
>> 0x801b=0x0001 ] pb=0x06e00008 )
>> [VGL]      config=0x00000105(0x105) drawable=0x06e00008 ) 4.723072 ms
>> [VGL] glViewport (x=0 y=0 width=360 height=289 ) 0.005960 ms
> 
> The reason I like this better is because there's no possibility for
> confusion of which lines came from VGL (think output from VGL and app
> both going to stderr/stdout).
> 
> The empty lines aren't so nice (coming from the 2nd modified line in the
> patch).  I don't see a way to fix it apart from a) being able to look up
> the last char written to the stream (again think mixed output to stream)
> or b) modifying all the prarg macros to print leading space if
> necessary.  The complexity doesn't seem worth it.
> 
> -Nathan
> 
> 
> 
> ------------------------------------------------------------------------------
> Achieve unprecedented app performance and reliability
> What every C/C++ and Fortran developer should know.
> Learn how Intel has extended the reach of its next-generation tools
> to help boost performance applications - inlcuding clusters.
> http://p.sf.net/sfu/intel-dev2devmay
> 
> 
> 
> _______________________________________________
> VirtualGL-Devel mailing list
> VirtualGL-Devel@...
> https://lists.sourceforge.net/lists/listinfo/virtualgl-devel

Re: [VirtualGL-Devel] [PATCH] Make glXGetConfig/glXGetFBConfigAttrib return errors instead of dying

[DRC <dcommander@us...>]

On 5/13/11 12:11 PM, Nathan Kidd wrote:
> Rather than ripping out the rug from under the user, worst-case the app
> doesn't draw correctly but at least the user has a chance to save.  The
> trace logs will still give necessary info to know something went wrong.
> 
> This is the logical follow-up to the previous patch.  Given enough time,
> I suggest an app that triggers one of these cases will be encountered.
> While we don't want to start baby-sitting bad applications, we should at
> least be as lenient as other known GL drivers.

I am OK with making the bad arguments non-fatal, because that is
consistent with the behavior of the rest of the GLX functions in VGL.
However, a failure in MatchConfig() and MatchVisual() needs to remain fatal.

Arguments:
(1) If such horribly-behaved apps existed, we would've encountered them
by now.
(2) We're not a GL driver.  There are certain things in VirtualGL that
are non-recoverable that would probably be recoverable in a regular GLX
implementation.  Visual matching is one of them.  If MatchConfig() or
MatchVisual() are failing, it usually means that there is a deeper
interaction issue with the app, and if the function fails silently and
only causes the app to render incorrectly, it's really hard to track
down what's going on.  Fatal errors will get reported, whereas non-fatal
errors will just lead to the user saying "well, this solution is flaky"
and never reporting the issue.

I take a very reactive approach to developing VirtualGL, as you may have
noticed.  Everything that is done to that code is done in response to
the needs of a specific app.  I don't fix that which isn't broken yet,
as a general rule, because it's been my experience that doing that often
breaks something else.

Re: [VirtualGL-Devel] [PATCH] Make glXGetConfig/glXGetFBConfigAttrib return errors instead of dying

[Nathan Kidd <nathan-ml@sp...>]

Forgot to attached simple app I used to test this. -Nathan

On 11-05-13 01:11 PM, Nathan Kidd wrote:
> Rather than ripping out the rug from under the user, worst-case the app
> doesn't draw correctly but at least the user has a chance to save. The
> trace logs will still give necessary info to know something went wrong.
>
> This is the logical follow-up to the previous patch. Given enough time,
> I suggest an app that triggers one of these cases will be encountered.
> While we don't want to start baby-sitting bad applications, we should at
> least be as lenient as other known GL drivers.
>
> -Nathan

[VirtualGL-Devel] [PATCH] Make glXGetConfig/glXGetFBConfigAttrib return errors instead of dying

[Nathan Kidd <nathan-ml@sp...>]

Rather than ripping out the rug from under the user, worst-case the app 
doesn't draw correctly but at least the user has a chance to save.  The 
trace logs will still give necessary info to know something went wrong.

This is the logical follow-up to the previous patch.  Given enough time,
I suggest an app that triggers one of these cases will be encountered.
While we don't want to start baby-sitting bad applications, we should at 
least be as lenient as other known GL drivers.

-Nathan

[VirtualGL-Devel] [PATCH] Don't kill process if glXGetConfig() is fed bad arguments

[Nathan Kidd <nathan-ml@sp...>]

This is the "minimally fix the problem" patch.

[VirtualGL-Devel] Trace Indentation [was Re: New VGL_ALLOWINDIRECT option for Mathematica 7]

[Nathan Kidd <nathan-ml@sp...>]

On 11-05-10 10:06 PM, DRC wrote:
> On 5/3/11 10:53 AM, Nathan Kidd wrote:
>> Yeah, the nested calls are annoying enough as it is. The attached
>> trivial patch fixes the issue for glXIsDirect().  There are a number of
>> other nested traces though.  For readability probably a simple "static
>> int tracedepth" could be added to the starttrace/stoptrace macros to
>> give automatic indenting for the nested calls.  Let me see how that
>> looks...
>
> I checked in a patch to CVS head which should line up the nested calls
> on new lines in the trace output.  See how it works for you.

Current CVS gives me:

> [VGL] glXMakeCurrent (dpy=0x7f6cf813eb40(:0.0) drawable=0x0700145e ctx=0x7f6cf8c421c8
>         XQueryExtension (dpy=0x7f6cf813eb40(:0.0) name=XVideo *major_opcode=132 *first_event=72 *first_error=140 ) 0.051022 ms
>
>         glXCreatePbuffer (dpy=0x7f6cf8131000(:0.0) config=0x00000105(0x105) attrib_list=[0x8041=0x0168 0x8040=0x0121 0x801b=0x0001 ] pb=0x06e00008 ) 0.403166 ms
>       config=0x00000105(0x105) drawable=0x06e00008 ) 38.542032 ms
> [VGL] glViewport (x=0 y=0 width=360 height=289 ) 0.010014 ms


With the attached patch we get:

> [VGL] glXMakeCurrent (dpy=0x7fcc6c13cd90(:0.0) drawable=0x070011c9 ctx=0x7fcc6d5b42e8
> [VGL]        XQueryExtension (dpy=0x7fcc6c13cd90(:0.0) name=XVideo *major_opcode=132 *first_event=72 *first_error=140 ) 0.051022 ms
> [VGL]
> [VGL]        glXCreatePbuffer (dpy=0x7fcc6c12f250(:0.0) config=0x00000105(0x105) attrib_list=[0x8041=0x0168 0x8040=0x0121 0x801b=0x0001 ] pb=0x06e00008 )
> [VGL]      config=0x00000105(0x105) drawable=0x06e00008 ) 4.723072 ms
> [VGL] glViewport (x=0 y=0 width=360 height=289 ) 0.005960 ms

The reason I like this better is because there's no possibility for 
confusion of which lines came from VGL (think output from VGL and app 
both going to stderr/stdout).

The empty lines aren't so nice (coming from the 2nd modified line in the 
patch).  I don't see a way to fix it apart from a) being able to look up 
the last char written to the stream (again think mixed output to stream) 
or b) modifying all the prarg macros to print leading space if 
necessary.  The complexity doesn't seem worth it.

-Nathan