Not sure how many of you follow the VirtualGL project, but tonight on the virtualgl-users mail list they've announced that Sun has apparently pulled the plug on VirtualGL:
http://sourceforge.net/mailarchive/forum.php?thread_name=49790410.6000600%40users.sourceforge.net&forum_name=virtualgl-users Does this mean that Sun is doing away with the Shared Visualization package, or will we see a new technology employed instead? It would be sad to see such a nice tool disappear, especially since it's actually become quite useful in the most recent releases. Any of the Sun guys on the list care to comment? Well, if you're allowed to say anything about it, of course. Thanks. ---Dan On Tue, Jan 20, 2009 at 12:16 AM, Jeremy Stagg <[email protected]>wrote: > Is it the VGA connector ? Try the digital. > (Have experienced some faulty SunRay2 devices with VGA) > > > >>> On 20/01/2009 at 2:17 pm, in message < > [email protected]>, Dan Allongo > <[email protected]> wrote: > Bob, > > Here is the output of the command you asked me to run: > $ gdmflexiserver --command=VERSION > GDM 2.20.7 > > > Below is some extra info about my server, just in case any of it is > relevant: > $ cat /proc/version > Linux version 2.6.26-1-686-bigmem (Debian 2.6.26-13) ([email protected]) > (gcc version 4.1.3 20080704 (prerelease) (Debian 4.1.2-24)) #1 SMP Sat Jan > 10 19:13:22 UTC 2009 > > $ cat /proc/meminfo > MemTotal: 16625048 kB > --snip-- > > $ cat /proc/cpuinfo > processor : 0 > vendor_id : GenuineIntel > cpu family : 6 > model : 14 > model name : Intel(R) Xeon(TM) CPU @ 2.00GHz > stepping : 8 > cpu MHz : 1992.000 > cache size : 2048 KB > physical id : 0 > siblings : 2 > core id : 0 > cpu cores : 2 > apicid : 0 > initial apicid : 0 > fdiv_bug : no > hlt_bug : no > f00f_bug : no > coma_bug : no > fpu : yes > fpu_exception : yes > cpuid level : 10 > wp : yes > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca > cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx > constant_tsc arch_perfmon bts pni monitor vmx est tm2 xtpr > --snip-- > (the output is the same for processors 1-3, so 4 cores total) > > $ lspci > 00:00.0 Host bridge: Intel Corporation E7520 Memory Controller Hub (rev 0c) > 00:02.0 PCI bridge: Intel Corporation E7525/E7520/E7320 PCI Express Port A > (rev 0c) > 00:04.0 PCI bridge: Intel Corporation E7525/E7520 PCI Express Port B (rev > 0c) > 00:06.0 PCI bridge: Intel Corporation E7520 PCI Express Port C (rev 0c) > 00:07.0 PCI bridge: Intel Corporation E7520 PCI Express Port C1 (rev 0c) > 00:1c.0 PCI bridge: Intel Corporation 6300ESB 64-bit PCI-X Bridge (rev 02) > 00:1d.0 USB Controller: Intel Corporation 6300ESB USB Universal Host > Controller (rev 02) > 00:1d.1 USB Controller: Intel Corporation 6300ESB USB Universal Host > Controller (rev 02) > 00:1d.4 System peripheral: Intel Corporation 6300ESB Watchdog Timer (rev > 02) > 00:1d.5 PIC: Intel Corporation 6300ESB I/O Advanced Programmable Interrupt > Controller (rev 02) > 00:1d.7 USB Controller: Intel Corporation 6300ESB USB2 Enhanced Host > Controller (rev 02) > 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 0a) > 00:1f.0 ISA bridge: Intel Corporation 6300ESB LPC Interface Controller (rev > 02) > 00:1f.2 IDE interface: Intel Corporation 6300ESB SATA Storage Controller > (rev 02) > 00:1f.3 SMBus: Intel Corporation 6300ESB SMBus Controller (rev 02) > 03:00.0 Ethernet controller: Intel Corporation 82573E Gigabit Ethernet > Controller (Copper) (rev 03) > 04:00.0 Ethernet controller: Intel Corporation 82573L Gigabit Ethernet > Controller > 06:00.0 VGA compatible controller: nVidia Corporation GeForce 8600 GT (rev > a1) > > I'm using the NVIDIA 173.14 driver. > > > > On Mon, Jan 19, 2009 at 8:41 PM, Bob Doolittle > <[email protected]>wrote: > >> What version of GDM is in your distro? >> Try running the following command: >> gdmflexiserver --command=VERSION >> >> I have some ideas that could help with the version we support - 2.16, but >> I'm not too sure about the new rewrite. >> With the old version, you can have per-display copies of (parts of) the >> GDM config file - that might help. I'm don't know about the new version, >> however. >> >> -Bob >> >> Dan Allongo wrote: >> >>> So I've got the SunRay Image Transport working, but it doesn't give me >>> any >>> more speed, it just looks very blurry... :-( >>> It could also be due to the way I've got it set up. I followed the wiki >>> for >>> setting up SRSS 4.1 on Debian Lenny and I'm also using the sample >>> gdm.conf >>> provided there as well. This means that the Xorg server on :0 is disabled >>> so >>> that Xnewt can start new sessions (headless mode). This is the only way >>> that >>> I've managed to get past the 26D, otherwise if the Xorg server starts on >>> :0, >>> the 'ray just hangs waiting for data. The problem is that VirtualGL on >>> the >>> otherhand requires the 3D accelerated Xorg to run on :0. Right now I have >>> to >>> run 'sudo X &' after I've logged into the SunRay and just before I run >>> 'vglrun -dl -c rgb +sync quake3' otherwise VGL complains that display:0 >>> cannot be opened. >>> Does anyone have a working gdm.conf for a SunRay server that runs >>> VirtualGL? >>> I mean, I guess I could always just install the SunRay server in a VM and >>> have a regular desktop environment as the host running VirtualBox and >>> VirtualGL, but then I'd lose sound since the SunRay sessions would be >>> ssh'd >>> into the host... there's got to be a way to do this all on one box. >>> I understand that Solaris allows using GLP for headless VirtualGL so that >>> it >>> plays nice with SRSS but VGL on Linux requires a 3D accelerated X server >>> running. >>> Ideas? >>> >>> >>> On Thu, Jan 15, 2009 at 8:24 AM, William Usher <[email protected]> >>> wrote: >>> >>> >>> >>>> I think this would be an awesome demo to present to some clients. "Let's >>>> see a Wyse do _this_". Any idea about frame rates on a 2FS? >>>> >>>> >>>> On Tue, Jan 13, 2009 at 11:54 PM, Dan Allongo <[email protected]> >>>> wrote: >>>> >>>> >>>> >>>>> i finally snagged the librrsunray.so from the rhel package and put it >>>>> in >>>>> /usr/lib but i won't be able to test it until i get home on thursday >>>>> night >>>>> (i'm away on business for the week). i did try to load the sunray >>>>> driver >>>>> from my laptop through ssh, but it of course threw some error. the good >>>>> news >>>>> is that when the .so isn't in /usr/lib, vglrun throws a different error >>>>> stating that it can't find the file, so at least it's looking in the >>>>> right >>>>> place. >>>>> >>>>> after doing a little more reading on sunray 1 performance, i'm quite >>>>> surprised that i'm getting such good framrates as it is. hopefully the >>>>> accelerated yuv render path will allow me to bump the res to 512x384. >>>>> getting 640x480 even at 15 or 20 fps would be a dream come true. >>>>> >>>>> i'll post an update on friday after i've tinkered with it thursday >>>>> night. >>>>> >>>>> >>>>> >>>>> On Sun, Jan 11, 2009 at 9:29 PM, Dan Allongo <[email protected]> >>>>> wrote: >>>>> >>>>> >>>>> >>>>>> since i'm running vgl and srss on the same server, i'm using rgb mode >>>>>> (basically a raw dump of the vgl X display data) and letting the >>>>>> sunray >>>>>> Xnewt handle it. i noticed that using proxy mode gives similar >>>>>> performance >>>>>> and jpeg results in additional input lag. because i'm running linux i >>>>>> don't >>>>>> have the sunray plugin for vgl, but i may try to alien the rpms and >>>>>> see if >>>>>> it works. >>>>>> >>>>>> honestly, i think rgb is going to be the best mode to avoid having the >>>>>> image processed twice on the same server. >>>>>> >>>>>> On Sun, Jan 11, 2009 at 8:54 PM, William Yang <[email protected]> >>>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>>> Which output mode are you using? I think the highest frame rate is >>>>>>> the sr output mode, but the quality is noticeably degraded. The next >>>>>>> highest should be sryuv, with better quality but lower framerate. >>>>>>> >>>>>>> >>>>>>> >>>>>>> I don't have any FPS numbers though. >>>>>>> >>>>>>> >>>>>>> >>>>>>> William Yang >>>>>>> >>>>>>> >>>>>>> >>>>>>> *From:* [email protected] [mailto: >>>>>>> [email protected]] *On Behalf Of *Dan Allongo >>>>>>> *Sent:* Sunday, January 11, 2009 7:26 PM >>>>>>> *To:* [email protected] >>>>>>> *Subject:* [SunRay-Users] sunray 1g max fill rate? >>>>>>> >>>>>>> >>>>>>> >>>>>>> hi all! >>>>>>> >>>>>>> i'm new to this list, so allow me to explain my setup briefly before >>>>>>> i >>>>>>> begin: >>>>>>> i've got a couple sunray 1g's (manufacture date july/september 2004) >>>>>>> running with the latest patched 4.1 gui firmware on debian lenny >>>>>>> (dual xeon >>>>>>> 2ghz sossaman, 16gb pc2-3200 ecc). sunray interconnect is on eth1 >>>>>>> (intel >>>>>>> gigabit) hooked up to a 5-port dlink 10/100 switch. eth0 connects to >>>>>>> my >>>>>>> dlink wireless router. i'm running virtualgl 2.1.1 with a nvidia >>>>>>> geforce >>>>>>> 8600gt using the nvidia driver (173.xx). >>>>>>> >>>>>>> i'm trying to play quake 3 through the sunray (i know, i know!) >>>>>>> building >>>>>>> ioquake3 from the latest source on svn. i'm actually getting decent >>>>>>> framrates at 400x300, the sound and input lag is nearly non-existent >>>>>>> when >>>>>>> running vglrun with +sync specified. obviously, i'm getting worse >>>>>>> performance as i increase the resolution, but i want to make sure >>>>>>> that i'm >>>>>>> getting the max frames possible. >>>>>>> >>>>>>> here's what i'm getting: >>>>>>> 29 fps @ 400x300 >>>>>>> 16 fps @ 512x384 >>>>>>> 11 fps @ 640x480 >>>>>>> 7 fps @ 800x600 >>>>>>> 4 fps @ 1024x768 >>>>>>> >>>>>>> the decline is pretty linear pointing at a max fill rate of about >>>>>>> 3.6M >>>>>>> pixels or so. >>>>>>> >>>>>>> my question is - is this expected performance? is there anything i >>>>>>> can >>>>>>> do to get even a few more pixels out of this? let me reiterate: quake >>>>>>> 3 is >>>>>>> fully playable at 400x300, but i'm just curious about bumping the >>>>>>> resolution >>>>>>> up at least a little bit. i guess i'm just a little surprised given >>>>>>> that i'm >>>>>>> browsing the internet and reading documents on my 22" (1680x1050) >>>>>>> with >>>>>>> frequent scrolling and full screen updates, and it feels very snappy. >>>>>>> in >>>>>>> fact, the sunray is responsive enough that i sometimes forget i'm on >>>>>>> a dumb >>>>>>> terminal! >>>>>>> >>>>>>> is anyone else using vgl on their sunrays? >>>>>>> >>>>>>> thanks. >>>>>>> >>>>>>> _______________________________________________ >>>>>>> SunRay-Users mailing list >>>>>>> [email protected] >>>>>>> http://www.filibeto.org/mailman/listinfo/sunray-users >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>> SunRay-Users mailing list >>>>> [email protected] >>>>> http://www.filibeto.org/mailman/listinfo/sunray-users >>>>> >>>>> >>>>> >>>>> >>>> -- >>>> -Will >>>> >>>> _______________________________________________ >>>> SunRay-Users mailing list >>>> [email protected] >>>> http://www.filibeto.org/mailman/listinfo/sunray-users >>>> >>>> >>>> >>>> >>> >>> ------------------------------------------------------------------------ >>> >>> >>> _______________________________________________ >>> SunRay-Users mailing list >>> [email protected] >>> http://www.filibeto.org/mailman/listinfo/sunray-users >>> >>> >> >> _______________________________________________ >> SunRay-Users mailing list >> [email protected] >> http://www.filibeto.org/mailman/listinfo/sunray-users >> > > > *Network Help Pty Ltd* > *Phone:* +61-3-9459-2122 > *Facsimile: *+61-3-9459-5322 > * Website:* http://www.networkhelp.com.au > > *Disclaimer :** This message contains confidential information and is > intended only for the individual named. If you are not the named addressee > you should not disseminate, distribute or copy this e-mail. Please notify > the sender immediately by e-mail if you have received this e-mail by mistake > and delete this e-mail from your system. E-mail transmission cannot be > guaranteed to be secure or error-free as information could be intercepted, > corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. > The sender therefore does not accept liability for any errors or omissions > in the contents of this message, which arise as a result of e-mail > transmission. If verification is required please request a hard-copy > version. Contact Network Help on +61-3-9459-2122 for further details.* > > _______________________________________________ > SunRay-Users mailing list > [email protected] > http://www.filibeto.org/mailman/listinfo/sunray-users > >
_______________________________________________ SunRay-Users mailing list [email protected] http://www.filibeto.org/mailman/listinfo/sunray-users
