virtualgl-users Mailing List for VirtualGL (Page 11)
3D Without Boundaries
Brought to you by:
dcommander
Menu
▾
▴
virtualgl-users — VirtualGL User Discussion and Support (moved to Google Groups-- see http://www.VirtualGL.org/About/MailingLists)
You can subscribe to this list here.
| 2007 |
Jan
(1) |
Feb
(5) |
Mar
(7) |
Apr
(7) |
May
(1) |
Jun
(10) |
Jul
(5) |
Aug
(4) |
Sep
(16) |
Oct
(2) |
Nov
(8) |
Dec
(3) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
(6) |
Feb
(18) |
Mar
(6) |
Apr
(5) |
May
(15) |
Jun
(6) |
Jul
(23) |
Aug
(5) |
Sep
(9) |
Oct
(15) |
Nov
(7) |
Dec
(3) |
| 2009 |
Jan
(22) |
Feb
(13) |
Mar
(15) |
Apr
(3) |
May
(19) |
Jun
(1) |
Jul
(44) |
Aug
(16) |
Sep
(13) |
Oct
(32) |
Nov
(34) |
Dec
(6) |
| 2010 |
Jan
(5) |
Feb
(27) |
Mar
(28) |
Apr
(29) |
May
(19) |
Jun
(30) |
Jul
(14) |
Aug
(5) |
Sep
(17) |
Oct
(10) |
Nov
(13) |
Dec
(13) |
| 2011 |
Jan
(18) |
Feb
(34) |
Mar
(57) |
Apr
(39) |
May
(28) |
Jun
(2) |
Jul
(7) |
Aug
(17) |
Sep
(28) |
Oct
(25) |
Nov
(17) |
Dec
(15) |
| 2012 |
Jan
(15) |
Feb
(47) |
Mar
(40) |
Apr
(15) |
May
(15) |
Jun
(34) |
Jul
(44) |
Aug
(66) |
Sep
(34) |
Oct
(8) |
Nov
(37) |
Dec
(23) |
| 2013 |
Jan
(14) |
Feb
(26) |
Mar
(38) |
Apr
(27) |
May
(33) |
Jun
(67) |
Jul
(14) |
Aug
(39) |
Sep
(24) |
Oct
(59) |
Nov
(29) |
Dec
(16) |
| 2014 |
Jan
(21) |
Feb
(17) |
Mar
(21) |
Apr
(11) |
May
(10) |
Jun
(2) |
Jul
(10) |
Aug
|
Sep
(23) |
Oct
(16) |
Nov
(7) |
Dec
(2) |
| 2015 |
Jan
(7) |
Feb
|
Mar
(26) |
Apr
|
May
(2) |
Jun
(16) |
Jul
(1) |
Aug
(5) |
Sep
(6) |
Oct
(10) |
Nov
(5) |
Dec
(6) |
| 2016 |
Jan
|
Feb
(6) |
Mar
|
Apr
(2) |
May
|
Jun
(6) |
Jul
(5) |
Aug
|
Sep
(17) |
Oct
(6) |
Nov
(2) |
Dec
(4) |
| 2017 |
Jan
(3) |
Feb
(25) |
Mar
(4) |
Apr
(3) |
May
(4) |
Jun
(10) |
Jul
(1) |
Aug
(8) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: DRC <dco...@us...> - 2014-05-28 16:04:32
|
Cool. Problems that solve themselves are my favorite kind. :) > On May 28, 2014, at 4:01 AM, Paul Melis <pau...@su...> wrote: > > Okay, we figured out what was going on, the application in question > created a new GLUT window explictly on :0.0. So VGL was not to blame... > > Paul > >> On 21-05-14 14:28, Paul Melis wrote: >> Here's a trace and the two pieces of xwininfo output (gui.info = :1, >> viewer.info = :0). I see an XCreateWindow on :0.0 by VGL, but can't tell >> if that's coming from VGL, or from the app and gets intercepted by VGL. >> There was some output of the app in the trace output that I removed, btw. >> >> Paul >> >>> On 05/21/2014 01:23 AM, DRC wrote: >>> I've learned never to say that anything is impossible, because I usually >>> end up being proven wrong, but let's just say that if VirtualGL is >>> causing this, it is by way of an as-yet-undiscovered mechanism that I >>> can't at the present moment fathom. VirtualGL doesn't modify the >>> display argument of any functions except GLX functions. >>> >>> Can you send me a VGL trace of the application along with a list of the >>> window handles (obtainable with xwininfo) from the window that is on >>> display :1 and the window that is on display :0? >>> >>> >>>> On 5/20/14 4:37 PM, Paul Melis wrote: >>>> Hi DRC, >>>> >>>> I'm afraid sharing the app is a bit difficult... >>>> >>>> I did some more testing on my home machine, using a TigerVNC server and >>>> VirtualGL 2.3.3. What seems to be happening is that when I start the app >>>> with vglrun within the VNC session the GUI window indeed ends up on >>>> DISPLAY :1 in side the VNC session, but the rendering window ends up on >>>> DISPLAY :0, i.e. outside the VNC session. I can't tell if the rendering >>>> window starts out on :1 and then gets moved to :0 or if it is created on >>>> :0 in the first place. >>>> >>>> It's a single-process app written with what looks like FLTK, so I would >>>> expect both windows to just get created on the same X display. Is it >>>> possible that VirtualGL causes the different displays to be used? >>>> >>>> Regards, >>>> Paul >>> ------------------------------------------------------------------------------ >>> >>> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE >>> Instantly run your Selenium tests across 300+ browser/OS combos. >>> Get unparalleled scalability from the best Selenium testing platform >>> available >>> Simple to use. Nothing to install. Get started now for free." >>> http://p.sf.net/sfu/SauceLabs >>> _______________________________________________ >>> VirtualGL-Users mailing list >>> Vir...@li... >>> https://lists.sourceforge.net/lists/listinfo/virtualgl-users >> >> >> >> ------------------------------------------------------------------------------ >> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE >> Instantly run your Selenium tests across 300+ browser/OS combos. >> Get unparalleled scalability from the best Selenium testing platform available >> Simple to use. Nothing to install. Get started now for free." >> http://p.sf.net/sfu/SauceLabs >> >> >> >> _______________________________________________ >> VirtualGL-Users mailing list >> Vir...@li... >> https://lists.sourceforge.net/lists/listinfo/virtualgl-users > > > -- > ** SURFsara heeft een nieuw algemeen telefoonnummer: 020 800 1300 ** > > Paul Melis > | Groepsleider & Adviseur Visualisatie | SURFsara | > | Science Park 140 | 1098 XG Amsterdam | > | T 020 592 30 59 | pau...@su... | www.surfsara.nl | > > ------------------------------------------------------------------------------ > Time is money. Stop wasting it! Get your web API in 5 minutes. > www.restlet.com/download > http://p.sf.net/sfu/restlet > _______________________________________________ > VirtualGL-Users mailing list > Vir...@li... > https://lists.sourceforge.net/lists/listinfo/virtualgl-users |
|
From: Paul M. <pau...@su...> - 2014-05-28 09:01:32
|
Okay, we figured out what was going on, the application in question created a new GLUT window explictly on :0.0. So VGL was not to blame... Paul On 21-05-14 14:28, Paul Melis wrote: > Here's a trace and the two pieces of xwininfo output (gui.info = :1, > viewer.info = :0). I see an XCreateWindow on :0.0 by VGL, but can't tell > if that's coming from VGL, or from the app and gets intercepted by VGL. > There was some output of the app in the trace output that I removed, btw. > > Paul > > On 05/21/2014 01:23 AM, DRC wrote: >> I've learned never to say that anything is impossible, because I usually >> end up being proven wrong, but let's just say that if VirtualGL is >> causing this, it is by way of an as-yet-undiscovered mechanism that I >> can't at the present moment fathom. VirtualGL doesn't modify the >> display argument of any functions except GLX functions. >> >> Can you send me a VGL trace of the application along with a list of the >> window handles (obtainable with xwininfo) from the window that is on >> display :1 and the window that is on display :0? >> >> >> On 5/20/14 4:37 PM, Paul Melis wrote: >>> Hi DRC, >>> >>> I'm afraid sharing the app is a bit difficult... >>> >>> I did some more testing on my home machine, using a TigerVNC server and >>> VirtualGL 2.3.3. What seems to be happening is that when I start the app >>> with vglrun within the VNC session the GUI window indeed ends up on >>> DISPLAY :1 in side the VNC session, but the rendering window ends up on >>> DISPLAY :0, i.e. outside the VNC session. I can't tell if the rendering >>> window starts out on :1 and then gets moved to :0 or if it is created on >>> :0 in the first place. >>> >>> It's a single-process app written with what looks like FLTK, so I would >>> expect both windows to just get created on the same X display. Is it >>> possible that VirtualGL causes the different displays to be used? >>> >>> Regards, >>> Paul >> ------------------------------------------------------------------------------ >> >> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE >> Instantly run your Selenium tests across 300+ browser/OS combos. >> Get unparalleled scalability from the best Selenium testing platform >> available >> Simple to use. Nothing to install. Get started now for free." >> http://p.sf.net/sfu/SauceLabs >> _______________________________________________ >> VirtualGL-Users mailing list >> Vir...@li... >> https://lists.sourceforge.net/lists/listinfo/virtualgl-users > > > > ------------------------------------------------------------------------------ > "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE > Instantly run your Selenium tests across 300+ browser/OS combos. > Get unparalleled scalability from the best Selenium testing platform available > Simple to use. Nothing to install. Get started now for free." > http://p.sf.net/sfu/SauceLabs > > > > _______________________________________________ > VirtualGL-Users mailing list > Vir...@li... > https://lists.sourceforge.net/lists/listinfo/virtualgl-users > -- ** SURFsara heeft een nieuw algemeen telefoonnummer: 020 800 1300 ** Paul Melis | Groepsleider & Adviseur Visualisatie | SURFsara | | Science Park 140 | 1098 XG Amsterdam | | T 020 592 30 59 | pau...@su... | www.surfsara.nl | |
|
From: Paul M. <pau...@su...> - 2014-05-21 12:29:34
|
Here's a trace and the two pieces of xwininfo output (gui.info = :1, viewer.info = :0). I see an XCreateWindow on :0.0 by VGL, but can't tell if that's coming from VGL, or from the app and gets intercepted by VGL. There was some output of the app in the trace output that I removed, btw. Paul On 05/21/2014 01:23 AM, DRC wrote: > I've learned never to say that anything is impossible, because I usually > end up being proven wrong, but let's just say that if VirtualGL is > causing this, it is by way of an as-yet-undiscovered mechanism that I > can't at the present moment fathom. VirtualGL doesn't modify the > display argument of any functions except GLX functions. > > Can you send me a VGL trace of the application along with a list of the > window handles (obtainable with xwininfo) from the window that is on > display :1 and the window that is on display :0? > > > On 5/20/14 4:37 PM, Paul Melis wrote: >> Hi DRC, >> >> I'm afraid sharing the app is a bit difficult... >> >> I did some more testing on my home machine, using a TigerVNC server and >> VirtualGL 2.3.3. What seems to be happening is that when I start the app >> with vglrun within the VNC session the GUI window indeed ends up on >> DISPLAY :1 in side the VNC session, but the rendering window ends up on >> DISPLAY :0, i.e. outside the VNC session. I can't tell if the rendering >> window starts out on :1 and then gets moved to :0 or if it is created on >> :0 in the first place. >> >> It's a single-process app written with what looks like FLTK, so I would >> expect both windows to just get created on the same X display. Is it >> possible that VirtualGL causes the different displays to be used? >> >> Regards, >> Paul > ------------------------------------------------------------------------------ > "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE > Instantly run your Selenium tests across 300+ browser/OS combos. > Get unparalleled scalability from the best Selenium testing platform available > Simple to use. Nothing to install. Get started now for free." > http://p.sf.net/sfu/SauceLabs > _______________________________________________ > VirtualGL-Users mailing list > Vir...@li... > https://lists.sourceforge.net/lists/listinfo/virtualgl-users |
|
From: DRC <dco...@us...> - 2014-05-20 23:23:12
|
I've learned never to say that anything is impossible, because I usually end up being proven wrong, but let's just say that if VirtualGL is causing this, it is by way of an as-yet-undiscovered mechanism that I can't at the present moment fathom. VirtualGL doesn't modify the display argument of any functions except GLX functions. Can you send me a VGL trace of the application along with a list of the window handles (obtainable with xwininfo) from the window that is on display :1 and the window that is on display :0? On 5/20/14 4:37 PM, Paul Melis wrote: > Hi DRC, > > I'm afraid sharing the app is a bit difficult... > > I did some more testing on my home machine, using a TigerVNC server and > VirtualGL 2.3.3. What seems to be happening is that when I start the app > with vglrun within the VNC session the GUI window indeed ends up on > DISPLAY :1 in side the VNC session, but the rendering window ends up on > DISPLAY :0, i.e. outside the VNC session. I can't tell if the rendering > window starts out on :1 and then gets moved to :0 or if it is created on > :0 in the first place. > > It's a single-process app written with what looks like FLTK, so I would > expect both windows to just get created on the same X display. Is it > possible that VirtualGL causes the different displays to be used? > > Regards, > Paul |
|
From: Paul M. <pau...@su...> - 2014-05-20 21:51:12
|
Hi DRC, I'm afraid sharing the app is a bit difficult... I did some more testing on my home machine, using a TigerVNC server and VirtualGL 2.3.3. What seems to be happening is that when I start the app with vglrun within the VNC session the GUI window indeed ends up on DISPLAY :1 in side the VNC session, but the rendering window ends up on DISPLAY :0, i.e. outside the VNC session. I can't tell if the rendering window starts out on :1 and then gets moved to :0 or if it is created on :0 in the first place. It's a single-process app written with what looks like FLTK, so I would expect both windows to just get created on the same X display. Is it possible that VirtualGL causes the different displays to be used? Regards, Paul On 05/20/2014 05:30 AM, DRC wrote: > Unfortunately not. Is this something that could be readily reproduced > without using your cluster? That is, on a regular PC? Is the app > something I could download and test? > > > On 5/16/14 9:18 AM, Paul Melis wrote: >> Hi all, >> >> I'm trying to run a 32-bit application on a 64-bit Linux cluster under >> VirtualGL. The app starts, but right after startup the window containing >> the OpenGL view is briefly visible and then disappears, it simply >> vanishes (the separate FLTK GUI windows does stay around). If I run with >> vglrun +pr I can see from the stats that some kind of rendering is going >> on, though, strangely enough. >> >> Does this sound familiar to anyone? Any clues what is going on? >> >> Regards, >> Paul >> > ------------------------------------------------------------------------------ > "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE > Instantly run your Selenium tests across 300+ browser/OS combos. > Get unparalleled scalability from the best Selenium testing platform available > Simple to use. Nothing to install. Get started now for free." > http://p.sf.net/sfu/SauceLabs > _______________________________________________ > VirtualGL-Users mailing list > Vir...@li... > https://lists.sourceforge.net/lists/listinfo/virtualgl-users |
|
From: DRC <dco...@us...> - 2014-05-20 03:30:59
|
Unfortunately not. Is this something that could be readily reproduced without using your cluster? That is, on a regular PC? Is the app something I could download and test? On 5/16/14 9:18 AM, Paul Melis wrote: > Hi all, > > I'm trying to run a 32-bit application on a 64-bit Linux cluster under > VirtualGL. The app starts, but right after startup the window containing > the OpenGL view is briefly visible and then disappears, it simply > vanishes (the separate FLTK GUI windows does stay around). If I run with > vglrun +pr I can see from the stats that some kind of rendering is going > on, though, strangely enough. > > Does this sound familiar to anyone? Any clues what is going on? > > Regards, > Paul > |
|
From: DRC <dco...@us...> - 2014-05-20 03:29:51
|
This list is now just for VirtualGL users. There is a new list, tur...@li..., for TurboVNC users. Please use it in the future for TurboVNC questions. To answer your question, the vncserver script is definitely there. It is in /opt/TurboVNC/bin, as the documentation clearly indicates. It is placed there intentionally so as to avoid conflicting with any VNC installation that might be installed in /usr/bin. > dpkg --contents turbovnc_1.2.1_amd64.deb drwx------ drc/drc 0 2013-11-22 13:55:53 ./ drwxr-xr-x root/root 0 2013-11-22 13:55:53 ./opt/ drwxr-xr-x root/root 0 2013-11-22 13:55:53 ./opt/TurboVNC/ drwxr-xr-x root/root 0 2013-11-22 13:55:53 ./opt/TurboVNC/man/ drwxr-xr-x root/root 0 2013-11-22 13:55:53 ./opt/TurboVNC/man/man1/ -rw-r--r-- root/root 1260 2010-06-28 20:49:43 ./opt/TurboVNC/man/man1/vncconnect.1 -rw-r--r-- root/root 8535 2013-10-18 15:51:55 ./opt/TurboVNC/man/man1/vncserver.1 -rw-r--r-- root/root 22739 2012-11-19 17:01:55 ./opt/TurboVNC/man/man1/Xvnc.1 -rw-r--r-- root/root 27344 2013-10-16 21:31:33 ./opt/TurboVNC/man/man1/vncviewer.1 -rw-r--r-- root/root 26446 2012-07-28 14:37:27 ./opt/TurboVNC/man/man1/Xserver.1 -rw-r--r-- root/root 5529 2013-10-18 15:58:22 ./opt/TurboVNC/man/man1/vncpasswd.1 -rw-r--r-- root/root 7598 2013-09-19 21:56:10 ./opt/TurboVNC/README.txt drwxr-xr-x root/root 0 2013-11-22 13:55:53 ./opt/TurboVNC/bin/ -rwxr-xr-x root/root 2715626 2013-11-22 13:55:52 ./opt/TurboVNC/bin/Xvnc -rwxr-xr-x root/root 9729 2013-11-22 13:54:21 ./opt/TurboVNC/bin/vncconnect -rwxr-xr-x root/root 29549 2013-11-22 13:54:22 ./opt/TurboVNC/bin/vncpasswd -rwxr-xr-x root/root 25541 2013-11-22 13:54:21 ./opt/TurboVNC/bin/tvncconfig -rwxr-xr-x root/root 29209 2013-11-22 13:54:15 ./opt/TurboVNC/bin/vncserver -rwxr-xr-x root/root 596845 2013-11-22 13:54:21 ./opt/TurboVNC/bin/vncviewer drwxr-xr-x root/root 0 2013-11-22 13:55:53 ./opt/TurboVNC/java/ -rw-r--r-- root/root 459608 2013-11-22 13:54:38 ./opt/TurboVNC/java/VncViewer.jar -rw-r--r-- root/root 894 2012-08-07 01:45:19 ./opt/TurboVNC/java/favicon.ico -rw-r--r-- root/root 8161 2013-09-19 21:47:51 ./opt/TurboVNC/java/README.txt -rw-r--r-- root/root 720 2012-07-31 16:01:51 ./opt/TurboVNC/java/index.vnc drwxr-xr-x root/root 0 2013-11-22 13:55:53 ./etc/ drwxr-xr-x root/root 0 2013-11-22 13:55:53 ./etc/init.d/ -rwxr-xr-x root/root 2768 2013-11-22 13:54:15 ./etc/init.d/tvncserver drwxr-xr-x root/root 0 2013-11-22 13:55:53 ./etc/sysconfig/ -rw-r--r-- root/root 1005 2012-07-31 16:01:51 ./etc/sysconfig/tvncservers -rw-r--r-- root/root 2298 2012-04-05 01:59:02 ./etc/turbovncserver.conf -rw-r--r-- root/root 2444 2011-11-05 19:51:23 ./etc/turbovncserver-auth.conf drwxr-xr-x root/root 0 2013-11-22 13:55:53 ./usr/ drwxr-xr-x root/root 0 2013-11-22 13:55:53 ./usr/share/ drwxr-xr-x root/root 0 2013-11-22 13:55:53 ./usr/share/applications/ -rw-r--r-- root/root 182 2013-11-22 13:55:53 ./usr/share/applications/tvncviewer.desktop drwxr-xr-x root/root 0 2013-11-22 13:55:53 ./usr/share/doc/ drwxr-xr-x root/root 0 2013-11-22 13:55:53 ./usr/share/doc/turbovnc-1.2.1/ -rw-r--r-- root/root 4739 2009-09-11 15:20:46 ./usr/share/doc/turbovnc-1.2.1/somerights20.png -rw-r--r-- root/root 105664 2013-11-22 12:24:11 ./usr/share/doc/turbovnc-1.2.1/index.html -rw-r--r-- root/root 18092 2012-03-28 16:05:25 ./usr/share/doc/turbovnc-1.2.1/LICENSE.txt -rw-r--r-- root/root 1805 2012-08-24 03:14:08 ./usr/share/doc/turbovnc-1.2.1/newconn-x11.png -rw-r--r-- root/root 123506 2012-08-24 03:14:08 ./usr/share/doc/turbovnc-1.2.1/unixauth-java.png -rw-r--r-- root/root 17883 2013-05-15 00:49:19 ./usr/share/doc/turbovnc-1.2.1/newconn-java.png -rw-r--r-- root/root 50774 2009-09-13 21:35:36 ./usr/share/doc/turbovnc-1.2.1/x11transport.png -rw-r--r-- root/root 68607 2009-09-13 21:35:36 ./usr/share/doc/turbovnc-1.2.1/vgltransportservernetwork.png -rw-r--r-- root/root 2811 2012-08-24 03:14:08 ./usr/share/doc/turbovnc-1.2.1/unixauth-x11.png -rw-r--r-- root/root 2319 2010-05-12 16:37:36 ./usr/share/doc/turbovnc-1.2.1/turbovnc.css -rw-r--r-- root/root 124002 2012-08-24 03:14:08 ./usr/share/doc/turbovnc-1.2.1/vncauth-java.png -rw-r--r-- root/root 1279 2009-09-11 15:20:46 ./usr/share/doc/turbovnc-1.2.1/LICENSE-PuTTY.txt -rw-r--r-- root/root 6915 2012-08-24 03:14:08 ./usr/share/doc/turbovnc-1.2.1/vncauth-win.png -rw-r--r-- root/root 6804 2012-08-24 03:14:08 ./usr/share/doc/turbovnc-1.2.1/unixauth-win.png -rw-r--r-- root/root 1655 2012-08-24 03:14:08 ./usr/share/doc/turbovnc-1.2.1/vncauth-x11.png -rw-r--r-- root/root 5990 2013-05-15 00:49:19 ./usr/share/doc/turbovnc-1.2.1/newconn-win.png On 5/19/14 8:17 PM, jupiter wrote: > Hi, > > Is turbovnc_1.2.1_amd64.deb include turbovnc server? I downloaded and > installed it, but could not find vncserver. |
|
From: jupiter <jup...@gm...> - 2014-05-20 01:18:01
|
Hi, Is turbovnc_1.2.1_amd64.deb include turbovnc server? I downloaded and installed it, but could not find vncserver. Thank you. |
|
From: Paul M. <pau...@su...> - 2014-05-16 14:31:36
|
Hi all, I'm trying to run a 32-bit application on a 64-bit Linux cluster under VirtualGL. The app starts, but right after startup the window containing the OpenGL view is briefly visible and then disappears, it simply vanishes (the separate FLTK GUI windows does stay around). If I run with vglrun +pr I can see from the stats that some kind of rendering is going on, though, strangely enough. Does this sound familiar to anyone? Any clues what is going on? Regards, Paul -- ** SURFsara heeft een nieuw algemeen telefoonnummer: 020 800 1300 ** Paul Melis | Groepsleider & Adviseur Visualisatie | SURFsara | | Science Park 140 | 1098 XG Amsterdam | | T 020 592 30 59 | pau...@su... | www.surfsara.nl | |
|
From: DRC <dco...@us...> - 2014-05-01 21:00:52
|
I am pleased to report that the spinoff of TurboVNC into a separate
project has been completed.
What has changed
================
Mailing lists
-------------
Perhaps most important for those reading this-- there are three new
mailing lists specific to TurboVNC (turbovnc-announce, turbovnc-users,
turbovnc-devel.) If you are an active customer of mine who is using
TurboVNC, or if your e-mail address contained the word "TurboVNC" in it
(pretty obvious), then I automatically copied your subscription from
virtualgl-{} to turbovnc-{}, but otherwise, please take a moment to
subscribe to one or more of the new lists if you want to continue
receiving information about TurboVNC:
http://sourceforge.net/p/turbovnc/mailman/
You may also want to unsubscribe from the virtualgl-* mailing lists if
you don't care about VirtualGL. The virtualgl-* mailing lists will be,
from this moment forward, for discussing VirtualGL only.
Downloads
---------
-- VirtualGL files are now at:
http://sourceforge.net/projects/virtualgl/files/
-- TurboVNC files are now at:
http://sourceforge.net/projects/turbovnc/files/
Please update any packaging scripts and documentation to reflect the new
URLs. Unfortunately, SourceForge doesn't allow symlinking within the
file release directories, so I can't maintain backward compatibility here.
Web sites
---------
-- TurboVNC now has its own SourceForge project page at
http://www.sourceforge.net/projects/turbovnc. All TurboVNC bugs,
feature requests, and patches have been moved into that tracker. Both
the VirtualGL and TurboVNC SourceForge pages contain a link to the
other, for convenience.
-- All of the TurboVNC content that used to be on VirtualGL.org is now
on http://www.TurboVNC.org. That includes all of the sponsors and
projects on the "Sponsors" page that were specific to TurboVNC.
-- The pre-release builds for TurboVNC are now at:
http://www.turbovnc.org/DeveloperInfo/PreReleases
Subversion
----------
The VirtualGL and TurboVNC subversion repositories have been split and
re-imported. Thus, it is no longer necessary to add "vgl" or "vnc" to
the end of the subversion URL when doing a checkout. The new URLs for
anonymous checkout are:
-- VirtualGL:
svn://svn.code.sf.net/p/virtualgl/code
-- TurboVNC:
svn://svn.code.sf.net/p/turbovnc/code
(add "trunk" or "branches/*" or "tags/*" to these URLs to check out a
specific version.)
Unfortunately, you will have to re-checkout existing working copies.
There is no way to use 'svn switch' to migrate the working copies,
because the revision numbering has changed.
New icons/logos
---------------
For the time being, I have updated the icons and logos to use a more
modern (fire-engine-red) color scheme. I am, however, looking for a
graphic artist who would be willing to design a new logo for the
project. If you or someone you know might be interested, let me know.
What hasn't changed
===================
"The VirtualGL Project" is still the name of the entity that manages
both VirtualGL and TurboVNC.
Our Facebook and LinkedIn pages will still contain both VirtualGL and
TurboVNC content.
|
|
From: DRC <dco...@us...> - 2014-04-24 02:58:26
|
In order to increase the visibility of TurboVNC in the open source community, I think it may be time to consider spinning it off from The VirtualGL Project. When VirtualGL was first open sourced 10 years ago, it made sense to include TurboVNC in the same project, because there were no other open source X proxies available at the time that had the necessary performance to handle 3D workloads. During the Sun years, both projects were tied at the hip in the Sun Shared Visualization product, so it made even more sense for them to share online resources. However, although I believe that TurboVNC's performance and quality are the best in its class, there are now quite a few other X proxies that provide sufficient performance for 3D workloads as well. Although TurboVNC is well known in the visualization community, by virtue of its association with VirtualGL, I feel like there are a lot of potential users of the product who haven't heard of it because it's tucked away in The VirtualGL Project. I've run across others who assume that TurboVNC can only be used with VirtualGL (well, they're sort of right if they're using a 3D application, but not other applications.) When you go to the VirtualGL project page on SourceForge, it lists TigerVNC as a recommended project. I want TurboVNC in that list as well. Further, I don't want to see anyone still trying to use TightVNC 1.3.x (it happens more often than you'd think.) If anyone has any strong objections, please let me know. This isn't a done deal yet. I want to get your feedback and concerns, in case there might be some potential downsides that I have not considered. |
|
From: DRC <dco...@us...> - 2014-04-13 20:03:11
|
So, let me break this down: We don't support RPi as a server platform for VirtualGL. You are asking for support on something that is not supported and may not even be supportable in the context of this project. You are attempting to do something that no one else has attempted, so you're pretty much on your own for troubleshooting. I don't know for sure whether RPi even supports accelerated GLX. It may not. That question is for another forum, not this one. I am simply saying that accelerated GLX is a prerequisite for using VirtualGL, in its current form, with that platform. Using VirtualGL in its current form may or may not even be useful for what you're ultimately trying to do. You are trying to run OpenGL ES applications remotely, but most OpenGL ES applications are not X applications. VirtualGL and TurboVNC only work with X/GLX applications. VirtualGL could be extended to support X/EGL applications, thus providing OpenGL ES support for the small subclass of OpenGL ES applications that are also X applications. However, most OpenGL ES applications are not X applications, so this would be of very limited benefit. This is not going to be the appropriate forum to ask for support in bringing up accelerated drivers and accessing your GPU through the X server. You need to ask people more familiar with RPi about that. Assuming you can get the accelerated drivers up and running and access your GPU through the X server, then please post here if you are still having problems that are specific to VirtualGL. If you have any further information regarding the types of OpenGL ES applications you want to run remotely, information that might affect my assessment of the general usefulness (or lack thereof) of adding OpenGL ES support to VirtualGL, then please follow up. On 4/13/14 1:12 PM, George Profenza wrote: > Thank you ! This is starting to make sense, little by little. > > I was looking for a GLX extension through the available packages: > " > libegl1-mesa - free implementation of the EGL API -- runtime > libgl1-mesa-dev - free implementation of the OpenGL API -- GLX > development files > libgl1-mesa-dri - free implementation of the OpenGL API -- DRI modules > libgl1-mesa-dri-dbg - Debugging symbols for the Mesa DRI modules > libgl1-mesa-dri-experimental - free implementation of the OpenGL API -- > Extra DRI modules > libgl1-mesa-dri-experimental-dbg - Debugging symbols for the > experimental Mesa DRI modules > libgl1-mesa-glx - free implementation of the OpenGL API -- GLX runtime > libgl1-mesa-glx-dbg - Debugging symbols for the Mesa GLX runtime > libgl1-mesa-swx11 - free implementation of the OpenGL API -- runtime > libgl1-mesa-swx11-dbg - free implementation of the OpenGL API -- > debugging symbols > libgl1-mesa-swx11-dev - free implementation of the OpenGL API -- > development files > libopengl-perl - Perl interface providing graphics display using OpenGL > libswt-glx-gtk-3-jni - Standard Widget Toolkit for GTK+ GLX JNI library > libva-glx1 - Video Acceleration (VA) API for Linux -- GLX runtime > libxcb-glx0 - X C Binding, glx extension > libxcb-glx0-dbg - X C Binding, glx extension, debugging symbols > libxcb-glx0-dev - X C Binding, glx extension, development files > mesa-utils - Miscellaneous Mesa GL utilities > rss-glx - Really Slick Screensavers GLX Port > " > I went ahead and installed libegl1-mesa-dev libgl1-mesa-glx > libswt-glx-gtk-3-jni libva-glx1 libxcb-glx0 mesa-utils > but xdpyinfo still doesn't list a GLX extension. I'm currently looking > at mesa (http://www.mesa3d.org/egl.html) > and thinking about compiling from source with "egl_glx". Will that > enable the GLX extension I need or allow me to > view gl content through vnc (even if not hardware accelerated) ? > > I had a quick look at the Raspberry Pi specs again: > The GPU is Broadcom's VideoCore > IV(http://www.broadcom.com/products/BCM2835), > currently sharing 128MB from the 512MB available on the system. > > From what I understand from "the presence of accelerated 3D drivers > (i.e. the GLX vendor > strings and the OpenGL renderer string should not have the word > "software" or "Mesa" in them.)" the above will not completely resolve > the problem and I won't be able to use VirtualGL, correct ? > > Will I be able to see a EGL content through a vnc connection even if not > hardware accelerated ? > > All my best, > George |
|
From: George P. <or...@gm...> - 2014-04-13 18:13:14
|
Thank you ! This is starting to make sense, little by little. I was looking for a GLX extension through the available packages: " libegl1-mesa - free implementation of the EGL API -- runtime libgl1-mesa-dev - free implementation of the OpenGL API -- GLX development files libgl1-mesa-dri - free implementation of the OpenGL API -- DRI modules libgl1-mesa-dri-dbg - Debugging symbols for the Mesa DRI modules libgl1-mesa-dri-experimental - free implementation of the OpenGL API -- Extra DRI modules libgl1-mesa-dri-experimental-dbg - Debugging symbols for the experimental Mesa DRI modules libgl1-mesa-glx - free implementation of the OpenGL API -- GLX runtime libgl1-mesa-glx-dbg - Debugging symbols for the Mesa GLX runtime libgl1-mesa-swx11 - free implementation of the OpenGL API -- runtime libgl1-mesa-swx11-dbg - free implementation of the OpenGL API -- debugging symbols libgl1-mesa-swx11-dev - free implementation of the OpenGL API -- development files libopengl-perl - Perl interface providing graphics display using OpenGL libswt-glx-gtk-3-jni - Standard Widget Toolkit for GTK+ GLX JNI library libva-glx1 - Video Acceleration (VA) API for Linux -- GLX runtime libxcb-glx0 - X C Binding, glx extension libxcb-glx0-dbg - X C Binding, glx extension, debugging symbols libxcb-glx0-dev - X C Binding, glx extension, development files mesa-utils - Miscellaneous Mesa GL utilities rss-glx - Really Slick Screensavers GLX Port " I went ahead and installed libegl1-mesa-dev libgl1-mesa-glx libswt-glx-gtk-3-jni libva-glx1 libxcb-glx0 mesa-utils but xdpyinfo still doesn't list a GLX extension. I'm currently looking at mesa (http://www.mesa3d.org/egl.html) and thinking about compiling from source with "egl_glx". Will that enable the GLX extension I need or allow me to view gl content through vnc (even if not hardware accelerated) ? I had a quick look at the Raspberry Pi specs again: The GPU is Broadcom's VideoCore IV(http://www.broadcom.com/products/BCM2835 ), currently sharing 128MB from the 512MB available on the system. >From what I understand from "the presence of accelerated 3D drivers (i.e. the GLX vendor strings and the OpenGL renderer string should not have the word "software" or "Mesa" in them.)" the above will not completely resolve the problem and I won't be able to use VirtualGL, correct ? Will I be able to see a EGL content through a vnc connection even if not hardware accelerated ? All my best, George On Sun, Apr 13, 2014 at 3:59 PM, DRC <dco...@us...>wrote: > From VirtualGL's point of view, there are two issues with the X server > that is running on your Raspberry Pi: > > -- It needs a GLX extension. You can see from the output of xdpyinfo > that it currently lacks one. > -- It appears to be currently running with a depth of 16. It needs to > be running with a depth of 24. > > Those settings are generally changed in xorg.conf, but more important > than the presence of a GLX extension is the presence of a GPU for it to > leverage. I am not familiar with what GPU is in Raspberry Pi and how to > configure the X server to take advantage of it. What I can tell you is > that, before you're going to be able to successfully use VGL, the output > of xdpyinfo will need to show the presence of a GLX extension on display > :0 with "depth of the root window" = 24 or 32, and the output of > '/opt/VirtualGL/bin/glxinfo -display :0 -c' will need to indicate the > presence of Pbuffer support (refer to the VirtualGL User's Guide) as > well as the presence of accelerated 3D drivers (i.e. the GLX vendor > strings and the OpenGL renderer string should not have the word > "software" or "Mesa" in them.) > > > On 4/13/14 7:57 AM, George Profenza wrote: > > Thank you again for the detailed answer. > > > > Unfortunately, since I am not very experienced I am hoping you can still > > help with a few (hopefully) simple questions. > > You mentioned I should " get a "3D X server" up and running just like > > you would when using > > VirtualGL with a "regular" PC. " > > I'm not 100% what you meant. Had a quick look at what x11 packages are > > available and I can easily install these: > > x11-apps x11proto-kb-dev x11proto-xf86dri-dev > > x11-common x11proto-print-dev x11proto-xf86misc-dev > > x11proto-bigreqs-dev x11proto-randr-dev > x11proto-xf86vidmode-dev > > x11proto-composite-dev x11proto-record-dev x11proto-xinerama-dev > > x11proto-core-dev x11proto-render-dev x11-session-utils > > x11proto-damage-dev x11proto-resource-dev x11-utils > > x11proto-dmx-dev x11proto-scrnsaver-dev x11vnc > > x11proto-dri2-dev x11proto-video-dev x11vnc-data > > x11proto-fixes-dev x11proto-xcmisc-dev x11-xfs-utils > > x11proto-fonts-dev x11proto-xext-dev x11-xkb-utils > > x11proto-gl-dev x11proto-xf86bigfont-dev x11-xserver-utils > > x11proto-input-dev x11proto-xf86dga-dev > > > > I've installed the gl-dev, dri2-dev,dmx-dev packages and also > > mesa-common-dev and mesa-utils > > Also tried using some of the info tools but it doesn't look great: > > " > > pi@picam2 ~ $ glxinfo > > name of display: :0.0 > > Error: couldn't find RGB GLX visual or fbconfig > > > > pi@picam2 ~ $ glxgears > > Error: couldn't get an RGB, Double-buffered visual > > pi@picam2 ~ $ glxdemo > > Error: couldn't get an RGB, Double-buffered visual > > pi@picam2 ~ $ glxheads > > glxheads: exercise multiple GLX connections (any key = exit) > > Usage: > > glxheads xdisplayname ... > > Example: > > glxheads :0 mars:0 venus:1 > > Error on display :0.0 - Unable to find RGB, double-buffered visual > > pi@picam2 ~ $ glxheads :0 > > Error on display :0 - Unable to find RGB, double-buffered visual > > pi@picam2 ~ $ glxheads :0.0 > > Error on display :0.0 - Unable to find RGB, double-buffered visual > > pi@picam2 ~ $ > > " > > > > I've going through the manual and got a bit stuck at "VGL Transport with > > X11 Forwarding". > > I've previously "granted access to the 3D server" > > using /etc/init.d/lightdm stop, running vglserver_config (with options > > n,n,n), restarted the display manager > > and got this output from xdpyinfo: > > " > > pi@picam2 /opt/VirtualGL/bin $ xdpyinfo -display :0 > > name of display: :0 > > version number: 11.0 > > vendor string: The X.Org Foundation > > vendor release number: 11204000 > > X.Org version: 1.12.4 > > maximum request size: 16777212 bytes > > motion buffer size: 256 > > bitmap unit, bit order, padding: 32, LSBFirst, 32 > > image byte order: LSBFirst > > number of supported pixmap formats: 7 > > supported pixmap formats: > > depth 1, bits_per_pixel 1, scanline_pad 32 > > depth 4, bits_per_pixel 8, scanline_pad 32 > > depth 8, bits_per_pixel 8, scanline_pad 32 > > depth 15, bits_per_pixel 16, scanline_pad 32 > > depth 16, bits_per_pixel 16, scanline_pad 32 > > depth 24, bits_per_pixel 32, scanline_pad 32 > > depth 32, bits_per_pixel 32, scanline_pad 32 > > keycode range: minimum 8, maximum 255 > > focus: window 0x2000005, revert to Parent > > number of extensions: 25 > > BIG-REQUESTS > > Composite > > DAMAGE > > DOUBLE-BUFFER > > DPMS > > DRI2 > > Generic Event Extension > > MIT-SCREEN-SAVER > > MIT-SHM > > RANDR > > RECORD > > RENDER > > SECURITY > > SHAPE > > SYNC > > X-Resource > > XC-MISC > > XFIXES > > XFree86-DGA > > XFree86-VidModeExtension > > XINERAMA > > XInputExtension > > XKEYBOARD > > XTEST > > XVideo > > default screen number: 0 > > number of screens: 1 > > > > screen #0: > > dimensions: 656x512 pixels (174x135 millimeters) > > resolution: 96x96 dots per inch > > depths (7): 16, 1, 4, 8, 15, 24, 32 > > root window id: 0x43 > > depth of root window: 16 planes > > number of colormaps: minimum 1, maximum 1 > > default colormap: 0x20 > > default number of colormap cells: 64 > > preallocated pixels: black 0, white 65535 > > options: backing-store NO, save-unders NO > > largest cursor: 656x512 > > current input event mask: 0x7a003c > > ButtonPressMask ButtonReleaseMask EnterWindowMask > > LeaveWindowMask StructureNotifyMask > > SubstructureNotifyMask > > SubstructureRedirectMask FocusChangeMask PropertyChangeMask > > number of visuals: 2 > > default visual id: 0x21 > > visual: > > visual id: 0x21 > > class: TrueColor > > depth: 16 planes > > available colormap entries: 64 per subfield > > red, green, blue masks: 0xf800, 0x7e0, 0x1f > > significant bits in color specification: 8 bits > > visual: > > visual id: 0x41 > > class: TrueColor > > depth: 32 planes > > available colormap entries: 256 per subfield > > red, green, blue masks: 0xff0000, 0xff00, 0xff > > significant bits in color specification: 8 bits > > " > > Then I tried to connect and run glxspheres > > " > > pi@picam2 /opt/VirtualGL/bin $ ./vglconnect pi...@pi... > > > > VirtualGL Client 32-bit v2.3.3 (Build 20140413) > > vglclient is already running on this X display and accepting unencrypted > > connections on port 4242. > > > > pi...@pi...'s password: > > Linux picam2 3.10.36+ #665 PREEMPT Wed Apr 9 15:01:53 BST 2014 armv6l > > > > The programs included with the Debian GNU/Linux system are free software; > > the exact distribution terms for each program are described in the > > individual files in /usr/share/doc/*/copyright. > > > > Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent > > permitted by applicable law. > > Last login: Sun Apr 13 13:38:32 2014 from 192.168.0.14 > > pi@picam2 /opt/VirtualGL/bin $ ./vglrun ./glxspheres > > [VGL] NOTICE: Automatically setting VGL_CLIENT environment variable to > > [VGL] 192.168.0.14, the IP address of your SSh client. > > Polygons in scene: 62464 > > ERROR (603): Could not obtain RGB visual with requested properties > > pi@picam2 /opt/VirtualGL/bin $ ./vglconnect -x pi...@pi... > > > > VirtualGL Client 32-bit v2.3.3 (Build 20140413) > > vglclient is already running on this X display and accepting unencrypted > > connections on port 4242. > > > > mktemp: failed to create file via template `vglconnect.XXXXXX': > > Permission denied > > ^C > > pi@picam2 /opt/VirtualGL/bin $ sudo ./vglconnect -x pi...@pi... > > > > VirtualGL Client 32-bit v2.3.3 (Build 20140413) > > X11 connection rejected because of wrong authentication. > > start-- 534: Could not open display > > [VGL] ERROR: vglclient failed to execute. > > > > " > > > > Also, if it helps, here's the full ldd info on glxspheres: > > " > > pi@picam2 /opt/VirtualGL/bin $ ldd glxspheres > > /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so (0xb6f30000) > > libGL.so.1 => /usr/lib/arm-linux-gnueabihf/libGL.so.1 (0xb6ebb000) > > libX11.so.6 => /usr/lib/arm-linux-gnueabihf/libX11.so.6 (0xb6da7000) > > libGLU.so.1 => /usr/lib/arm-linux-gnueabihf/libGLU.so.1 (0xb6d4b000) > > libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0xb6cda000) > > libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6bab000) > > libglapi.so.0 => /usr/lib/arm-linux-gnueabihf/libglapi.so.0 (0xb6b84000) > > libXext.so.6 => /usr/lib/arm-linux-gnueabihf/libXext.so.6 (0xb6b6e000) > > libXdamage.so.1 => /usr/lib/arm-linux-gnueabihf/libXdamage.so.1 > (0xb6b64000) > > libXfixes.so.3 => /usr/lib/arm-linux-gnueabihf/libXfixes.so.3 > (0xb6b57000) > > libX11-xcb.so.1 => /usr/lib/arm-linux-gnueabihf/libX11-xcb.so.1 > (0xb6b4d000) > > libxcb-glx.so.0 => /usr/lib/arm-linux-gnueabihf/libxcb-glx.so.0 > (0xb6b34000) > > libxcb.so.1 => /usr/lib/arm-linux-gnueabihf/libxcb.so.1 (0xb6b15000) > > libXxf86vm.so.1 => /usr/lib/arm-linux-gnueabihf/libXxf86vm.so.1 > (0xb6b08000) > > libdrm.so.2 => /usr/lib/arm-linux-gnueabihf/libdrm.so.2 (0xb6af6000) > > libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0xb6ad6000) > > libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0xb6acb000) > > libstdc++.so.6 => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 > (0xb69fe000) > > libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0xb69d6000) > > /lib/ld-linux-armhf.so.3 (0xb6f3e000) > > libXau.so.6 => /usr/lib/arm-linux-gnueabihf/libXau.so.6 (0xb69cc000) > > libXdmcp.so.6 => /usr/lib/arm-linux-gnueabihf/libXdmcp.so.6 (0xb69bf000) > > librt.so.1 => /lib/arm-linux-gnueabihf/librt.so.1 (0xb69b0000) > > " > > > > At this point I am bit lost. Your suggestion of trying "to test > > VirtualGL as-is and verify that it works on that platform." sounds good. > > Can you please advise how I can continue with that ? > > > > Thank you again for all your support, > > George > > > > > > On Sun, Apr 6, 2014 at 5:38 PM, DRC <dco...@us... > > <mailto:dco...@us...>> wrote: > > > > On 4/6/14 5:06 AM, George Profenza wrote: > > > Thank you very much for the detailed explanations and your > patience. > > > > > > Using ldd on vglserver_config yelds:"not a dynamic executable" > > > For the gl apps I see all the linked libraries and > > > "libGL.so.1 => /usr/lib/arm-linux-gnueabihf/libGL.so.1 (0xb6f21000) > > > libGLU.so.1 => /usr/lib/arm-linux-gnueabihf/libGLU.so.1 > (0xb6ec5000) > > > libX11.so.6 => /usr/lib/arm-linux-gnueabihf/libX11.so.6 > (0xb6db1000)l > > > " > > > I can't run the demos though (E.g. glxspheres), I get this output: > > > " > > > Polygons in scene: 62464 > > > ERROR (603): Could not obtain RGB visual with requested properties > > > " > > > > > > So I guess the GL code in the sources need to be ported to GLES > > > and it sure doesn't look simple to me :) > > > > I really don't know anything about Raspberry Pi, but if it has > libX11, > > then apparently it does support a regular X server. Also, if you're > > getting that error message, then apparently it supports GLX as well > > (otherwise, GLXspheres wouldn't even run.) I suspect that EGL may be > > implemented as a wrapper to GLX, which means that you're going to > have > > to get a "3D X server" up and running just like you would when using > > VirtualGL with a "regular" PC. This would at least allow you to test > > VirtualGL as-is and verify that it works on that platform. > > > > There is a remote chance that EGL is implemented as a GLX wrapper and > > that the implementation is done in such a way that EGL applications > > could be made to work with VirtualGL as-is. Basically, this would be > > the case if the EGL API was in a separate library that made GLX calls > > into libGL. I suspect, however, that that's not how it works. It's > > more likely that the EGL calls are exposed in libGL itself, in which > > case VirtualGL would have to specifically interpose those calls. And > > GLXspheres and the other "toy" applications in the VGL source would > need > > to be ported to EGL. > > > > The other aspect of this is the windowing system. VirtualGL's basic > job > > is to split OpenGL and X11 rendering. VirtualGL redirects the OpenGL > > rendering to a "local" X server (the "3D X server") that is attached > to > > a GPU. It then reads back the rendered 3D pixels at the appropriate > > time and uses 2D drawing commands to composite those pixels back into > > the appropriate X window, which is displayed to a remote X server or > X > > proxy (the "2D X server".) Meanwhile, the other X11 drawing commands > > from the application go directly to the 2D X server. > > > > Thus, it goes without saying that, if an OpenGL ES application is not > > using X windows as a means of drawing its GUI, then VirtualGL will > not > > be applicable. This doesn't mean that the application has to > directly > > call X windows. It could be using a toolkit, such as GTK or Qt, that > > calls X windows "behind the scenes", but ultimately, there has to be > > some underlying communication between the application and libX11 in > > order for VirtualGL to work-- as well as VNC, since VNC is a virtual > X > > server. > > > > > > > > > I'm guessing by "science fair" you mean too localized > > > > Yes. The funding aspect is a sort of filter. If someone wants a > > feature badly enough to pay for it, then the feature usually tends > to be > > broadly applicable. It's quite often the case that one organization > > will pay me to implement a feature, and another organization will > start > > using the feature and pay me for follow-up work down the road. It is > > extremely rare that an organization will pay for a feature that is > only > > narrowly applicable. > > > > VirtualGL does have a "general fund" that pays for 200 hours/year of > my > > labor, but I have to be judicious with that, since it has to cover > any > > time I spend doing releases and answering e-mails on the mailing > lists > > and doing code cleanup, etc. I have, on occasion, used that fund to > pay > > for new feature implementations, but it really has to be something > that > > is very compelling and something that I feel will move the project > > forward. > > > > > > > The project looks very useful. It must be pretty hard code for you > being > > > the only maintainer. > > > I'm wondering if crowd funding would work to help with the > financial > > > support needed. > > > My guess is OpenGL ES support would be useful for people using > Raspberry PI, > > > beagle bone,Odroid,UDOO,etc. but perhaps to smart phone game > developers, > > > but I shoould do my homework on this instead of making > asssumptions. > > > > Crowd funding might be useful. It would definitely be a good > indicator > > of whether enough people are interested in this to pay for its > > implementation. I suspect, however, that this feature is not broadly > > applicable enough to attract the kind of money that would pay for my > > labor to implement it. The problem, as above, is that implementing > > OpenGL ES support in VGL would only allow a very narrow class of > OpenGL > > ES applications-- those that use X11 to do their drawing-- to be > > supported. Most mobile applications aren't going to fall into that > > category. > > > > > > > > > > > Thanks again, > > > George > > > > > > > > > > > > On Sun, Apr 6, 2014 at 7:55 AM, DRC < > dco...@us... > > <mailto:dco...@us...> > > > <mailto:dco...@us... > > <mailto:dco...@us...>>> wrote: > > > > > > > > > > > > On Apr 5, 2014, at 1:14 PM, George Profenza <or...@gm...<mailto: > or...@gm...> > > > <mailto:or...@gm... <mailto:or...@gm...>>> wrote: > > > > > >> Hi, > > >> > > >> I'm new to this so want to make sure I understood what you > just > > >> explained :) > > >> > > >> Currently, "out of the box", just compiled, as-is I won't be > able > > >> to use VirtualGL to serve an OpenGL ES window to TurboVNC, > correct ? > > > > > > Correct > > > > > >> "LD_PRELOAD exists in the underlying O/S and applications are > > >> dynamically linked with the OpenGL ES library" and - is there > a > > >> quick way to test this ? > > >> I'm hoping the application got linked with OpenGL ES. > > > > > > ldd {application binary} > > > > > > will tell you whether the app is dynamically linked with > OpenGL ES. > > > Testing LD_PRELOAD is more of an advanced topic. > > > > > > > > >> Regarding intercepting and modifying EGL calls, that would be > > >> something I would need to modify in the VirtualGL sources ? > > >> If so, any hints on how I could get started ? > > > > > > Yeah, spend 8 years dealing with various OpenGL, > high-performance > > > computing, and video streaming problems, then another 10 doing > > > nothing but developing remote 3D software, and the problem > will seem > > > straightforward. :) Otherwise, it would be difficult for me to > > > bring you up to speed on the types of issues you are likely to > > > encounter. > > > > > > This is why (and how) I make my living doing contract > development > > > and consulting around this stuff. I don't earn a salary, so I > rely > > > on financial sponsorship to keep this project afloat, and that > > > usually takes the form of organizations paying me to add > features. I > > > do things that way for two reasons: (1) it allows the project > to > > > respond to the needs of various different (and sometimes > competing) > > > organizations rather than being co-opted for one specific > > > organization's agenda, and (2) the expectation that new > features > > > will usually require financial sponsorship means that there > will be > > > a well-defined need for any new feature that goes in (thus > > > preventing VGL from becoming a "science fair" project.) > > > > > > I created VirtualGL from scratch more than 10 years ago. I've > been > > > the sole maintainer of the project and have developed probably > 99% > > > of its code. I am not trying to sound arrogant, but it's just > not > > > possible for me to teach you or anyone else what I know, > because I > > > myself was not taught it. I discovered how to do it on my own > > > through years of experimentation and research. Even if I > brought > > > someone else up to speed on this code, it would take them > twice as > > > long to develop a feature as it would take me, and the result > would > > > not be as good, so I'd end up having to spend my free time > cleaning > > > up the contributed patches. I am willing to do that if the > feature > > > is something that I feel will be broadly applicable. I don't > get > > > that sense here, though. Without understanding more about why > you're > > > trying to bring up VGL in this environment, I'm getting a very > > > strong "science fair" vibe here. > > > > > > > > >> Thank you, > > >> George > > >> > > >> > > >> On Sat, Apr 5, 2014 at 2:20 PM, DRC > > >> <dco...@us... > > <mailto:dco...@us...> > > >> <mailto:dco...@us... > > <mailto:dco...@us...>>> wrote: > > >> > > >> Not currently. I don't know of any technical reason why it > > >> couldn't, assuming that LD_PRELOAD exists in the > underlying > > >> O/S and applications are dynamically linked with the > OpenGL ES > > >> library. Conceptually, it would just require intercepting > and > > >> modifying the EGL calls in much the same way that we > currently > > >> modify the GLX calls. Straightforward but would probably > > >> require a lot of testing in order to get right. > > >> > > >> > On Apr 5, 2014, at 4:01 AM, George Profenza < > or...@gm... <mailto:or...@gm...> > > <mailto:or...@gm... <mailto:or...@gm...>>> wrote: > > >> > > > >> > Hello, > > >> > > > >> > I'm new to VirtualGL and I was wondering if I could use > it on a Raspberry PI. > > >> > (arm v6 cpu with a broadcom gpu) > > >> > > > >> > I've compiled libjpeg-turbo and VirtualGL from source > and ran vglserver_config > > >> > but I can't seem to get an OpenGL ES window showing up > in TurboVNC. > > >> > Is it possible to use OpenGL ES on VirtualGL ? If so, > how ? > > >> > > > >> > Thank you for your time, > > >> > George > > >> > > ------------------------------------------------------------------------------ > > >> > _______________________________________________ > > >> > VirtualGL-Users mailing list > > >> >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...> > > >> <mailto:Vir...@li... > > <mailto:Vir...@li...>> > > >>https://lists.sourceforge.net/lists/listinfo/virtualgl-users > > >> > > >> > > >> > ------------------------------------------------------------------------------ > > >> _______________________________________________ > > >> 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...> > > > <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 > > > > > > > > > > > ------------------------------------------------------------------------------ > > Put Bad Developers to Shame > > Dominate Development with Jenkins Continuous Integration > > Continuously Automate Build, Test & Deployment > > Start a new project now. Try Jenkins in the cloud. > > http://p.sf.net/sfu/13600_Cloudbees > > > > > > > > _______________________________________________ > > VirtualGL-Users mailing list > > Vir...@li... > > https://lists.sourceforge.net/lists/listinfo/virtualgl-users > > > > > ------------------------------------------------------------------------------ > Put Bad Developers to Shame > Dominate Development with Jenkins Continuous Integration > Continuously Automate Build, Test & Deployment > Start a new project now. Try Jenkins in the cloud. > http://p.sf.net/sfu/13600_Cloudbees > _______________________________________________ > VirtualGL-Users mailing list > Vir...@li... > https://lists.sourceforge.net/lists/listinfo/virtualgl-users > |
|
From: DRC <dco...@us...> - 2014-04-13 14:59:55
|
From VirtualGL's point of view, there are two issues with the X server that is running on your Raspberry Pi: -- It needs a GLX extension. You can see from the output of xdpyinfo that it currently lacks one. -- It appears to be currently running with a depth of 16. It needs to be running with a depth of 24. Those settings are generally changed in xorg.conf, but more important than the presence of a GLX extension is the presence of a GPU for it to leverage. I am not familiar with what GPU is in Raspberry Pi and how to configure the X server to take advantage of it. What I can tell you is that, before you're going to be able to successfully use VGL, the output of xdpyinfo will need to show the presence of a GLX extension on display :0 with "depth of the root window" = 24 or 32, and the output of '/opt/VirtualGL/bin/glxinfo -display :0 -c' will need to indicate the presence of Pbuffer support (refer to the VirtualGL User's Guide) as well as the presence of accelerated 3D drivers (i.e. the GLX vendor strings and the OpenGL renderer string should not have the word "software" or "Mesa" in them.) On 4/13/14 7:57 AM, George Profenza wrote: > Thank you again for the detailed answer. > > Unfortunately, since I am not very experienced I am hoping you can still > help with a few (hopefully) simple questions. > You mentioned I should " get a "3D X server" up and running just like > you would when using > VirtualGL with a "regular" PC. " > I'm not 100% what you meant. Had a quick look at what x11 packages are > available and I can easily install these: > x11-apps x11proto-kb-dev x11proto-xf86dri-dev > x11-common x11proto-print-dev x11proto-xf86misc-dev > x11proto-bigreqs-dev x11proto-randr-dev x11proto-xf86vidmode-dev > x11proto-composite-dev x11proto-record-dev x11proto-xinerama-dev > x11proto-core-dev x11proto-render-dev x11-session-utils > x11proto-damage-dev x11proto-resource-dev x11-utils > x11proto-dmx-dev x11proto-scrnsaver-dev x11vnc > x11proto-dri2-dev x11proto-video-dev x11vnc-data > x11proto-fixes-dev x11proto-xcmisc-dev x11-xfs-utils > x11proto-fonts-dev x11proto-xext-dev x11-xkb-utils > x11proto-gl-dev x11proto-xf86bigfont-dev x11-xserver-utils > x11proto-input-dev x11proto-xf86dga-dev > > I've installed the gl-dev, dri2-dev,dmx-dev packages and also > mesa-common-dev and mesa-utils > Also tried using some of the info tools but it doesn't look great: > " > pi@picam2 ~ $ glxinfo > name of display: :0.0 > Error: couldn't find RGB GLX visual or fbconfig > > pi@picam2 ~ $ glxgears > Error: couldn't get an RGB, Double-buffered visual > pi@picam2 ~ $ glxdemo > Error: couldn't get an RGB, Double-buffered visual > pi@picam2 ~ $ glxheads > glxheads: exercise multiple GLX connections (any key = exit) > Usage: > glxheads xdisplayname ... > Example: > glxheads :0 mars:0 venus:1 > Error on display :0.0 - Unable to find RGB, double-buffered visual > pi@picam2 ~ $ glxheads :0 > Error on display :0 - Unable to find RGB, double-buffered visual > pi@picam2 ~ $ glxheads :0.0 > Error on display :0.0 - Unable to find RGB, double-buffered visual > pi@picam2 ~ $ > " > > I've going through the manual and got a bit stuck at "VGL Transport with > X11 Forwarding". > I've previously "granted access to the 3D server" > using /etc/init.d/lightdm stop, running vglserver_config (with options > n,n,n), restarted the display manager > and got this output from xdpyinfo: > " > pi@picam2 /opt/VirtualGL/bin $ xdpyinfo -display :0 > name of display: :0 > version number: 11.0 > vendor string: The X.Org Foundation > vendor release number: 11204000 > X.Org version: 1.12.4 > maximum request size: 16777212 bytes > motion buffer size: 256 > bitmap unit, bit order, padding: 32, LSBFirst, 32 > image byte order: LSBFirst > number of supported pixmap formats: 7 > supported pixmap formats: > depth 1, bits_per_pixel 1, scanline_pad 32 > depth 4, bits_per_pixel 8, scanline_pad 32 > depth 8, bits_per_pixel 8, scanline_pad 32 > depth 15, bits_per_pixel 16, scanline_pad 32 > depth 16, bits_per_pixel 16, scanline_pad 32 > depth 24, bits_per_pixel 32, scanline_pad 32 > depth 32, bits_per_pixel 32, scanline_pad 32 > keycode range: minimum 8, maximum 255 > focus: window 0x2000005, revert to Parent > number of extensions: 25 > BIG-REQUESTS > Composite > DAMAGE > DOUBLE-BUFFER > DPMS > DRI2 > Generic Event Extension > MIT-SCREEN-SAVER > MIT-SHM > RANDR > RECORD > RENDER > SECURITY > SHAPE > SYNC > X-Resource > XC-MISC > XFIXES > XFree86-DGA > XFree86-VidModeExtension > XINERAMA > XInputExtension > XKEYBOARD > XTEST > XVideo > default screen number: 0 > number of screens: 1 > > screen #0: > dimensions: 656x512 pixels (174x135 millimeters) > resolution: 96x96 dots per inch > depths (7): 16, 1, 4, 8, 15, 24, 32 > root window id: 0x43 > depth of root window: 16 planes > number of colormaps: minimum 1, maximum 1 > default colormap: 0x20 > default number of colormap cells: 64 > preallocated pixels: black 0, white 65535 > options: backing-store NO, save-unders NO > largest cursor: 656x512 > current input event mask: 0x7a003c > ButtonPressMask ButtonReleaseMask EnterWindowMask > LeaveWindowMask StructureNotifyMask > SubstructureNotifyMask > SubstructureRedirectMask FocusChangeMask PropertyChangeMask > number of visuals: 2 > default visual id: 0x21 > visual: > visual id: 0x21 > class: TrueColor > depth: 16 planes > available colormap entries: 64 per subfield > red, green, blue masks: 0xf800, 0x7e0, 0x1f > significant bits in color specification: 8 bits > visual: > visual id: 0x41 > class: TrueColor > depth: 32 planes > available colormap entries: 256 per subfield > red, green, blue masks: 0xff0000, 0xff00, 0xff > significant bits in color specification: 8 bits > " > Then I tried to connect and run glxspheres > " > pi@picam2 /opt/VirtualGL/bin $ ./vglconnect pi...@pi... > > VirtualGL Client 32-bit v2.3.3 (Build 20140413) > vglclient is already running on this X display and accepting unencrypted > connections on port 4242. > > pi...@pi...'s password: > Linux picam2 3.10.36+ #665 PREEMPT Wed Apr 9 15:01:53 BST 2014 armv6l > > The programs included with the Debian GNU/Linux system are free software; > the exact distribution terms for each program are described in the > individual files in /usr/share/doc/*/copyright. > > Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent > permitted by applicable law. > Last login: Sun Apr 13 13:38:32 2014 from 192.168.0.14 > pi@picam2 /opt/VirtualGL/bin $ ./vglrun ./glxspheres > [VGL] NOTICE: Automatically setting VGL_CLIENT environment variable to > [VGL] 192.168.0.14, the IP address of your SSh client. > Polygons in scene: 62464 > ERROR (603): Could not obtain RGB visual with requested properties > pi@picam2 /opt/VirtualGL/bin $ ./vglconnect -x pi...@pi... > > VirtualGL Client 32-bit v2.3.3 (Build 20140413) > vglclient is already running on this X display and accepting unencrypted > connections on port 4242. > > mktemp: failed to create file via template `vglconnect.XXXXXX': > Permission denied > ^C > pi@picam2 /opt/VirtualGL/bin $ sudo ./vglconnect -x pi...@pi... > > VirtualGL Client 32-bit v2.3.3 (Build 20140413) > X11 connection rejected because of wrong authentication. > start-- 534: Could not open display > [VGL] ERROR: vglclient failed to execute. > > " > > Also, if it helps, here's the full ldd info on glxspheres: > " > pi@picam2 /opt/VirtualGL/bin $ ldd glxspheres > /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so (0xb6f30000) > libGL.so.1 => /usr/lib/arm-linux-gnueabihf/libGL.so.1 (0xb6ebb000) > libX11.so.6 => /usr/lib/arm-linux-gnueabihf/libX11.so.6 (0xb6da7000) > libGLU.so.1 => /usr/lib/arm-linux-gnueabihf/libGLU.so.1 (0xb6d4b000) > libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0xb6cda000) > libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6bab000) > libglapi.so.0 => /usr/lib/arm-linux-gnueabihf/libglapi.so.0 (0xb6b84000) > libXext.so.6 => /usr/lib/arm-linux-gnueabihf/libXext.so.6 (0xb6b6e000) > libXdamage.so.1 => /usr/lib/arm-linux-gnueabihf/libXdamage.so.1 (0xb6b64000) > libXfixes.so.3 => /usr/lib/arm-linux-gnueabihf/libXfixes.so.3 (0xb6b57000) > libX11-xcb.so.1 => /usr/lib/arm-linux-gnueabihf/libX11-xcb.so.1 (0xb6b4d000) > libxcb-glx.so.0 => /usr/lib/arm-linux-gnueabihf/libxcb-glx.so.0 (0xb6b34000) > libxcb.so.1 => /usr/lib/arm-linux-gnueabihf/libxcb.so.1 (0xb6b15000) > libXxf86vm.so.1 => /usr/lib/arm-linux-gnueabihf/libXxf86vm.so.1 (0xb6b08000) > libdrm.so.2 => /usr/lib/arm-linux-gnueabihf/libdrm.so.2 (0xb6af6000) > libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0xb6ad6000) > libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0xb6acb000) > libstdc++.so.6 => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 (0xb69fe000) > libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0xb69d6000) > /lib/ld-linux-armhf.so.3 (0xb6f3e000) > libXau.so.6 => /usr/lib/arm-linux-gnueabihf/libXau.so.6 (0xb69cc000) > libXdmcp.so.6 => /usr/lib/arm-linux-gnueabihf/libXdmcp.so.6 (0xb69bf000) > librt.so.1 => /lib/arm-linux-gnueabihf/librt.so.1 (0xb69b0000) > " > > At this point I am bit lost. Your suggestion of trying "to test > VirtualGL as-is and verify that it works on that platform." sounds good. > Can you please advise how I can continue with that ? > > Thank you again for all your support, > George > > > On Sun, Apr 6, 2014 at 5:38 PM, DRC <dco...@us... > <mailto:dco...@us...>> wrote: > > On 4/6/14 5:06 AM, George Profenza wrote: > > Thank you very much for the detailed explanations and your patience. > > > > Using ldd on vglserver_config yelds:"not a dynamic executable" > > For the gl apps I see all the linked libraries and > > "libGL.so.1 => /usr/lib/arm-linux-gnueabihf/libGL.so.1 (0xb6f21000) > > libGLU.so.1 => /usr/lib/arm-linux-gnueabihf/libGLU.so.1 (0xb6ec5000) > > libX11.so.6 => /usr/lib/arm-linux-gnueabihf/libX11.so.6 (0xb6db1000)l > > " > > I can't run the demos though (E.g. glxspheres), I get this output: > > " > > Polygons in scene: 62464 > > ERROR (603): Could not obtain RGB visual with requested properties > > " > > > > So I guess the GL code in the sources need to be ported to GLES > > and it sure doesn't look simple to me :) > > I really don't know anything about Raspberry Pi, but if it has libX11, > then apparently it does support a regular X server. Also, if you're > getting that error message, then apparently it supports GLX as well > (otherwise, GLXspheres wouldn't even run.) I suspect that EGL may be > implemented as a wrapper to GLX, which means that you're going to have > to get a "3D X server" up and running just like you would when using > VirtualGL with a "regular" PC. This would at least allow you to test > VirtualGL as-is and verify that it works on that platform. > > There is a remote chance that EGL is implemented as a GLX wrapper and > that the implementation is done in such a way that EGL applications > could be made to work with VirtualGL as-is. Basically, this would be > the case if the EGL API was in a separate library that made GLX calls > into libGL. I suspect, however, that that's not how it works. It's > more likely that the EGL calls are exposed in libGL itself, in which > case VirtualGL would have to specifically interpose those calls. And > GLXspheres and the other "toy" applications in the VGL source would need > to be ported to EGL. > > The other aspect of this is the windowing system. VirtualGL's basic job > is to split OpenGL and X11 rendering. VirtualGL redirects the OpenGL > rendering to a "local" X server (the "3D X server") that is attached to > a GPU. It then reads back the rendered 3D pixels at the appropriate > time and uses 2D drawing commands to composite those pixels back into > the appropriate X window, which is displayed to a remote X server or X > proxy (the "2D X server".) Meanwhile, the other X11 drawing commands > from the application go directly to the 2D X server. > > Thus, it goes without saying that, if an OpenGL ES application is not > using X windows as a means of drawing its GUI, then VirtualGL will not > be applicable. This doesn't mean that the application has to directly > call X windows. It could be using a toolkit, such as GTK or Qt, that > calls X windows "behind the scenes", but ultimately, there has to be > some underlying communication between the application and libX11 in > order for VirtualGL to work-- as well as VNC, since VNC is a virtual X > server. > > > > > I'm guessing by "science fair" you mean too localized > > Yes. The funding aspect is a sort of filter. If someone wants a > feature badly enough to pay for it, then the feature usually tends to be > broadly applicable. It's quite often the case that one organization > will pay me to implement a feature, and another organization will start > using the feature and pay me for follow-up work down the road. It is > extremely rare that an organization will pay for a feature that is only > narrowly applicable. > > VirtualGL does have a "general fund" that pays for 200 hours/year of my > labor, but I have to be judicious with that, since it has to cover any > time I spend doing releases and answering e-mails on the mailing lists > and doing code cleanup, etc. I have, on occasion, used that fund to pay > for new feature implementations, but it really has to be something that > is very compelling and something that I feel will move the project > forward. > > > > The project looks very useful. It must be pretty hard code for you being > > the only maintainer. > > I'm wondering if crowd funding would work to help with the financial > > support needed. > > My guess is OpenGL ES support would be useful for people using Raspberry PI, > > beagle bone,Odroid,UDOO,etc. but perhaps to smart phone game developers, > > but I shoould do my homework on this instead of making asssumptions. > > Crowd funding might be useful. It would definitely be a good indicator > of whether enough people are interested in this to pay for its > implementation. I suspect, however, that this feature is not broadly > applicable enough to attract the kind of money that would pay for my > labor to implement it. The problem, as above, is that implementing > OpenGL ES support in VGL would only allow a very narrow class of OpenGL > ES applications-- those that use X11 to do their drawing-- to be > supported. Most mobile applications aren't going to fall into that > category. > > > > > > Thanks again, > > George > > > > > > > > On Sun, Apr 6, 2014 at 7:55 AM, DRC <dco...@us... > <mailto:dco...@us...> > > <mailto:dco...@us... > <mailto:dco...@us...>>> wrote: > > > > > > > > On Apr 5, 2014, at 1:14 PM, George Profenza <or...@gm... <mailto:or...@gm...> > > <mailto:or...@gm... <mailto:or...@gm...>>> wrote: > > > >> Hi, > >> > >> I'm new to this so want to make sure I understood what you just > >> explained :) > >> > >> Currently, "out of the box", just compiled, as-is I won't be able > >> to use VirtualGL to serve an OpenGL ES window to TurboVNC, correct ? > > > > Correct > > > >> "LD_PRELOAD exists in the underlying O/S and applications are > >> dynamically linked with the OpenGL ES library" and - is there a > >> quick way to test this ? > >> I'm hoping the application got linked with OpenGL ES. > > > > ldd {application binary} > > > > will tell you whether the app is dynamically linked with OpenGL ES. > > Testing LD_PRELOAD is more of an advanced topic. > > > > > >> Regarding intercepting and modifying EGL calls, that would be > >> something I would need to modify in the VirtualGL sources ? > >> If so, any hints on how I could get started ? > > > > Yeah, spend 8 years dealing with various OpenGL, high-performance > > computing, and video streaming problems, then another 10 doing > > nothing but developing remote 3D software, and the problem will seem > > straightforward. :) Otherwise, it would be difficult for me to > > bring you up to speed on the types of issues you are likely to > > encounter. > > > > This is why (and how) I make my living doing contract development > > and consulting around this stuff. I don't earn a salary, so I rely > > on financial sponsorship to keep this project afloat, and that > > usually takes the form of organizations paying me to add features. I > > do things that way for two reasons: (1) it allows the project to > > respond to the needs of various different (and sometimes competing) > > organizations rather than being co-opted for one specific > > organization's agenda, and (2) the expectation that new features > > will usually require financial sponsorship means that there will be > > a well-defined need for any new feature that goes in (thus > > preventing VGL from becoming a "science fair" project.) > > > > I created VirtualGL from scratch more than 10 years ago. I've been > > the sole maintainer of the project and have developed probably 99% > > of its code. I am not trying to sound arrogant, but it's just not > > possible for me to teach you or anyone else what I know, because I > > myself was not taught it. I discovered how to do it on my own > > through years of experimentation and research. Even if I brought > > someone else up to speed on this code, it would take them twice as > > long to develop a feature as it would take me, and the result would > > not be as good, so I'd end up having to spend my free time cleaning > > up the contributed patches. I am willing to do that if the feature > > is something that I feel will be broadly applicable. I don't get > > that sense here, though. Without understanding more about why you're > > trying to bring up VGL in this environment, I'm getting a very > > strong "science fair" vibe here. > > > > > >> Thank you, > >> George > >> > >> > >> On Sat, Apr 5, 2014 at 2:20 PM, DRC > >> <dco...@us... > <mailto:dco...@us...> > >> <mailto:dco...@us... > <mailto:dco...@us...>>> wrote: > >> > >> Not currently. I don't know of any technical reason why it > >> couldn't, assuming that LD_PRELOAD exists in the underlying > >> O/S and applications are dynamically linked with the OpenGL ES > >> library. Conceptually, it would just require intercepting and > >> modifying the EGL calls in much the same way that we currently > >> modify the GLX calls. Straightforward but would probably > >> require a lot of testing in order to get right. > >> > >> > On Apr 5, 2014, at 4:01 AM, George Profenza <or...@gm... <mailto:or...@gm...> > <mailto:or...@gm... <mailto:or...@gm...>>> wrote: > >> > > >> > Hello, > >> > > >> > I'm new to VirtualGL and I was wondering if I could use it on a Raspberry PI. > >> > (arm v6 cpu with a broadcom gpu) > >> > > >> > I've compiled libjpeg-turbo and VirtualGL from source and ran vglserver_config > >> > but I can't seem to get an OpenGL ES window showing up in TurboVNC. > >> > Is it possible to use OpenGL ES on VirtualGL ? If so, how ? > >> > > >> > Thank you for your time, > >> > George > >> > ------------------------------------------------------------------------------ > >> > _______________________________________________ > >> > VirtualGL-Users mailing list > >> >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...> > >> <mailto:Vir...@li... > <mailto:Vir...@li...>> > >>https://lists.sourceforge.net/lists/listinfo/virtualgl-users > >> > >> > >> ------------------------------------------------------------------------------ > >> _______________________________________________ > >> 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...> > > <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 > > > > > ------------------------------------------------------------------------------ > Put Bad Developers to Shame > Dominate Development with Jenkins Continuous Integration > Continuously Automate Build, Test & Deployment > Start a new project now. Try Jenkins in the cloud. > http://p.sf.net/sfu/13600_Cloudbees > > > > _______________________________________________ > VirtualGL-Users mailing list > Vir...@li... > https://lists.sourceforge.net/lists/listinfo/virtualgl-users > |
|
From: George P. <or...@gm...> - 2014-04-13 12:58:01
|
Thank you again for the detailed answer. Unfortunately, since I am not very experienced I am hoping you can still help with a few (hopefully) simple questions. You mentioned I should " get a "3D X server" up and running just like you would when using VirtualGL with a "regular" PC. " I'm not 100% what you meant. Had a quick look at what x11 packages are available and I can easily install these: x11-apps x11proto-kb-dev x11proto-xf86dri-dev x11-common x11proto-print-dev x11proto-xf86misc-dev x11proto-bigreqs-dev x11proto-randr-dev x11proto-xf86vidmode-dev x11proto-composite-dev x11proto-record-dev x11proto-xinerama-dev x11proto-core-dev x11proto-render-dev x11-session-utils x11proto-damage-dev x11proto-resource-dev x11-utils x11proto-dmx-dev x11proto-scrnsaver-dev x11vnc x11proto-dri2-dev x11proto-video-dev x11vnc-data x11proto-fixes-dev x11proto-xcmisc-dev x11-xfs-utils x11proto-fonts-dev x11proto-xext-dev x11-xkb-utils x11proto-gl-dev x11proto-xf86bigfont-dev x11-xserver-utils x11proto-input-dev x11proto-xf86dga-dev I've installed the gl-dev, dri2-dev,dmx-dev packages and also mesa-common-dev and mesa-utils Also tried using some of the info tools but it doesn't look great: " pi@picam2 ~ $ glxinfo name of display: :0.0 Error: couldn't find RGB GLX visual or fbconfig pi@picam2 ~ $ glxgears Error: couldn't get an RGB, Double-buffered visual pi@picam2 ~ $ glxdemo Error: couldn't get an RGB, Double-buffered visual pi@picam2 ~ $ glxheads glxheads: exercise multiple GLX connections (any key = exit) Usage: glxheads xdisplayname ... Example: glxheads :0 mars:0 venus:1 Error on display :0.0 - Unable to find RGB, double-buffered visual pi@picam2 ~ $ glxheads :0 Error on display :0 - Unable to find RGB, double-buffered visual pi@picam2 ~ $ glxheads :0.0 Error on display :0.0 - Unable to find RGB, double-buffered visual pi@picam2 ~ $ " I've going through the manual and got a bit stuck at "VGL Transport with X11 Forwarding". I've previously "granted access to the 3D server" using /etc/init.d/lightdm stop, running vglserver_config (with options n,n,n), restarted the display manager and got this output from xdpyinfo: " pi@picam2 /opt/VirtualGL/bin $ xdpyinfo -display :0 name of display: :0 version number: 11.0 vendor string: The X.Org Foundation vendor release number: 11204000 X.Org version: 1.12.4 maximum request size: 16777212 bytes motion buffer size: 256 bitmap unit, bit order, padding: 32, LSBFirst, 32 image byte order: LSBFirst number of supported pixmap formats: 7 supported pixmap formats: depth 1, bits_per_pixel 1, scanline_pad 32 depth 4, bits_per_pixel 8, scanline_pad 32 depth 8, bits_per_pixel 8, scanline_pad 32 depth 15, bits_per_pixel 16, scanline_pad 32 depth 16, bits_per_pixel 16, scanline_pad 32 depth 24, bits_per_pixel 32, scanline_pad 32 depth 32, bits_per_pixel 32, scanline_pad 32 keycode range: minimum 8, maximum 255 focus: window 0x2000005, revert to Parent number of extensions: 25 BIG-REQUESTS Composite DAMAGE DOUBLE-BUFFER DPMS DRI2 Generic Event Extension MIT-SCREEN-SAVER MIT-SHM RANDR RECORD RENDER SECURITY SHAPE SYNC X-Resource XC-MISC XFIXES XFree86-DGA XFree86-VidModeExtension XINERAMA XInputExtension XKEYBOARD XTEST XVideo default screen number: 0 number of screens: 1 screen #0: dimensions: 656x512 pixels (174x135 millimeters) resolution: 96x96 dots per inch depths (7): 16, 1, 4, 8, 15, 24, 32 root window id: 0x43 depth of root window: 16 planes number of colormaps: minimum 1, maximum 1 default colormap: 0x20 default number of colormap cells: 64 preallocated pixels: black 0, white 65535 options: backing-store NO, save-unders NO largest cursor: 656x512 current input event mask: 0x7a003c ButtonPressMask ButtonReleaseMask EnterWindowMask LeaveWindowMask StructureNotifyMask SubstructureNotifyMask SubstructureRedirectMask FocusChangeMask PropertyChangeMask number of visuals: 2 default visual id: 0x21 visual: visual id: 0x21 class: TrueColor depth: 16 planes available colormap entries: 64 per subfield red, green, blue masks: 0xf800, 0x7e0, 0x1f significant bits in color specification: 8 bits visual: visual id: 0x41 class: TrueColor depth: 32 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits " Then I tried to connect and run glxspheres " pi@picam2 /opt/VirtualGL/bin $ ./vglconnect pi...@pi... VirtualGL Client 32-bit v2.3.3 (Build 20140413) vglclient is already running on this X display and accepting unencrypted connections on port 4242. pi...@pi...'s password: Linux picam2 3.10.36+ #665 PREEMPT Wed Apr 9 15:01:53 BST 2014 armv6l The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Last login: Sun Apr 13 13:38:32 2014 from 192.168.0.14 pi@picam2 /opt/VirtualGL/bin $ ./vglrun ./glxspheres [VGL] NOTICE: Automatically setting VGL_CLIENT environment variable to [VGL] 192.168.0.14, the IP address of your SSh client. Polygons in scene: 62464 ERROR (603): Could not obtain RGB visual with requested properties pi@picam2 /opt/VirtualGL/bin $ ./vglconnect -x pi...@pi... VirtualGL Client 32-bit v2.3.3 (Build 20140413) vglclient is already running on this X display and accepting unencrypted connections on port 4242. mktemp: failed to create file via template `vglconnect.XXXXXX': Permission denied ^C pi@picam2 /opt/VirtualGL/bin $ sudo ./vglconnect -x pi...@pi... VirtualGL Client 32-bit v2.3.3 (Build 20140413) X11 connection rejected because of wrong authentication. start-- 534: Could not open display [VGL] ERROR: vglclient failed to execute. " Also, if it helps, here's the full ldd info on glxspheres: " pi@picam2 /opt/VirtualGL/bin $ ldd glxspheres /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so (0xb6f30000) libGL.so.1 => /usr/lib/arm-linux-gnueabihf/libGL.so.1 (0xb6ebb000) libX11.so.6 => /usr/lib/arm-linux-gnueabihf/libX11.so.6 (0xb6da7000) libGLU.so.1 => /usr/lib/arm-linux-gnueabihf/libGLU.so.1 (0xb6d4b000) libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0xb6cda000) libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6bab000) libglapi.so.0 => /usr/lib/arm-linux-gnueabihf/libglapi.so.0 (0xb6b84000) libXext.so.6 => /usr/lib/arm-linux-gnueabihf/libXext.so.6 (0xb6b6e000) libXdamage.so.1 => /usr/lib/arm-linux-gnueabihf/libXdamage.so.1 (0xb6b64000) libXfixes.so.3 => /usr/lib/arm-linux-gnueabihf/libXfixes.so.3 (0xb6b57000) libX11-xcb.so.1 => /usr/lib/arm-linux-gnueabihf/libX11-xcb.so.1 (0xb6b4d000) libxcb-glx.so.0 => /usr/lib/arm-linux-gnueabihf/libxcb-glx.so.0 (0xb6b34000) libxcb.so.1 => /usr/lib/arm-linux-gnueabihf/libxcb.so.1 (0xb6b15000) libXxf86vm.so.1 => /usr/lib/arm-linux-gnueabihf/libXxf86vm.so.1 (0xb6b08000) libdrm.so.2 => /usr/lib/arm-linux-gnueabihf/libdrm.so.2 (0xb6af6000) libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0xb6ad6000) libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0xb6acb000) libstdc++.so.6 => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 (0xb69fe000) libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0xb69d6000) /lib/ld-linux-armhf.so.3 (0xb6f3e000) libXau.so.6 => /usr/lib/arm-linux-gnueabihf/libXau.so.6 (0xb69cc000) libXdmcp.so.6 => /usr/lib/arm-linux-gnueabihf/libXdmcp.so.6 (0xb69bf000) librt.so.1 => /lib/arm-linux-gnueabihf/librt.so.1 (0xb69b0000) " At this point I am bit lost. Your suggestion of trying " to test VirtualGL as-is and verify that it works on that platform." sounds good. Can you please advise how I can continue with that ? Thank you again for all your support, George On Sun, Apr 6, 2014 at 5:38 PM, DRC <dco...@us...>wrote: > On 4/6/14 5:06 AM, George Profenza wrote: > > Thank you very much for the detailed explanations and your patience. > > > > Using ldd on vglserver_config yelds:"not a dynamic executable" > > For the gl apps I see all the linked libraries and > > "libGL.so.1 => /usr/lib/arm-linux-gnueabihf/libGL.so.1 (0xb6f21000) > > libGLU.so.1 => /usr/lib/arm-linux-gnueabihf/libGLU.so.1 (0xb6ec5000) > > libX11.so.6 => /usr/lib/arm-linux-gnueabihf/libX11.so.6 (0xb6db1000)l > > " > > I can't run the demos though (E.g. glxspheres), I get this output: > > " > > Polygons in scene: 62464 > > ERROR (603): Could not obtain RGB visual with requested properties > > " > > > > So I guess the GL code in the sources need to be ported to GLES > > and it sure doesn't look simple to me :) > > I really don't know anything about Raspberry Pi, but if it has libX11, > then apparently it does support a regular X server. Also, if you're > getting that error message, then apparently it supports GLX as well > (otherwise, GLXspheres wouldn't even run.) I suspect that EGL may be > implemented as a wrapper to GLX, which means that you're going to have > to get a "3D X server" up and running just like you would when using > VirtualGL with a "regular" PC. This would at least allow you to test > VirtualGL as-is and verify that it works on that platform. > > There is a remote chance that EGL is implemented as a GLX wrapper and > that the implementation is done in such a way that EGL applications > could be made to work with VirtualGL as-is. Basically, this would be > the case if the EGL API was in a separate library that made GLX calls > into libGL. I suspect, however, that that's not how it works. It's > more likely that the EGL calls are exposed in libGL itself, in which > case VirtualGL would have to specifically interpose those calls. And > GLXspheres and the other "toy" applications in the VGL source would need > to be ported to EGL. > > The other aspect of this is the windowing system. VirtualGL's basic job > is to split OpenGL and X11 rendering. VirtualGL redirects the OpenGL > rendering to a "local" X server (the "3D X server") that is attached to > a GPU. It then reads back the rendered 3D pixels at the appropriate > time and uses 2D drawing commands to composite those pixels back into > the appropriate X window, which is displayed to a remote X server or X > proxy (the "2D X server".) Meanwhile, the other X11 drawing commands > from the application go directly to the 2D X server. > > Thus, it goes without saying that, if an OpenGL ES application is not > using X windows as a means of drawing its GUI, then VirtualGL will not > be applicable. This doesn't mean that the application has to directly > call X windows. It could be using a toolkit, such as GTK or Qt, that > calls X windows "behind the scenes", but ultimately, there has to be > some underlying communication between the application and libX11 in > order for VirtualGL to work-- as well as VNC, since VNC is a virtual X > server. > > > > > I'm guessing by "science fair" you mean too localized > > Yes. The funding aspect is a sort of filter. If someone wants a > feature badly enough to pay for it, then the feature usually tends to be > broadly applicable. It's quite often the case that one organization > will pay me to implement a feature, and another organization will start > using the feature and pay me for follow-up work down the road. It is > extremely rare that an organization will pay for a feature that is only > narrowly applicable. > > VirtualGL does have a "general fund" that pays for 200 hours/year of my > labor, but I have to be judicious with that, since it has to cover any > time I spend doing releases and answering e-mails on the mailing lists > and doing code cleanup, etc. I have, on occasion, used that fund to pay > for new feature implementations, but it really has to be something that > is very compelling and something that I feel will move the project forward. > > > > The project looks very useful. It must be pretty hard code for you being > > the only maintainer. > > I'm wondering if crowd funding would work to help with the financial > > support needed. > > My guess is OpenGL ES support would be useful for people using Raspberry > PI, > > beagle bone,Odroid,UDOO,etc. but perhaps to smart phone game developers, > > but I shoould do my homework on this instead of making asssumptions. > > Crowd funding might be useful. It would definitely be a good indicator > of whether enough people are interested in this to pay for its > implementation. I suspect, however, that this feature is not broadly > applicable enough to attract the kind of money that would pay for my > labor to implement it. The problem, as above, is that implementing > OpenGL ES support in VGL would only allow a very narrow class of OpenGL > ES applications-- those that use X11 to do their drawing-- to be > supported. Most mobile applications aren't going to fall into that > category. > > > > > > Thanks again, > > George > > > > > > > > On Sun, Apr 6, 2014 at 7:55 AM, DRC <dco...@us... > > <mailto:dco...@us...>> wrote: > > > > > > > > On Apr 5, 2014, at 1:14 PM, George Profenza <or...@gm... > > <mailto:or...@gm...>> wrote: > > > >> Hi, > >> > >> I'm new to this so want to make sure I understood what you just > >> explained :) > >> > >> Currently, "out of the box", just compiled, as-is I won't be able > >> to use VirtualGL to serve an OpenGL ES window to TurboVNC, correct ? > > > > Correct > > > >> "LD_PRELOAD exists in the underlying O/S and applications are > >> dynamically linked with the OpenGL ES library" and - is there a > >> quick way to test this ? > >> I'm hoping the application got linked with OpenGL ES. > > > > ldd {application binary} > > > > will tell you whether the app is dynamically linked with OpenGL ES. > > Testing LD_PRELOAD is more of an advanced topic. > > > > > >> Regarding intercepting and modifying EGL calls, that would be > >> something I would need to modify in the VirtualGL sources ? > >> If so, any hints on how I could get started ? > > > > Yeah, spend 8 years dealing with various OpenGL, high-performance > > computing, and video streaming problems, then another 10 doing > > nothing but developing remote 3D software, and the problem will seem > > straightforward. :) Otherwise, it would be difficult for me to > > bring you up to speed on the types of issues you are likely to > > encounter. > > > > This is why (and how) I make my living doing contract development > > and consulting around this stuff. I don't earn a salary, so I rely > > on financial sponsorship to keep this project afloat, and that > > usually takes the form of organizations paying me to add features. I > > do things that way for two reasons: (1) it allows the project to > > respond to the needs of various different (and sometimes competing) > > organizations rather than being co-opted for one specific > > organization's agenda, and (2) the expectation that new features > > will usually require financial sponsorship means that there will be > > a well-defined need for any new feature that goes in (thus > > preventing VGL from becoming a "science fair" project.) > > > > I created VirtualGL from scratch more than 10 years ago. I've been > > the sole maintainer of the project and have developed probably 99% > > of its code. I am not trying to sound arrogant, but it's just not > > possible for me to teach you or anyone else what I know, because I > > myself was not taught it. I discovered how to do it on my own > > through years of experimentation and research. Even if I brought > > someone else up to speed on this code, it would take them twice as > > long to develop a feature as it would take me, and the result would > > not be as good, so I'd end up having to spend my free time cleaning > > up the contributed patches. I am willing to do that if the feature > > is something that I feel will be broadly applicable. I don't get > > that sense here, though. Without understanding more about why you're > > trying to bring up VGL in this environment, I'm getting a very > > strong "science fair" vibe here. > > > > > >> Thank you, > >> George > >> > >> > >> On Sat, Apr 5, 2014 at 2:20 PM, DRC > >> <dco...@us... > >> <mailto:dco...@us...>> wrote: > >> > >> Not currently. I don't know of any technical reason why it > >> couldn't, assuming that LD_PRELOAD exists in the underlying > >> O/S and applications are dynamically linked with the OpenGL ES > >> library. Conceptually, it would just require intercepting and > >> modifying the EGL calls in much the same way that we currently > >> modify the GLX calls. Straightforward but would probably > >> require a lot of testing in order to get right. > >> > >> > On Apr 5, 2014, at 4:01 AM, George Profenza < > or...@gm... <mailto:or...@gm...>> wrote: > >> > > >> > Hello, > >> > > >> > I'm new to VirtualGL and I was wondering if I could use it on > a Raspberry PI. > >> > (arm v6 cpu with a broadcom gpu) > >> > > >> > I've compiled libjpeg-turbo and VirtualGL from source and ran > vglserver_config > >> > but I can't seem to get an OpenGL ES window showing up in > TurboVNC. > >> > Is it possible to use OpenGL ES on VirtualGL ? If so, how ? > >> > > >> > Thank you for your time, > >> > George > >> > > ------------------------------------------------------------------------------ > >> > _______________________________________________ > >> > VirtualGL-Users mailing list > >> >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... > > <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 > |
|
From: DRC <dco...@us...> - 2014-04-06 16:39:09
|
On 4/6/14 5:06 AM, George Profenza wrote:
> Thank you very much for the detailed explanations and your patience.
>
> Using ldd on vglserver_config yelds:"not a dynamic executable"
> For the gl apps I see all the linked libraries and
> "libGL.so.1 => /usr/lib/arm-linux-gnueabihf/libGL.so.1 (0xb6f21000)
> libGLU.so.1 => /usr/lib/arm-linux-gnueabihf/libGLU.so.1 (0xb6ec5000)
> libX11.so.6 => /usr/lib/arm-linux-gnueabihf/libX11.so.6 (0xb6db1000)l
> "
> I can't run the demos though (E.g. glxspheres), I get this output:
> "
> Polygons in scene: 62464
> ERROR (603): Could not obtain RGB visual with requested properties
> "
>
> So I guess the GL code in the sources need to be ported to GLES
> and it sure doesn't look simple to me :)
I really don't know anything about Raspberry Pi, but if it has libX11,
then apparently it does support a regular X server. Also, if you're
getting that error message, then apparently it supports GLX as well
(otherwise, GLXspheres wouldn't even run.) I suspect that EGL may be
implemented as a wrapper to GLX, which means that you're going to have
to get a "3D X server" up and running just like you would when using
VirtualGL with a "regular" PC. This would at least allow you to test
VirtualGL as-is and verify that it works on that platform.
There is a remote chance that EGL is implemented as a GLX wrapper and
that the implementation is done in such a way that EGL applications
could be made to work with VirtualGL as-is. Basically, this would be
the case if the EGL API was in a separate library that made GLX calls
into libGL. I suspect, however, that that's not how it works. It's
more likely that the EGL calls are exposed in libGL itself, in which
case VirtualGL would have to specifically interpose those calls. And
GLXspheres and the other "toy" applications in the VGL source would need
to be ported to EGL.
The other aspect of this is the windowing system. VirtualGL's basic job
is to split OpenGL and X11 rendering. VirtualGL redirects the OpenGL
rendering to a "local" X server (the "3D X server") that is attached to
a GPU. It then reads back the rendered 3D pixels at the appropriate
time and uses 2D drawing commands to composite those pixels back into
the appropriate X window, which is displayed to a remote X server or X
proxy (the "2D X server".) Meanwhile, the other X11 drawing commands
from the application go directly to the 2D X server.
Thus, it goes without saying that, if an OpenGL ES application is not
using X windows as a means of drawing its GUI, then VirtualGL will not
be applicable. This doesn't mean that the application has to directly
call X windows. It could be using a toolkit, such as GTK or Qt, that
calls X windows "behind the scenes", but ultimately, there has to be
some underlying communication between the application and libX11 in
order for VirtualGL to work-- as well as VNC, since VNC is a virtual X
server.
> I'm guessing by "science fair" you mean too localized
Yes. The funding aspect is a sort of filter. If someone wants a
feature badly enough to pay for it, then the feature usually tends to be
broadly applicable. It's quite often the case that one organization
will pay me to implement a feature, and another organization will start
using the feature and pay me for follow-up work down the road. It is
extremely rare that an organization will pay for a feature that is only
narrowly applicable.
VirtualGL does have a "general fund" that pays for 200 hours/year of my
labor, but I have to be judicious with that, since it has to cover any
time I spend doing releases and answering e-mails on the mailing lists
and doing code cleanup, etc. I have, on occasion, used that fund to pay
for new feature implementations, but it really has to be something that
is very compelling and something that I feel will move the project forward.
> The project looks very useful. It must be pretty hard code for you being
> the only maintainer.
> I'm wondering if crowd funding would work to help with the financial
> support needed.
> My guess is OpenGL ES support would be useful for people using Raspberry PI,
> beagle bone,Odroid,UDOO,etc. but perhaps to smart phone game developers,
> but I shoould do my homework on this instead of making asssumptions.
Crowd funding might be useful. It would definitely be a good indicator
of whether enough people are interested in this to pay for its
implementation. I suspect, however, that this feature is not broadly
applicable enough to attract the kind of money that would pay for my
labor to implement it. The problem, as above, is that implementing
OpenGL ES support in VGL would only allow a very narrow class of OpenGL
ES applications-- those that use X11 to do their drawing-- to be
supported. Most mobile applications aren't going to fall into that
category.
> Thanks again,
> George
>
>
>
> On Sun, Apr 6, 2014 at 7:55 AM, DRC <dco...@us...
> <mailto:dco...@us...>> wrote:
>
>
>
> On Apr 5, 2014, at 1:14 PM, George Profenza <or...@gm...
> <mailto:or...@gm...>> wrote:
>
>> Hi,
>>
>> I'm new to this so want to make sure I understood what you just
>> explained :)
>>
>> Currently, "out of the box", just compiled, as-is I won't be able
>> to use VirtualGL to serve an OpenGL ES window to TurboVNC, correct ?
>
> Correct
>
>> "LD_PRELOAD exists in the underlying O/S and applications are
>> dynamically linked with the OpenGL ES library" and - is there a
>> quick way to test this ?
>> I'm hoping the application got linked with OpenGL ES.
>
> ldd {application binary}
>
> will tell you whether the app is dynamically linked with OpenGL ES.
> Testing LD_PRELOAD is more of an advanced topic.
>
>
>> Regarding intercepting and modifying EGL calls, that would be
>> something I would need to modify in the VirtualGL sources ?
>> If so, any hints on how I could get started ?
>
> Yeah, spend 8 years dealing with various OpenGL, high-performance
> computing, and video streaming problems, then another 10 doing
> nothing but developing remote 3D software, and the problem will seem
> straightforward. :) Otherwise, it would be difficult for me to
> bring you up to speed on the types of issues you are likely to
> encounter.
>
> This is why (and how) I make my living doing contract development
> and consulting around this stuff. I don't earn a salary, so I rely
> on financial sponsorship to keep this project afloat, and that
> usually takes the form of organizations paying me to add features. I
> do things that way for two reasons: (1) it allows the project to
> respond to the needs of various different (and sometimes competing)
> organizations rather than being co-opted for one specific
> organization's agenda, and (2) the expectation that new features
> will usually require financial sponsorship means that there will be
> a well-defined need for any new feature that goes in (thus
> preventing VGL from becoming a "science fair" project.)
>
> I created VirtualGL from scratch more than 10 years ago. I've been
> the sole maintainer of the project and have developed probably 99%
> of its code. I am not trying to sound arrogant, but it's just not
> possible for me to teach you or anyone else what I know, because I
> myself was not taught it. I discovered how to do it on my own
> through years of experimentation and research. Even if I brought
> someone else up to speed on this code, it would take them twice as
> long to develop a feature as it would take me, and the result would
> not be as good, so I'd end up having to spend my free time cleaning
> up the contributed patches. I am willing to do that if the feature
> is something that I feel will be broadly applicable. I don't get
> that sense here, though. Without understanding more about why you're
> trying to bring up VGL in this environment, I'm getting a very
> strong "science fair" vibe here.
>
>
>> Thank you,
>> George
>>
>>
>> On Sat, Apr 5, 2014 at 2:20 PM, DRC
>> <dco...@us...
>> <mailto:dco...@us...>> wrote:
>>
>> Not currently. I don't know of any technical reason why it
>> couldn't, assuming that LD_PRELOAD exists in the underlying
>> O/S and applications are dynamically linked with the OpenGL ES
>> library. Conceptually, it would just require intercepting and
>> modifying the EGL calls in much the same way that we currently
>> modify the GLX calls. Straightforward but would probably
>> require a lot of testing in order to get right.
>>
>> > On Apr 5, 2014, at 4:01 AM, George Profenza <or...@gm... <mailto:or...@gm...>> wrote:
>> >
>> > Hello,
>> >
>> > I'm new to VirtualGL and I was wondering if I could use it on a Raspberry PI.
>> > (arm v6 cpu with a broadcom gpu)
>> >
>> > I've compiled libjpeg-turbo and VirtualGL from source and ran vglserver_config
>> > but I can't seem to get an OpenGL ES window showing up in TurboVNC.
>> > Is it possible to use OpenGL ES on VirtualGL ? If so, how ?
>> >
>> > Thank you for your time,
>> > George
>> > ------------------------------------------------------------------------------
>> > _______________________________________________
>> > VirtualGL-Users mailing list
>> >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...
> <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
>
|
|
From: George P. <or...@gm...> - 2014-04-06 10:06:56
|
Thank you very much for the detailed explanations and your patience. Using ldd on vglserver_config yelds:"not a dynamic executable" For the gl apps I see all the linked libraries and "libGL.so.1 => /usr/lib/arm-linux-gnueabihf/libGL.so.1 (0xb6f21000) libGLU.so.1 => /usr/lib/arm-linux-gnueabihf/libGLU.so.1 (0xb6ec5000) libX11.so.6 => /usr/lib/arm-linux-gnueabihf/libX11.so.6 (0xb6db1000) l " I can't run the demos though (E.g. glxspheres), I get this output: " Polygons in scene: 62464 ERROR (603): Could not obtain RGB visual with requested properties " So I guess the GL code in the sources need to be ported to GLES and it sure doesn't look simple to me :) I'm guessing by "science fair" you mean too localized, if so, that would be my case. I'm using playing with http://openframeworks.cc (an easy to use collection of c++ libraries) which has an GLES renderer, so to see the output, I need to hook up a display with the Raspberry PI. I was wondering if I the gl graphics can somehow be streamed to a vnc client and that's how I found VirtualGL. The project looks very useful. It must be pretty hard code for you being the only maintainer. I'm wondering if crowd funding would work to help with the financial support needed. My guess is OpenGL ES support would be useful for people using Raspberry PI, beagle bone,Odroid,UDOO,etc. but perhaps to smart phone game developers, but I shoould do my homework on this instead of making asssumptions. Thanks again, George On Sun, Apr 6, 2014 at 7:55 AM, DRC <dco...@us...>wrote: > > > On Apr 5, 2014, at 1:14 PM, George Profenza <or...@gm...> wrote: > > Hi, > > I'm new to this so want to make sure I understood what you just explained > :) > > Currently, "out of the box", just compiled, as-is I won't be able to use > VirtualGL to serve an OpenGL ES window to TurboVNC, correct ? > > > Correct > > "LD_PRELOAD exists in the underlying O/S and applications are dynamically > linked with the OpenGL ES library" and - is there a quick way to test > this ? > I'm hoping the application got linked with OpenGL ES. > > > ldd {application binary} > > will tell you whether the app is dynamically linked with OpenGL ES. > Testing LD_PRELOAD is more of an advanced topic. > > > Regarding intercepting and modifying EGL calls, that would be something I > would need to modify in the VirtualGL sources ? > If so, any hints on how I could get started ? > > > Yeah, spend 8 years dealing with various OpenGL, high-performance > computing, and video streaming problems, then another 10 doing nothing but > developing remote 3D software, and the problem will seem straightforward. > :) Otherwise, it would be difficult for me to bring you up to speed on the > types of issues you are likely to encounter. > > This is why (and how) I make my living doing contract development and > consulting around this stuff. I don't earn a salary, so I rely on financial > sponsorship to keep this project afloat, and that usually takes the form of > organizations paying me to add features. I do things that way for two > reasons: (1) it allows the project to respond to the needs of various > different (and sometimes competing) organizations rather than being > co-opted for one specific organization's agenda, and (2) the expectation > that new features will usually require financial sponsorship means that > there will be a well-defined need for any new feature that goes in (thus > preventing VGL from becoming a "science fair" project.) > > I created VirtualGL from scratch more than 10 years ago. I've been the > sole maintainer of the project and have developed probably 99% of its code. > I am not trying to sound arrogant, but it's just not possible for me to > teach you or anyone else what I know, because I myself was not taught it. I > discovered how to do it on my own through years of experimentation and > research. Even if I brought someone else up to speed on this code, it would > take them twice as long to develop a feature as it would take me, and the > result would not be as good, so I'd end up having to spend my free time > cleaning up the contributed patches. I am willing to do that if the feature > is something that I feel will be broadly applicable. I don't get that sense > here, though. Without understanding more about why you're trying to bring > up VGL in this environment, I'm getting a very strong "science fair" vibe > here. > > > Thank you, > George > > > On Sat, Apr 5, 2014 at 2:20 PM, DRC <dco...@us...>wrote: > >> Not currently. I don't know of any technical reason why it couldn't, >> assuming that LD_PRELOAD exists in the underlying O/S and applications are >> dynamically linked with the OpenGL ES library. Conceptually, it would just >> require intercepting and modifying the EGL calls in much the same way that >> we currently modify the GLX calls. Straightforward but would probably >> require a lot of testing in order to get right. >> >> > On Apr 5, 2014, at 4:01 AM, George Profenza <or...@gm...> wrote: >> > >> > Hello, >> > >> > I'm new to VirtualGL and I was wondering if I could use it on a >> Raspberry PI. >> > (arm v6 cpu with a broadcom gpu) >> > >> > I've compiled libjpeg-turbo and VirtualGL from source and ran >> vglserver_config >> > but I can't seem to get an OpenGL ES window showing up in TurboVNC. >> > Is it possible to use OpenGL ES on VirtualGL ? If so, how ? >> > >> > Thank you for your time, >> > George >> > >> ------------------------------------------------------------------------------ >> > _______________________________________________ >> > VirtualGL-Users mailing list >> > 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 > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > VirtualGL-Users mailing list > Vir...@li... > https://lists.sourceforge.net/lists/listinfo/virtualgl-users > > |
|
From: DRC <dco...@us...> - 2014-04-06 06:55:21
|
> On Apr 5, 2014, at 1:14 PM, George Profenza <or...@gm...> wrote:
>
> Hi,
>
> I'm new to this so want to make sure I understood what you just explained :)
>
> Currently, "out of the box", just compiled, as-is I won't be able to use VirtualGL to serve an OpenGL ES window to TurboVNC, correct ?
Correct
> "LD_PRELOAD exists in the underlying O/S and applications are dynamically linked with the OpenGL ES library" and - is there a quick way to test this ?
> I'm hoping the application got linked with OpenGL ES.
ldd {application binary}
will tell you whether the app is dynamically linked with OpenGL ES. Testing LD_PRELOAD is more of an advanced topic.
> Regarding intercepting and modifying EGL calls, that would be something I would need to modify in the VirtualGL sources ?
> If so, any hints on how I could get started ?
Yeah, spend 8 years dealing with various OpenGL, high-performance computing, and video streaming problems, then another 10 doing nothing but developing remote 3D software, and the problem will seem straightforward. :) Otherwise, it would be difficult for me to bring you up to speed on the types of issues you are likely to encounter.
This is why (and how) I make my living doing contract development and consulting around this stuff. I don't earn a salary, so I rely on financial sponsorship to keep this project afloat, and that usually takes the form of organizations paying me to add features. I do things that way for two reasons: (1) it allows the project to respond to the needs of various different (and sometimes competing) organizations rather than being co-opted for one specific organization's agenda, and (2) the expectation that new features will usually require financial sponsorship means that there will be a well-defined need for any new feature that goes in (thus preventing VGL from becoming a "science fair" project.)
I created VirtualGL from scratch more than 10 years ago. I've been the sole maintainer of the project and have developed probably 99% of its code. I am not trying to sound arrogant, but it's just not possible for me to teach you or anyone else what I know, because I myself was not taught it. I discovered how to do it on my own through years of experimentation and research. Even if I brought someone else up to speed on this code, it would take them twice as long to develop a feature as it would take me, and the result would not be as good, so I'd end up having to spend my free time cleaning up the contributed patches. I am willing to do that if the feature is something that I feel will be broadly applicable. I don't get that sense here, though. Without understanding more about why you're trying to bring up VGL in this environment, I'm getting a very strong "science fair" vibe here.
> Thank you,
> George
>
>
>> On Sat, Apr 5, 2014 at 2:20 PM, DRC <dco...@us...> wrote:
>> Not currently. I don't know of any technical reason why it couldn't, assuming that LD_PRELOAD exists in the underlying O/S and applications are dynamically linked with the OpenGL ES library. Conceptually, it would just require intercepting and modifying the EGL calls in much the same way that we currently modify the GLX calls. Straightforward but would probably require a lot of testing in order to get right.
>>
>> > On Apr 5, 2014, at 4:01 AM, George Profenza <or...@gm...> wrote:
>> >
>> > Hello,
>> >
>> > I'm new to VirtualGL and I was wondering if I could use it on a Raspberry PI.
>> > (arm v6 cpu with a broadcom gpu)
>> >
>> > I've compiled libjpeg-turbo and VirtualGL from source and ran vglserver_config
>> > but I can't seem to get an OpenGL ES window showing up in TurboVNC.
>> > Is it possible to use OpenGL ES on VirtualGL ? If so, how ?
>> >
>> > Thank you for your time,
>> > George
>> > ------------------------------------------------------------------------------
>> > _______________________________________________
>> > VirtualGL-Users mailing list
>> > 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
|
|
From: George P. <or...@gm...> - 2014-04-05 18:14:30
|
Hi, I'm new to this so want to make sure I understood what you just explained :) Currently, "out of the box", just compiled, as-is I won't be able to use VirtualGL to serve an OpenGL ES window to TurboVNC, correct ? "LD_PRELOAD exists in the underlying O/S and applications are dynamically linked with the OpenGL ES library" and - is there a quick way to test this ? I'm hoping the application got linked with OpenGL ES. Regarding intercepting and modifying EGL calls, that would be something I would need to modify in the VirtualGL sources ? If so, any hints on how I could get started ? Thank you, George On Sat, Apr 5, 2014 at 2:20 PM, DRC <dco...@us...>wrote: > Not currently. I don't know of any technical reason why it couldn't, > assuming that LD_PRELOAD exists in the underlying O/S and applications are > dynamically linked with the OpenGL ES library. Conceptually, it would just > require intercepting and modifying the EGL calls in much the same way that > we currently modify the GLX calls. Straightforward but would probably > require a lot of testing in order to get right. > > > On Apr 5, 2014, at 4:01 AM, George Profenza <or...@gm...> wrote: > > > > Hello, > > > > I'm new to VirtualGL and I was wondering if I could use it on a > Raspberry PI. > > (arm v6 cpu with a broadcom gpu) > > > > I've compiled libjpeg-turbo and VirtualGL from source and ran > vglserver_config > > but I can't seem to get an OpenGL ES window showing up in TurboVNC. > > Is it possible to use OpenGL ES on VirtualGL ? If so, how ? > > > > Thank you for your time, > > George > > > ------------------------------------------------------------------------------ > > _______________________________________________ > > VirtualGL-Users mailing list > > Vir...@li... > > https://lists.sourceforge.net/lists/listinfo/virtualgl-users > > > ------------------------------------------------------------------------------ > _______________________________________________ > VirtualGL-Users mailing list > Vir...@li... > https://lists.sourceforge.net/lists/listinfo/virtualgl-users > |
|
From: DRC <dco...@us...> - 2014-04-05 13:20:30
|
Not currently. I don't know of any technical reason why it couldn't, assuming that LD_PRELOAD exists in the underlying O/S and applications are dynamically linked with the OpenGL ES library. Conceptually, it would just require intercepting and modifying the EGL calls in much the same way that we currently modify the GLX calls. Straightforward but would probably require a lot of testing in order to get right. > On Apr 5, 2014, at 4:01 AM, George Profenza <or...@gm...> wrote: > > Hello, > > I'm new to VirtualGL and I was wondering if I could use it on a Raspberry PI. > (arm v6 cpu with a broadcom gpu) > > I've compiled libjpeg-turbo and VirtualGL from source and ran vglserver_config > but I can't seem to get an OpenGL ES window showing up in TurboVNC. > Is it possible to use OpenGL ES on VirtualGL ? If so, how ? > > Thank you for your time, > George > ------------------------------------------------------------------------------ > _______________________________________________ > VirtualGL-Users mailing list > Vir...@li... > https://lists.sourceforge.net/lists/listinfo/virtualgl-users |
|
From: George P. <or...@gm...> - 2014-04-05 09:02:06
|
Hello, I'm new to VirtualGL and I was wondering if I could use it on a Raspberry PI. (arm v6 cpu with a broadcom gpu) I've compiled libjpeg-turbo and VirtualGL from source and ran vglserver_config but I can't seem to get an OpenGL ES window showing up in TurboVNC. Is it possible to use OpenGL ES on VirtualGL ? If so, how ? Thank you for your time, George |
|
From: Patrik P. <pa...@fl...> - 2014-03-28 07:07:29
|
I can confirm that the new prerelease build works for us too. 2014-03-27 19:23, DRC skrev: > A new pre-release build with the infinite drawing loop fix is now available: > > http://www.virtualgl.org/DeveloperInfo/PreReleases > > So at least it should now work as well as 2.3 worked. I will keep you > posted with the progress of the flashing issue. That one is in Altair's > court right now. > > > On 3/26/14 11:30 AM, Patrik Pira wrote: >> No problems, thank you for your support. >> >> 2014-03-26 06:06, DRC skrev: >>> Sorry for the delay on this. Both issues have been reproduced, and I'm >>> investigating. >>> >>> >>> On 3/3/14 1:25 AM, Patrik Pira wrote: >>>> Yes, flickering does occur with VGL 2.3. It does go away when I switch >>>> to software opengl. >>>> >>>> >>>> 2014-02-28 18:39, DRC skrev: >>>>> OK, fair enough. I'm working with Altair in parallel to try and >>>>> diagnose this, and they've confirmed that the infinite loop issue occurs >>>>> with VGL 2.3.3, but I'm trying to nail down whether the flickering issue >>>>> is also VirtualGL's fault. Can you confirm whether the flickering >>>>> occurs with VGL 2.3 and if it goes away when you switch to software OpenGL? >>>>> >>>>> Altair is sending me a demo license for HM so I can diagnose this on my >>>>> end. I suspect that it's entirely a VGL issue, so the use of ThinLinc >>>>> vs. TurboVNC probably doesn't matter. >>>>> >>>>> >>>>> On 2/28/14 4:09 AM, Patrik Pira wrote: >>>>>> Oh you mean turbovnc viewer. I read hypermesh viewer... >>>>>> >>>>>> We are not using turbovnc. We use Cendio's thinlinc (version 4.0). Their >>>>>> tigervnc Xvnc support softare glx so if I run hypermesh without vglrun >>>>>> it works okay albeit slower. >>>>>> >>>>>> 2014-02-28 09:41, DRC skrev: >>>>>>> You mean the native Windows viewer? Which version? And also, which >>>>>>> version of the TurboVNC server are you using? >>>>>>> >>>>>>> >>>>>>> On 2/28/14 1:12 AM, Patrik Pira wrote: >>>>>>>> I wasn't aware of that there is a java viewer also. I use the native one >>>>>>>> when the problem appears. >>>>>>>> >>>>>>>> I start it with: >>>>>>>> >>>>>>>> $ vglrun hm >>>>>>>> >>>>>>>> In the end, the file "hmopengl" is executed which is native 64-bit code. >>>>>>>> >>>>>>>> To reproduce deadlock, create a 1-dimensional, standard section, HYPER >>>>>>>> BEAM, thinwalled box. After pressing "create", process will deadlock >>>>>>>> during painting of next HyperBeam window. >>>>>>>> >>>>>>>> Hypermesh 12.0 will produce some initial flickering when painting the >>>>>>>> Hyperbeam window. Hypermesh 11.0 has no visual anomalies as far as I can >>>>>>>> see. >>>>>>>> >>>>>>>> 2014-02-27 19:59, DRC skrev: >>>>>>>>> Altair is looking into it. Are the visual anomalies specific to a >>>>>>>>> particular viewer? Do you, for instance, see them with both the Java >>>>>>>>> and the native viewer on a particular platform? >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2/27/14 1:17 AM, Patrik Pira wrote: >>>>>>>>>> I also tried hypermesh 11.0 and it also deadlocks with VirtualGL 2.3.3. >>>>>>>>>> Works fine when downgrading to VirtualGL 2.3. >>>>>>>>>> >>>>>>>>>> 2014-02-26 20:24, Patrik Pira skrev: >>>>>>>>>>> Hypermesh 12.0, which seems to be the latest version released according >>>>>>>>>>> to their website. >>>>>>>>>>> >>>>>>>>>>> We use NVIDIA cards, I believe these servers have a Quadro 4000 or >>>>>>>>>>> similar card. Driver version 310 or 320 something on RHEL6 x86_64. I am >>>>>>>>>>> not at work right now so I can't check the exact version. >>>>>>>>>>> >>>>>>>>>>> As it works (mostly) okay with VirtualGL 2.3 but not with VirtualGL >>>>>>>>>>> 2.3.3 (nor with 2.3.2) it looks to me like a regression in recent >>>>>>>>>>> versions of VirtualGL. >>>>>>>>>>> >>>>>>>>>>> 2014-02-26 20:10, DRC skrev: >>>>>>>>>>>> What version of HyperMesh? Altair actively sells VirtualGL and TurboVNC >>>>>>>>>>>> as part of their grid service offering, so I know that it has been >>>>>>>>>>>> tested. The only possibility is that a new version came out that broke >>>>>>>>>>>> something, or perhaps there is something different about your environment. >>>>>>>>>>>> >>>>>>>>>>>> What graphics adapter and driver version are you running? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 2/26/14 3:47 AM, Patrik Pira wrote: >>>>>>>>>>>>> Hello >>>>>>>>>>>>> >>>>>>>>>>>>> I'm having problems running Altair hypermesh with the latest version of >>>>>>>>>>>>> VirtualGL (2.3.3). Application sort of deadlocks when creating a >>>>>>>>>>>>> hyperbeam section and rapidly just redraws the opengl drawing area >>>>>>>>>>>>> without responding to input. Only way out is to kill the process. >>>>>>>>>>>>> >>>>>>>>>>>>> After some maillist archive reading I figured out that this issue was >>>>>>>>>>>>> fixed with the changelog entry below. >>>>>>>>>>>>> >>>>>>>>>>>>> =============================================================================== >>>>>>>>>>>>> 2.3 beta1 >>>>>>>>>>>>> =============================================================================== >>>>>>>>>>>>> [1] >>>>>>>>>>>>> Re-fixed issue that caused MainWin-based applications to hang. This was >>>>>>>>>>>>> initially fixed in VGL 2.1 final, but it was re-broken by the rewrite of the >>>>>>>>>>>>> global faker configuration routines in VGL 2.2. >>>>>>>>>>>>> ------------------------------------------------------------------------------- >>>>>>>>>>>>> >>>>>>>>>>>>> So I installed VirtualGL 2.3 and suddenly it worked. It's not very >>>>>>>>>>>>> pretty with some spurious flickering in the opengl drawing area, but it >>>>>>>>>>>>> works. >>>>>>>>>>>>> >>>>>>>>>>>>> I also tried all the other application reciepe workarounds with >>>>>>>>>>>>> virtualgl 2.3.3 but they had no impact. >>>>>>>>>>>>> >>>>>>>>>>>>> Regards >>>>>>>>>>>>> Patrik Pira >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Flow-based real-time traffic analytics software. Cisco certified tool. >>>>> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer >>>>> Customize your own dashboards, set traffic alerts and generate reports. >>>>> Network behavioral analysis & security monitoring. All-in-one tool. >>>>> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk >>>>> _______________________________________________ >>>>> VirtualGL-Users mailing list >>>>> Vir...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/virtualgl-users >>>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. >>>> With Perforce, you get hassle-free workflows. Merge that actually works. >>>> Faster operations. Version large binaries. Built-in WAN optimization and the >>>> freedom to use Git, Perforce or both. Make the move to Perforce. >>>> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk >>>> _______________________________________________ >>>> VirtualGL-Users mailing list >>>> Vir...@li... >>>> https://lists.sourceforge.net/lists/listinfo/virtualgl-users >>>> >>> >>> ------------------------------------------------------------------------------ >>> Learn Graph Databases - Download FREE O'Reilly Book >>> "Graph Databases" is the definitive new guide to graph databases and their >>> applications. Written by three acclaimed leaders in the field, >>> this first edition is now available. Download your free book today! >>> http://p.sf.net/sfu/13534_NeoTech >>> _______________________________________________ >>> VirtualGL-Users mailing list >>> Vir...@li... >>> https://lists.sourceforge.net/lists/listinfo/virtualgl-users >>> >> >> >> ------------------------------------------------------------------------------ >> Learn Graph Databases - Download FREE O'Reilly Book >> "Graph Databases" is the definitive new guide to graph databases and their >> applications. Written by three acclaimed leaders in the field, >> this first edition is now available. Download your free book today! >> http://p.sf.net/sfu/13534_NeoTech >> _______________________________________________ >> 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 > |
|
From: DRC <dco...@us...> - 2014-03-28 06:00:51
|
In my testing, I also discovered (and was not at all surprised by the fact) that TurboVNC doesn't work with the version of Gnome shipped with F20. Even the "classic" mode seems to require the X Composite extension. I'm not sure what RHEL 7 is doing in that department, but this might jump up and bite us in the butt sooner rather than later. Minimally, I'm going to need to implement the Composite extension in TVNC and maybe some other stuff like XKEYBOARD to keep things running smoothly with the Red Hat family. If anyone is interested in sponsoring that, please let me know. Using Xfce remains a viable workaround. |
|
From: DRC <dco...@us...> - 2014-03-28 05:39:01
|
Should be fixed in the latest pre-release build. Confirmed to be an issue with Fedora 19 and 20 and the official VirtualGL 2.3.2 and 2.3.3 RPMs (as well as any pre-releases of 2.3.4 up until now.) Of course, Fedora also ships their own package for VirtualGL now, so it's less of an issue if our RPM doesn't work on that platform, but I still want it to work. There are certain things you can't do with theirs, such as running setuid apps. On 3/26/14 9:23 AM, Kevin Van Workum wrote: > My mistake, we have several distributions that we test new packages on > and I got confused. The rpm didn't install on my FC-20 test machine. > Installs fine on RHEL-6.4, RHEL-6.5, CentOS-6.4, CentOS-6.5. The > specific error is: > > file /usr/lib64 from install of VirtualGL-2.3.4-20140326.x86_64 > conflicts with file from package filesystem-3.2-19.fc20.x86_64 > > I'm guessing it's an issue with the rpm version on FC-20, > rpm-4.11.2-2.fc20.x86_64. In the other distros, /usr/lib64 is also owned > by filesystem. > > I tried both downloading the nightly build from > http://virtualgl.sourceforge.net/vgl.nightly.2.3.x and building it from > source as well. To get the rpm to install on FC-20, I had to remove the > "%dir %{libdir}" line. > > Sorry for the confusion. |
|
From: DRC <dco...@us...> - 2014-03-27 18:23:53
|
A new pre-release build with the infinite drawing loop fix is now available: http://www.virtualgl.org/DeveloperInfo/PreReleases So at least it should now work as well as 2.3 worked. I will keep you posted with the progress of the flashing issue. That one is in Altair's court right now. On 3/26/14 11:30 AM, Patrik Pira wrote: > No problems, thank you for your support. > > 2014-03-26 06:06, DRC skrev: >> Sorry for the delay on this. Both issues have been reproduced, and I'm >> investigating. >> >> >> On 3/3/14 1:25 AM, Patrik Pira wrote: >>> Yes, flickering does occur with VGL 2.3. It does go away when I switch >>> to software opengl. >>> >>> >>> 2014-02-28 18:39, DRC skrev: >>>> OK, fair enough. I'm working with Altair in parallel to try and >>>> diagnose this, and they've confirmed that the infinite loop issue occurs >>>> with VGL 2.3.3, but I'm trying to nail down whether the flickering issue >>>> is also VirtualGL's fault. Can you confirm whether the flickering >>>> occurs with VGL 2.3 and if it goes away when you switch to software OpenGL? >>>> >>>> Altair is sending me a demo license for HM so I can diagnose this on my >>>> end. I suspect that it's entirely a VGL issue, so the use of ThinLinc >>>> vs. TurboVNC probably doesn't matter. >>>> >>>> >>>> On 2/28/14 4:09 AM, Patrik Pira wrote: >>>>> Oh you mean turbovnc viewer. I read hypermesh viewer... >>>>> >>>>> We are not using turbovnc. We use Cendio's thinlinc (version 4.0). Their >>>>> tigervnc Xvnc support softare glx so if I run hypermesh without vglrun >>>>> it works okay albeit slower. >>>>> >>>>> 2014-02-28 09:41, DRC skrev: >>>>>> You mean the native Windows viewer? Which version? And also, which >>>>>> version of the TurboVNC server are you using? >>>>>> >>>>>> >>>>>> On 2/28/14 1:12 AM, Patrik Pira wrote: >>>>>>> I wasn't aware of that there is a java viewer also. I use the native one >>>>>>> when the problem appears. >>>>>>> >>>>>>> I start it with: >>>>>>> >>>>>>> $ vglrun hm >>>>>>> >>>>>>> In the end, the file "hmopengl" is executed which is native 64-bit code. >>>>>>> >>>>>>> To reproduce deadlock, create a 1-dimensional, standard section, HYPER >>>>>>> BEAM, thinwalled box. After pressing "create", process will deadlock >>>>>>> during painting of next HyperBeam window. >>>>>>> >>>>>>> Hypermesh 12.0 will produce some initial flickering when painting the >>>>>>> Hyperbeam window. Hypermesh 11.0 has no visual anomalies as far as I can >>>>>>> see. >>>>>>> >>>>>>> 2014-02-27 19:59, DRC skrev: >>>>>>>> Altair is looking into it. Are the visual anomalies specific to a >>>>>>>> particular viewer? Do you, for instance, see them with both the Java >>>>>>>> and the native viewer on a particular platform? >>>>>>>> >>>>>>>> >>>>>>>> On 2/27/14 1:17 AM, Patrik Pira wrote: >>>>>>>>> I also tried hypermesh 11.0 and it also deadlocks with VirtualGL 2.3.3. >>>>>>>>> Works fine when downgrading to VirtualGL 2.3. >>>>>>>>> >>>>>>>>> 2014-02-26 20:24, Patrik Pira skrev: >>>>>>>>>> Hypermesh 12.0, which seems to be the latest version released according >>>>>>>>>> to their website. >>>>>>>>>> >>>>>>>>>> We use NVIDIA cards, I believe these servers have a Quadro 4000 or >>>>>>>>>> similar card. Driver version 310 or 320 something on RHEL6 x86_64. I am >>>>>>>>>> not at work right now so I can't check the exact version. >>>>>>>>>> >>>>>>>>>> As it works (mostly) okay with VirtualGL 2.3 but not with VirtualGL >>>>>>>>>> 2.3.3 (nor with 2.3.2) it looks to me like a regression in recent >>>>>>>>>> versions of VirtualGL. >>>>>>>>>> >>>>>>>>>> 2014-02-26 20:10, DRC skrev: >>>>>>>>>>> What version of HyperMesh? Altair actively sells VirtualGL and TurboVNC >>>>>>>>>>> as part of their grid service offering, so I know that it has been >>>>>>>>>>> tested. The only possibility is that a new version came out that broke >>>>>>>>>>> something, or perhaps there is something different about your environment. >>>>>>>>>>> >>>>>>>>>>> What graphics adapter and driver version are you running? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 2/26/14 3:47 AM, Patrik Pira wrote: >>>>>>>>>>>> Hello >>>>>>>>>>>> >>>>>>>>>>>> I'm having problems running Altair hypermesh with the latest version of >>>>>>>>>>>> VirtualGL (2.3.3). Application sort of deadlocks when creating a >>>>>>>>>>>> hyperbeam section and rapidly just redraws the opengl drawing area >>>>>>>>>>>> without responding to input. Only way out is to kill the process. >>>>>>>>>>>> >>>>>>>>>>>> After some maillist archive reading I figured out that this issue was >>>>>>>>>>>> fixed with the changelog entry below. >>>>>>>>>>>> >>>>>>>>>>>> =============================================================================== >>>>>>>>>>>> 2.3 beta1 >>>>>>>>>>>> =============================================================================== >>>>>>>>>>>> [1] >>>>>>>>>>>> Re-fixed issue that caused MainWin-based applications to hang. This was >>>>>>>>>>>> initially fixed in VGL 2.1 final, but it was re-broken by the rewrite of the >>>>>>>>>>>> global faker configuration routines in VGL 2.2. >>>>>>>>>>>> ------------------------------------------------------------------------------- >>>>>>>>>>>> >>>>>>>>>>>> So I installed VirtualGL 2.3 and suddenly it worked. It's not very >>>>>>>>>>>> pretty with some spurious flickering in the opengl drawing area, but it >>>>>>>>>>>> works. >>>>>>>>>>>> >>>>>>>>>>>> I also tried all the other application reciepe workarounds with >>>>>>>>>>>> virtualgl 2.3.3 but they had no impact. >>>>>>>>>>>> >>>>>>>>>>>> Regards >>>>>>>>>>>> Patrik Pira >>>> >>>> ------------------------------------------------------------------------------ >>>> Flow-based real-time traffic analytics software. Cisco certified tool. >>>> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer >>>> Customize your own dashboards, set traffic alerts and generate reports. >>>> Network behavioral analysis & security monitoring. All-in-one tool. >>>> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk >>>> _______________________________________________ >>>> VirtualGL-Users mailing list >>>> Vir...@li... >>>> https://lists.sourceforge.net/lists/listinfo/virtualgl-users >>>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. >>> With Perforce, you get hassle-free workflows. Merge that actually works. >>> Faster operations. Version large binaries. Built-in WAN optimization and the >>> freedom to use Git, Perforce or both. Make the move to Perforce. >>> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> VirtualGL-Users mailing list >>> Vir...@li... >>> https://lists.sourceforge.net/lists/listinfo/virtualgl-users >>> >> >> ------------------------------------------------------------------------------ >> Learn Graph Databases - Download FREE O'Reilly Book >> "Graph Databases" is the definitive new guide to graph databases and their >> applications. Written by three acclaimed leaders in the field, >> this first edition is now available. Download your free book today! >> http://p.sf.net/sfu/13534_NeoTech >> _______________________________________________ >> VirtualGL-Users mailing list >> Vir...@li... >> https://lists.sourceforge.net/lists/listinfo/virtualgl-users >> > > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/13534_NeoTech > _______________________________________________ > VirtualGL-Users mailing list > Vir...@li... > https://lists.sourceforge.net/lists/listinfo/virtualgl-users > |
13 messages has been excluded from this view by a project administrator.
