Hey! On 08/23/2013 10:37 PM, DRC wrote: >> Did you see that they implemented the RemoteFX codec (libfreerdp-rfx) - >> both encode/decode with SSE2 acceleration? That must be something worth >> testing as another option in TurboVNC? I don't know how it would compare >> to libjpeg-turbo (it is some wavelet algorithm) but I think its good >> stuff. It is available on github in their repo: >> >> https://github.com/FreeRDP/FreeRDP/tree/master/libfreerdp/codec > > I doubt that it will perform as well as what we're doing, because I've > personally tested the full-blown RemoteFX solution using a Windows > Server and Windows Client. It doesn't support accelerated OpenGL, so it
Yeah, I read that too - that it softrenders OpenGL, and 1.1 only too I think. So MS is trying to push against DirectX, one might think. > was a non-starter as a remote 3D solution for technical computing, but I > also looked at the general performance, and I wasn't able to push more > than about 1/3 the pixels that TurboVNC is capable of. I agree, though, > that it does bear further investigation. And you had RemoteFX enabled with a GPU on the server side? Just so that you didn't just use "plain RDP" ;) > You can read more about what TurboVNC is doing here > http://www.virtualgl.org/pmwiki/uploads/About/tighttoturbo.pdf and in Yeah, I have read it, although quickly. > the TurboVNC User's Guide, but in a nutshell, our codec has been > designed almost from the ground up around the needs of 3D and video > applications. We built upon TightVNC, which has the ability to split > out areas of solid color in a framebuffer update and send them > separately as bounding boxes (very fast, extremely low-bandwidth), then > the remaining areas of the FBU are divided into subrectangles, and each > subrect is sent using the most optimal subencoding based on the number > of unique colors in the subrect. JPEG is used for high-color subrects, > and mono or indexed color is used for low-color subrects. > > Where we improve upon TightVNC is in picking the mix of subencodings-- I > refer to this in the docs as the "encoding method." TightVNC's encoding > methods are geared toward compressing 2D workloads absolutely as tightly > as it can, since the solution was originally targeted at remote desktop > access over dial-up and satellite. It used JPEG only sparingly because, Right. > at the time, JPEG was really slow. However, the performance assumptions > made by TightVNC 1.3.x are no longer valid. libjpeg-turbo makes JPEG > encoding the fastest method of encoding, so we can get really tight and > fast compression on high-color subrects without having to resort to high > levels of Zlib compression. The Zlib performance curve is nonlinear, > and as you get into the higher levels, you can easily encounter > situations in which your CPU usage doubles but you only get 10% better > compression (NOTE: really wish someone would come up with SSE2 > optimizations for Zlib!) That's basically the problem with the higher > compression levels in TightVNC. CL 9 in TightVNC doesn't, in the > aggregate, produce any better compression than CL 5 except on rare > corner cases, and it eats up 5 times (!) the CPU as CL 5. Anything > above CL 5 in the TightVNC 1.3.x codec (which is what libvncserver used > prior to my involvement, and what many other projects still use) is > literally useless. Thanks for the details! It is quite interesting all this, and I also find it "odd" that TurboVNC isn't more "known" in general (although professionals in visualization clearly knows). You hold a fairly low profile :) >> I also note they are experimenting with both an x11 RDP server and a >> server for Windows. The Windows server (how to capture on Windows has >> been discussed here in other threads) is using the new "Desktop >> Duplication API" that was introduced in Windows 8 that also TightVNC is >> using in their latest release: >> >> http://www.tightvnc.com/release-2.7.php > > Definite improvement over mirror drivers, but it's still a screen > scraper. Screen scrapers can only serve one user at a time, and it's > difficult to do hardware-accelerated 3D with them. Not sure whether the Yes, this "single user" limitation is probably something they do not want to change - since that is where they charge money for RDP licenses. > desktop duplication API changes that, but I doubt it. HP RGS is the > only screen scraper solution I know of that has managed to solve the 3D > problem. Ok, will google that. [SNIP of comparison with Tight, interesting] >> Btw, I looked at the vglrun shell script and AFAICT it simply uses the >> LD_PRELOAD trick. If I turn Remmina into a dynamic library and compile >> it myself, I presume it is easy to make sure I get the faker lib and not >> having to use vglrun? I am not a hardcore C/C++ guy, but I can push >> myself through things ;) > > You're confusing the purposes of VirtualGL and TurboVNC. VirtualGL > redirects the 3D rendering on the server side into a Pbuffer on the > "root" X display, then reads back the rendered pixels and transmits them > to the X proxy (TurboVNC in our case.) You can use other X proxies or > remote display technologies, but that doesn't eliminate the need for > VirtualGL. VirtualGL is what gives you 3D hardware acceleration in your > remote display environment. Yes, I actually understood this - I didn't explain too carefully why I wanted to run Remmina "in VirtualGL". It's because Remmina supports RDP through FreeRDP and I was under the impression (wrong though!) that RDP actually could choose to redirect 3D operations to client side, but that is "Multimedia Redirection" and only covers video/audio, not 3D. So yes, I agree - I only need to "wrap" my Linux apps with vglrun so that I get the OpenGL rendered and pushed through as jpeg. >> Ah, another silly question - the IPP version of libjpeg-turbo, how do I >> use that? 3-4x faster sounds interesting. > > There is no IPP version of libjpeg-turbo. libjpeg-turbo has its own > built-in SIMD routines that accelerate it to 3-4x the performance of > plain libjpeg. It performs on par with IPP in most cases (I re-tested > that recently with IPP 7.1.) > http://www.libjpeg-turbo.org/About/Performance has a run-down. Ok, I thought I read in some directory about IPP version, then I misunderstood. Thanks for the detailed answers! Also I just realized there is no audio in TurboVNC, funny enough I thought there was because I "heard it" but I was of course running everything locally so I was "hearing the server". Any views on sound output/input? I noted the QEMU extension, but agree that it might be "stupid" to mix audio into the same TCP socket. Seems people use PulseAudio "on the side" for this, do you (or anyone) know more about that? regards, Göran ------------------------------------------------------------------------------ Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk _______________________________________________ VirtualGL-Devel mailing list VirtualGL-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-devel
