I think you could interact with it, although I don't remember since we primarily tested with glxgears and screensavers. I don't see any reason why it wouldn't be interactive though. It appears that although the Sun Ray plugin is stale, VirtualGL has still been developing new features that can be used with Sun Ray; for instance there is now an XVideo mode in 2.2 beta according to the docs.
William Yang > -----Original Message----- > From: [email protected] [mailto:sunray-users- > [email protected]] On Behalf Of Craig Bender > Sent: Thursday, September 02, 2010 11:19 AM > To: SunRay-Users mailing list > Subject: Re: [SunRay-Users] Server Side Graphics Processing > > Thanks William, > > Thanks for providing the missing details. Remembering some things about > the Sun Ray demo...Was there any limitation with app interaction? Your > sentence "allowed for some fairly decent speed 3D accelerated graphics > to be displayed on a Sun Ray" knocked a few cobwebs loose. Is > "displayed" a key word there? i.e. You couldn't interact with the 3D > app from a Sun Ray? Or am I thinking of something else. Some how the > requirement of SunForum (a Solaris/SPARC NetMeeting clone for the > youngsters out there) came to my mind when reading your email. > > > > On 9/2/10 8:10 AM, William Yang wrote: > > The shared visualization product from Sun was basically VirtualGL + Sun > Ray > > plugin. The VirtualGL stack is open source, but I think Sun was the > primary > > sponsor until Sun dropped it, so I don't know what the status of the > project > > is any more. With GPUs on the Sun Ray server, the old shared vis > product > > allowed for some fairly decent speed 3D accelerated graphics to be > displayed > > on a Sun Ray. > > > > William Yang > > > >> -----Original Message----- > >> From: [email protected] [mailto:sunray-users- > >> [email protected]] On Behalf Of Craig Bender > >> Sent: Thursday, September 02, 2010 10:27 AM > >> To: [email protected]; SunRay-Users mailing list > >> Subject: Re: [SunRay-Users] Server Side Graphics Processing > >> > >> Today, nothing in SRSS or VDI will use a GPU at any level in the stack > >> (Sun Ray Presentation Layer, Hypervisor, vRDP). > >> > >> Not sure what Viz product pitch you had, but there were two "solutions". > >> One was basically dedicated solution which I believe was an actual > >> product and the other was a "shared" solution concept that was in early > >> stages. > >> > >> Both were aimed at recapturing the traditional (legacy?) Sun > Workstation > >> market, and Solaris only (No Linux, no windows). Neither exist today, > >> at least as an offering from Oracle (I think parts of the shared Viz > >> were "open"). > >> > >> We are constantly looking at new ways to bring affordable, scalable > >> solutions to Sun Ray, but pricing some of the dedicated GPU solutions > >> blows me away and can't really understand why anyone would pay $3-5K to > >> replace a PC on the desk. The shared concept is more interesting. > >> > >> > >> > >> > >> > >> On 9/2/10 5:44 AM, Alex Brulo wrote: > >>> Hi guys, > >>> > >>> I am second here for pleading ignorance, so bear with me please. > >>> My question as follows: (hope someone from VDI team > >>> would put all my ignorance to rest :-) > >>> I have quiet powerful 4600 M2 with 256GB of ram > >>> and build in ATI graphic adapter serving 50 VM's (mostly Linux, but > >> there are > >>> some windows) in a single server configuration. > >>> a) Is there any point to upgrade and install > >>> top of the range supported nVidia adapter > >>> and run it in Multi-GPU FrameRendering or CLI ? > >>> b) will it affect VB/srs performance or is it all irrelevant ? > >>> I still have the presentation Sun-visualization.ppt from not so > distant > >> past. > >>> One of the slides had a sample configuration using 4600 M2 and 2 > nVidia > >> Model > >>> 4 Quadro Plexes with 6GB of total frame buffer. I was wondering if a > >> similar > >>> type of configuration could be applicable (Solaris 10 and VDI 3.2) > >>> Thanks > >>> > >>> > >>> > >>> > >>> On Thursday 02 September 2010 01:07:28 sunray-users- > [email protected] > >> wrote: > >>>> Send SunRay-Users mailing list submissions to > >>>> [email protected] > >>>> > >>>> To subscribe or unsubscribe via the World Wide Web, visit > >>>> http://www.filibeto.org/mailman/listinfo/sunray-users > >>>> or, via email, send a message with subject or body 'help' to > >>>> [email protected] > >>>> > >>>> You can reach the person managing the list at > >>>> [email protected] > >>>> > >>>> When replying, please edit your Subject line so it is more specific > >>>> than "Re: Contents of SunRay-Users digest..." > >>>> > >>>> > >>>> Today's Topics: > >>>> > >>>> 1. Re: Top 3 of new Sun Ray features (Craig Bender) > >>>> 2. Re: Top 3 of new Sun Ray features (Ivar Janmaat) > >>>> 3. Re: Top 3 of new Sun Ray features (Wim Coekaerts) > >>>> 4. Server Side Graphics Processing (was: Top 3 of new Sun Ray > >>>> features) (David Bullock) > >>>> 5. Regarding Flash 10 Content (Craig Bender) > >>>> > >>>> > >>>> --------------------------------------------------------------------- > - > >>>> > >>>> Message: 1 > >>>> Date: Wed, 01 Sep 2010 12:57:48 -0700 > >>>> From: Craig Bender<[email protected]> > >>>> To: SunRay-Users mailing list<[email protected]> > >>>> Subject: Re: [SunRay-Users] Top 3 of new Sun Ray features > >>>> Message-ID:<[email protected]> > >>>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed > >>>> > >>>> Folks, > >>>> I apologize if anyone took this to mean we are not pursuing local > >> decode > >>>> solutions, or that I was trying to push Ivar away from wanting local > >>>> decode. That is neither the case, or my intent. > >>>> > >>>> I was simply trying was to highlight that while RCA may be more > >>>> "expensive" in terms of scalability, it has it's place when usability > >> is > >>>> a concern. > >>>> > >>>> At the very least, RCA buys us time to further develop and enhance > our > >>>> existing technologies such as direct decode without impacting end > user > >>>> experience. > >>>> > >>>> On 9/1/10 10:11 AM, Craig Bender wrote: > >>>>> On paper direct decode looks like a better option, and in some cases > >> it > >>>>> is indeed the better option. Like: > >>>>> > >>>>> A purpose built hardware device, or features in an existing devices > >>>>> chipset, dedicated to video processing. Typically these only support > a > >>>>> few formats due to putting codec either in the hardware on in the > > RTOS. > >>>>> Rarely do the codecs in the device support every possible encoding > >>>>> option, so even video that is "supported" at the higher level of the > >>>>> spec, might not play on device. Codec development takes time, and in > >>>>> many cases the vendors of the purpose built device need to license > >>>>> technology from 3rd parties even though there is a free (to use) > >> Windows > >>>>> codec. The biggest problem with the purpose built device though, is > it > >>>>> usually does only one thing. And if it does more than one well it > >>>>> usually costs as much as a PC, but doesn't exactly replace your PC. > >>>>> > >>>>> The other would A device that allows the somewhat easy installation > of > >>>>> readily available codecs. Usually this means windows, but definitely > >>>>> means a fat OS. I say somewhat easy installation because things > rarely > >>>>> just work. You might get prompted to install a codec, you might have > >> to > >>>>> manually research what codec is needed. There might not be a codec > for > >>>>> your OS available, or it might not be free. > >>>>> > >>>>> Then you take thin clients. They have the problems of the purpose > >> built > >>>>> device, with the added the complexity that they really weren't built > >> for > >>>>> video. Sure the chipset may have some codec support (usually parts > of > >> a > >>>>> codec that are "free") but not only do you have to write firmware to > >>>>> access the codec and software to stream it down to them, but you > have > >> a > >>>>> problem with updates to the video format spec itself. They are > >>>>> constantly changing and you wind up having to either replace the > >>>>> hardware or someone has to start writing software drivers, and > >>>>> eventually you have locked down PC. > >>>>> > >>>>> Just like the Sun Ray "future proofs" the device from desktop (i.e. > >>>>> display almost any desktop on the same device), RCA future proofs > the > >>>>> multimedia from the codec required on the display device. > >>>>> > >>>>> It may require more processing at the hypervisor layer, or some > cases > >>>>> the Sun Ray Server layer, and it may not be as efficient bandwidth > >> wise > >>>>> as direct decode, but it makes things usable. And at the end of day, > >>>>> it's not usable, it's not worth buying. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> The problem with purpose built hardware is that > >>>>> > >>>>> On 9/1/10 8:33 AM, Ivar Janmaat wrote: > >>>>>> Hello, > >>>>>> > >>>>>> The advantage of MMR is that it uses less resources on the server > >> since > >>>>>> it is offloading the decoding to the Sun Ray. > >>>>>> This will scale better then vrdp. Although not yet tested I suspect > >> MMR > >>>>>> will use less bandwidth which would give better performance over > WAN. > >>>>>> > >>>>>> #3 means indeed a separation between the system disk c: and the > >>>>>> documents and settings disk d: > >>>>>> I used this a lot in implementations with Virtual Bridges since > they > >>>>>> have had this feature already 10 years ago. > >>>>>> I noticed that you can not select this feature if you use LDAP or > >> Novell > >>>>>> directory servers. It can only be used in combination with AD. > >>>>>> > >>>>>> Kind regards, > >>>>>> > >>>>>> Ivar > >>>>>> > >>>>>> Wim Coekaerts schreef: > >>>>>>> have you tried vdi3.2 with vb as the hypervisor and vrdp ? > >>>>>>> > >>>>>>> it plays flash just fine for windows xp,7, linux etc > >>>>>>> > >>>>>>> not sure what #3 means. I guess you mean the new feature in 3.2 > >> where > >>>>>>> you can replace only the system disk and keep the user disk. I > >> didn't > >>>>>>> realize that didn't work with ldap > >>>>>>> > >>>>>>>> Number 1: > >>>>>>>> Flash 10 content support in MMR on Windows XP. > >>>>>>>> > >>>>>>>> Number 2: > >>>>>>>> MMR support for Windows 7 > >>>>>>>> > >>>>>>>> Number 3: > >>>>>>>> Personal data disk for other directories than AD. > >>>>>>>> > >>>>>>>> I hope this helps to give some direction for future development. > >>>>>>>> > >>>>>>>> Kind regards, > >>>>>>>> > >>>>>>>> Ivar Janmaat > >>>>>>>> _______________________________________________ > >>>>>>>> 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 > >>>>> > >>>>> _______________________________________________ > >>>>> SunRay-Users mailing list > >>>>> [email protected] > >>>>> http://www.filibeto.org/mailman/listinfo/sunray-users > >>>> > >>>> ------------------------------ > >>>> > >>>> Message: 2 > >>>> Date: Thu, 02 Sep 2010 00:13:17 +0200 > >>>> From: Ivar Janmaat<[email protected]> > >>>> To: SunRay-Users mailing list<[email protected]> > >>>> Subject: Re: [SunRay-Users] Top 3 of new Sun Ray features > >>>> Message-ID:<[email protected]> > >>>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed > >>>> > >>>> Hello Craig, > >>>> > >>>> I appreciate your input! > >>>> > >>>> A few years ago my opinion on the implementation of MMR was rather > >>>> negative because in my opinion the ultimate ultra thin client should > >>>> only handle generic codecs not specific Flash and MS codecs of a > >>>> specific version. The RCA method is much more in line with my > thoughts > >>>> on how the ultimate ultra thin client should operate. You definitely > >>>> don't want to end up with an obese client stuffed with all sorts of > >> codecs. > >>>> > >>>> So I like the Virtualbox - RCA - Sun Ray combination. Since > Virtualbox > >>>> supports 3D acceleration, this combination can be very strong. > >>>> (I would like to see some sizing figures on the 3D acceleration > though) > >>>> > >>>> At this time however the VM market is still dominated by VMWare and > KVM > >>>> type VDI solutions which come with all sorts of application > management > >>>> tools. > >>>> If you want to position the Sun Ray as a client for those VDI > >>>> infrastructures, you need something else than vrdp (RCA). > >>>> This is where MMR kicks in. Other options are also possible like > pcoip > >>>> or spice. I have discussed those before. > >>>> The problem with MMR is that it is badly crippled since there is no > >>>> Flash 10 content support at this time. > >>>> It would be a good idea to put Flash 10 content support in MMR before > >>>> Flash 11 arrives. > >>>> Then the Sun Ray would also be a good client for current VDI > locations > >>>> where they don't use Virtualbox. > >>>> > >>>> So eventually it is not only a technical choice. It is also a choice > >>>> between selling Sun Rays solely with Virtualbox or selling it also > with > >>>> other VM solutions. > >>>> I think the broker function of the Sun Ray is unique in the market. > So > >> I > >>>> would favor superb connection protocols to all VM/VDI solutions. This > >>>> would enhance the broker function even further and lift the product > >>>> above other offerings in the market. That is why I asked to fix the > >>>> crippled MMR functionality by supporting Flash 10. > >>>> > >>>> If Oracle however does not fix the MMR then I need to conclude that > >>>> Oracle has already decided to sell Sun Rays only with Virtualbox. > >>>> That would limit the broker function of the Sun Ray server which > >>>> basically means that the solution will become the same as all other > >>>> solutions in the market. > >>>> With head to head competition it will than be much harder to build > >> large > >>>> volume Sun Ray sales. > >>>> > >>>> Kind regards, > >>>> > >>>> Ivar Janmaat > >>>> > >>>> Craig Bender schreef: > >>>>> Folks, > >>>>> I apologize if anyone took this to mean we are not pursuing local > >>>>> decode solutions, or that I was trying to push Ivar away from > wanting > >>>>> local decode. That is neither the case, or my intent. > >>>>> > >>>>> I was simply trying was to highlight that while RCA may be more > >>>>> "expensive" in terms of scalability, it has it's place when > usability > >>>>> is a concern. > >>>>> > >>>>> At the very least, RCA buys us time to further develop and enhance > our > >>>>> existing technologies such as direct decode without impacting end > user > >>>>> experience. > >>>>> > >>>>> On 9/1/10 10:11 AM, Craig Bender wrote: > >>>>>> On paper direct decode looks like a better option, and in some > cases > >> it > >>>>>> is indeed the better option. Like: > >>>>>> > >>>>>> A purpose built hardware device, or features in an existing devices > >>>>>> chipset, dedicated to video processing. Typically these only > support > >> a > >>>>>> few formats due to putting codec either in the hardware on in the > >> RTOS. > >>>>>> Rarely do the codecs in the device support every possible encoding > >>>>>> option, so even video that is "supported" at the higher level of > the > >>>>>> spec, might not play on device. Codec development takes time, and > in > >>>>>> many cases the vendors of the purpose built device need to license > >>>>>> technology from 3rd parties even though there is a free (to use) > >> Windows > >>>>>> codec. The biggest problem with the purpose built device though, is > >> it > >>>>>> usually does only one thing. And if it does more than one well it > >>>>>> usually costs as much as a PC, but doesn't exactly replace your PC. > >>>>>> > >>>>>> The other would A device that allows the somewhat easy installation > >> of > >>>>>> readily available codecs. Usually this means windows, but > definitely > >>>>>> means a fat OS. I say somewhat easy installation because things > >> rarely > >>>>>> just work. You might get prompted to install a codec, you might > have > >> to > >>>>>> manually research what codec is needed. There might not be a codec > >> for > >>>>>> your OS available, or it might not be free. > >>>>>> > >>>>>> Then you take thin clients. They have the problems of the purpose > >> built > >>>>>> device, with the added the complexity that they really weren't > built > >> for > >>>>>> video. Sure the chipset may have some codec support (usually parts > of > >> a > >>>>>> codec that are "free") but not only do you have to write firmware > to > >>>>>> access the codec and software to stream it down to them, but you > have > >> a > >>>>>> problem with updates to the video format spec itself. They are > >>>>>> constantly changing and you wind up having to either replace the > >>>>>> hardware or someone has to start writing software drivers, and > >>>>>> eventually you have locked down PC. > >>>>>> > >>>>>> Just like the Sun Ray "future proofs" the device from desktop (i.e. > >>>>>> display almost any desktop on the same device), RCA future proofs > the > >>>>>> multimedia from the codec required on the display device. > >>>>>> > >>>>>> It may require more processing at the hypervisor layer, or some > cases > >>>>>> the Sun Ray Server layer, and it may not be as efficient bandwidth > >> wise > >>>>>> as direct decode, but it makes things usable. And at the end of day, > >>>>>> it's not usable, it's not worth buying. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> The problem with purpose built hardware is that > >>>> > >>>> ------------------------------ > >>>> > >>>> Message: 3 > >>>> Date: Wed, 01 Sep 2010 16:07:40 -0700 > >>>> From: Wim Coekaerts<[email protected]> > >>>> To: [email protected] > >>>> Subject: Re: [SunRay-Users] Top 3 of new Sun Ray features > >>>> Message-ID:<[email protected]> > >>>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed > >>>> > >>>> we are improving that as well... (rdp rdp7 rca etc) > >>>> > >>>> I would agree with your vmware comment but seriously disagree with > the > >>>> kvm/spice stuff. that's still no where and I can tell you that there > is > >>>> no interest there. > >>>> > >>>> On 09/01/2010 03:13 PM, Ivar Janmaat wrote: > >>>>> Hello Craig, > >>>>> > >>>>> I appreciate your input! > >>>>> > >>>>> A few years ago my opinion on the implementation of MMR was rather > >>>>> negative because in my opinion the ultimate ultra thin client should > >>>>> only handle generic codecs not specific Flash and MS codecs of a > >>>>> specific version. The RCA method is much more in line with my > thoughts > >>>>> on how the ultimate ultra thin client should operate. You definitely > >>>>> don't want to end up with an obese client stuffed with all sorts of > >>>>> codecs. > >>>>> > >>>>> So I like the Virtualbox - RCA - Sun Ray combination. Since > >>>>> Virtualbox supports 3D acceleration, this combination can be very > >> strong. > >>>>> (I would like to see some sizing figures on the 3D acceleration > > though) > >>>>> > >>>>> At this time however the VM market is still dominated by VMWare and > >>>>> KVM type VDI solutions which come with all sorts of application > >>>>> management tools. > >>>>> If you want to position the Sun Ray as a client for those VDI > >>>>> infrastructures, you need something else than vrdp (RCA). > >>>>> This is where MMR kicks in. Other options are also possible like > pcoip > >>>>> or spice. I have discussed those before. > >>>>> The problem with MMR is that it is badly crippled since there is no > >>>>> Flash 10 content support at this time. > >>>>> It would be a good idea to put Flash 10 content support in MMR > before > >>>>> Flash 11 arrives. > >>>>> Then the Sun Ray would also be a good client for current VDI > locations > >>>>> where they don't use Virtualbox. > >>>>> > >>>>> So eventually it is not only a technical choice. It is also a choice > >>>>> between selling Sun Rays solely with Virtualbox or selling it also > >>>>> with other VM solutions. > >>>>> I think the broker function of the Sun Ray is unique in the market. > So > >>>>> I would favor superb connection protocols to all VM/VDI solutions. > >>>>> This would enhance the broker function even further and lift the > >>>>> product above other offerings in the market. That is why I asked to > >>>>> fix the crippled MMR functionality by supporting Flash 10. > >>>>> > >>>>> If Oracle however does not fix the MMR then I need to conclude that > >>>>> Oracle has already decided to sell Sun Rays only with Virtualbox. > >>>>> That would limit the broker function of the Sun Ray server which > >>>>> basically means that the solution will become the same as all other > >>>>> solutions in the market. > >>>>> With head to head competition it will than be much harder to build > >>>>> large volume Sun Ray sales. > >>>>> > >>>>> Kind regards, > >>>>> > >>>>> Ivar Janmaat > >>>>> > >>>>> Craig Bender schreef: > >>>>>> Folks, > >>>>>> I apologize if anyone took this to mean we are not pursuing local > >>>>>> decode solutions, or that I was trying to push Ivar away from > wanting > >>>>>> local decode. That is neither the case, or my intent. > >>>>>> > >>>>>> I was simply trying was to highlight that while RCA may be more > >>>>>> "expensive" in terms of scalability, it has it's place when > usability > >>>>>> is a concern. > >>>>>> > >>>>>> At the very least, RCA buys us time to further develop and enhance > >>>>>> our existing technologies such as direct decode without impacting > end > >>>>>> user experience. > >>>>>> > >>>>>> On 9/1/10 10:11 AM, Craig Bender wrote: > >>>>>>> On paper direct decode looks like a better option, and in some > cases > >> it > >>>>>>> is indeed the better option. Like: > >>>>>>> > >>>>>>> A purpose built hardware device, or features in an existing > devices > >>>>>>> chipset, dedicated to video processing. Typically these only > support > >> a > >>>>>>> few formats due to putting codec either in the hardware on in the > >> RTOS. > >>>>>>> Rarely do the codecs in the device support every possible encoding > >>>>>>> option, so even video that is "supported" at the higher level of > the > >>>>>>> spec, might not play on device. Codec development takes time, and > in > >>>>>>> many cases the vendors of the purpose built device need to license > >>>>>>> technology from 3rd parties even though there is a free (to use) > >>>>>>> Windows > >>>>>>> codec. The biggest problem with the purpose built device though, > is > >> it > >>>>>>> usually does only one thing. And if it does more than one well it > >>>>>>> usually costs as much as a PC, but doesn't exactly replace your PC. > >>>>>>> > >>>>>>> The other would A device that allows the somewhat easy > installation > >> of > >>>>>>> readily available codecs. Usually this means windows, but > definitely > >>>>>>> means a fat OS. I say somewhat easy installation because things > >> rarely > >>>>>>> just work. You might get prompted to install a codec, you might > have > >> to > >>>>>>> manually research what codec is needed. There might not be a codec > >> for > >>>>>>> your OS available, or it might not be free. > >>>>>>> > >>>>>>> Then you take thin clients. They have the problems of the purpose > >> built > >>>>>>> device, with the added the complexity that they really weren't > built > >>>>>>> for > >>>>>>> video. Sure the chipset may have some codec support (usually parts > >> of a > >>>>>>> codec that are "free") but not only do you have to write firmware > to > >>>>>>> access the codec and software to stream it down to them, but you > >> have a > >>>>>>> problem with updates to the video format spec itself. They are > >>>>>>> constantly changing and you wind up having to either replace the > >>>>>>> hardware or someone has to start writing software drivers, and > >>>>>>> eventually you have locked down PC. > >>>>>>> > >>>>>>> Just like the Sun Ray "future proofs" the device from desktop (i.e. > >>>>>>> display almost any desktop on the same device), RCA future proofs > >> the > >>>>>>> multimedia from the codec required on the display device. > >>>>>>> > >>>>>>> It may require more processing at the hypervisor layer, or some > >> cases > >>>>>>> the Sun Ray Server layer, and it may not be as efficient bandwidth > >> wise > >>>>>>> as direct decode, but it makes things usable. And at the end of > day, > >>>>>>> it's not usable, it's not worth buying. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> The problem with purpose built hardware is that > >>>>> > >>>>> _______________________________________________ > >>>>> SunRay-Users mailing list > >>>>> [email protected] > >>>>> http://www.filibeto.org/mailman/listinfo/sunray-users > >>>> > >>>> ------------------------------ > >>>> > >>>> Message: 4 > >>>> Date: Thu, 2 Sep 2010 09:53:27 +1000 > >>>> From: David Bullock<[email protected]> > >>>> To: SunRay-Users mailing list<[email protected]> > >>>> Subject: [SunRay-Users] Server Side Graphics Processing (was: Top 3 > of > >>>> new Sun Ray features) > >>>> Message-ID: > >>>> <[email protected]> > >>>> Content-Type: text/plain; charset="iso-8859-1" > >>>> > >>>> Craig Bender wrote that decoding video under some scenarios may > > require: > >>>> > >>>> processing at the hypervisor layer, or some cases the Sun Ray Server > >> layer, > >>>> > >>>> > >>>> Just to parade my general ignorance on such things, when the > >> hypervisor/SRS > >>>> is compositing screen updates (or decoding video) for its myriad > >> clients, > >>>> is there any benefit from throwing extra graphics cards/GPU's at > the > >>>> server? Or is this not a bottleneck in practice? > >>>> > >>>> thanks, > >>>> David. > >>>> -------------- next part -------------- > >>>> An HTML attachment was scrubbed... > >>>> URL: > >>>> <http://www.filibeto.org/pipermail/sunray- > >> users/attachments/20100902/e69b4 > >>>> b37/attachment-0001.html> > >>>> > >>>> ------------------------------ > >>>> > >>>> Message: 5 > >>>> Date: Wed, 01 Sep 2010 17:06:30 -0700 > >>>> From: Craig Bender<[email protected]> > >>>> To: SunRay-Users mailing list<[email protected]> > >>>> Subject: [SunRay-Users] Regarding Flash 10 Content > >>>> Message-ID:<[email protected]> > >>>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed > >>>> > >>>> On 9/1/10 3:13 PM, Ivar Janmaat wrote: > >>>> > The problem with MMR is that it is badly crippled since there > is > >> no > >>>> > Flash 10 content support at this time. > >>>> > It would be a good idea to put Flash 10 content support in MMR > >> before > >>>> > Flash 11 arrives. > >>>> > >>>> I'm not sure I've covered this before or not, but previous > discussions > >>>> concerning our lack of support for Flash v10 content, or perhaps > better > >>>> stated, the versions of Flash content (v8, v9) that we state support > >>>> for, may be painting our ability to handle Flash v10 content with a > bit > >>>> too broad of a brush. Perhaps we need state we support Flash v10 > >>>> content with a footnote based on the following. > >>>> > >>>> In short there are two "New modes" that Flash can use to push content > >> to > >>>> the screen. These are in *addition* to the three that have been > >>>> available in the past, and are still the most widely used methods. > >>>> > >>>> The first is called "Direct" with uses DirectDraw and Direct3D on > >>>> Windows platforms, and OpenGL on Linux and OSX. > >>>> > >>>> The second is called "gpu" and does full fledged compositing using, > you > >>>> guessed it, the gpu on the client. > >>>> > >>>> While that does indeed seem like scary stuff, I believe our fear of > >> this > >>>> feature would seem to be more theoretical than based on reality. > >>>> > >>>> Most Flash content developers don't seem to be using it, unless they > >> are > >>>> developing a solution based around specific hardware, and not for > what > >> I > >>>> would say "normal consumption". Suppose you had a flash front end to > >>>> your bank. While they may be comfortable to tell you to install > Flash, > >>>> I think the Last thing they would want would be to tell people to > >> update > >>>> to the latest Direct3D driver or OpenGL. > >>>> > >>>> I'm sure there is some direct mode stuff out there, but I still can't > >>>> find an example of any GPU accelerated Flash content "in the wild". > >>>> > >>>> I think most of the issues people are seeing with our Flash solution > >> are > >>>> because of the size limitation, which is something we are addressing. > >>>> Granted 1024x768 is a fairly small area, and we've all seen more than > >>>> our fair share of out of control Flash based sites > >> (http://www.sobe.com/ > >>>> for instance. > >>>> > >>>> More info here on the two new modes from an engineer from Adobe, a > bit > >>>> dated, but explains the features. > >>>> > >>>> http://www.kaourantin.net/2008/05/what-does-gpu-acceleration- > mean.html > >>>> > >>>> Finally, our Flash solution is pretty the same at a higher level as > > RCA. > >>>> Both use motion jpeg. We don't have a "Flash" codec in the the Sun > > Ray, > >>>> so it's not "MMR", or at least it's not local decode of Flash content. > >>>> > >>>> I believe by the time you actually see Direct or GPU mode as a > standard > >>>> or normal way of writing Flash based content (if HTML5 doesn't kill > >>>> Flash), we should have a solution. > >>>> > >>>> > >>>> > >>>> > >>>> ------------------------------ > >>>> > >>>> _______________________________________________ > >>>> SunRay-Users mailing list > >>>> [email protected] > >>>> http://www.filibeto.org/mailman/listinfo/sunray-users > >>>> > >>>> > >>>> End of SunRay-Users Digest, Vol 80, Issue 3 > >>>> ******************************************* > >>>> > >>> > >> _______________________________________________ > >> 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 _______________________________________________ SunRay-Users mailing list [email protected] http://www.filibeto.org/mailman/listinfo/sunray-users
