> Can you provide more details of exactly why you need to use a 24-36
> Mpixel display?
I support a visualisation cluster which is a number of partners. One partner
has large 6 screen displays all over Australia. Another Uni on the other side
of Australia has just installed multi-screen display. Also we'll be installing
a Cave/Vis-wall (of which I have been asked to come up with some demos). So it
would be nice to be able to support direct realtime vis on these systems.
I don't yet have direct access to these systems myself, so the question on
scaling etc is with the view to testing on any machine (just by setting a large
screen size), with the results somewhat representative of how it might act on a
real display. It appears the answer is yes - so I'll test with that and see
what I can come up with.
I'll post some results.
Cheers,
Paul
----- Original Message -----
> From: "DRC" <dcomman...@users.sourceforge.net>
> To: virtualgl-users@lists.sourceforge.net
> Sent: Sunday, 16 June, 2013 4:05:37 AM
> Subject: Re: [VirtualGL-Users] Improving performance on very large displays
>
> Well, it's important to understand that VNC will usually just send
> the
> portions of the display that have changed ("incremental framebuffer
> update.") It will send a full framebuffer update upon first
> connecting
> and when specifically requested by the viewer (using the Refresh or
> Lossless Refresh functions) or when the scaling factor is changed,
> etc.
> The TurboVNC X11 viewer doesn't maintain a back buffer, and thus it
> will also request a full framebuffer update if the window is
> minimized/maximized or obscured. The Windows and Java viewers,
> however,
> are smart enough to redraw the window's current contents without
> requesting a new update from the server. All of that is somewhat
> moot
> if you are using a full-screen viz app that updates most of the
> display
> on every frame.
>
> To answer your question, since the viewer is maintaining a copy of
> the
> pixels from the server, a full framebuffer update will always send
> all
> of the pixels from the server, even if some of them aren't visible in
> the viewer due to the window size. The reason for this is both
> because
> the logic would be inordinately complicated if it was only
> maintaining
> the visible portion of the display, and also you wouldn't want to
> have
> to wait for a new framebuffer update when using the scrollbars.
>
> Downsampling on the server: Someone else asked about this, and I'm
> going to look into the possibility of using the RANDR extension (part
> of
> the desktop resize functionality that will go into TurboVNC 1.3) to
> do
> this. However, I'm not really sure how useful it would be. I don't
> understand why anyone would want to run the TurboVNC Server in a
> resolution that is significantly larger than the client display,
> unless
> they were broadcasting to multiple clients that support different
> resolutions.
>
> With downsampling, the text is quickly going to become unreadable.
> Can
> you provide more details of exactly why you need to use a 24-36
> Mpixel
> display? Perhaps I can provide a more intelligent answer.
>
>
> On 6/15/13 12:35 AM, Paul McIntosh wrote:
> > Hi Darrell,
> >
> > Thanks - the client we just tried was a Windows one but we'll be
> > trying a few. I'll give the multi-threading a go.
> >
> > For testing purposes, how out is setting a standard resolution
> > screen to something ridiculous? Is it smart enough to down sample
> > on the server side if the client is viewing in scaled mode? Or if
> > the client is viewing in full res, but only a portion, is the out
> > of view portion not sent?
> >
> > The point James just made is also something I need to try, I forgot
> > to look if the ssh daemon was maxing out! And I should test with
> > it without any tunnel at all.
> >
> > Cheers,
> >
> > Paul
> >
> > ----- Original Message -----
> >> From: "DRC" <dcomman...@users.sourceforge.net>
> >> To: virtualgl-users@lists.sourceforge.net
> >> Sent: Saturday, 15 June, 2013 9:43:08 AM
> >> Subject: Re: [VirtualGL-Users] Improving performance on very large
> >> displays
> >>
> >> Bigger pipes will definitely help, up to a point. The compression
> >> ratio
> >> you can get will vary a lot depending on the types of images that
> >> the
> >> app is generating. I use GLXspheres as a sort of
> >> "middle-of-the-road"
> >> approximation, since it has a realistic proportion of solid color
> >> and
> >> smooth gradient, one that you might see in a CAD or viz app when
> >> the
> >> model is zoomed out to fit in the window. However, as they say
> >> here
> >> in
> >> the States, your mileage may vary.
> >>
> >> GLXspheres compresses to about 1.8 bits/pixel when using
> >> perceptually
> >> lossless JPEG, about 0.75 bits/pixel when using medium-quality
> >> JPEG,
> >> and
> >> about 0.4 bits/pixel when using low-quality JPEG. Thus, for that
> >> particular image workload to maintain 15 fps at low quality on a
> >> 24-36
> >> Mpixel display would require 10-15 Megabits/sec of bandwidth.
> >> Double
> >> that for medium quality.
> >>
> >> It is also more than likely that you will run into a CPU
> >> bottleneck
> >> once
> >> you eliminate the network bottleneck. libjpeg-turbo is typically
> >> going
> >> to be capable of compressing perceptually lossless JPEG at about
> >> 60-100
> >> Mpixels/sec on a reasonably modern CPU core (maybe a bit more than
> >> that
> >> now-- my machine is 2 years old.) Add 30% to that for
> >> medium-quality
> >> JPEG, and add 50% for low-quality JPEG (both are faster, simply
> >> because
> >> they generate less data for the Huffman codec.) So applying that
> >> to
> >> the
> >> GLXspheres example above, my particular machine might be capable
> >> of
> >> compressing ~2-4 fps with a 24-36 Mpixel display, or perhaps ~3-6
> >> fps
> >> if
> >> using low-quality JPEG.
> >>
> >> If the client and server are reasonably similar in terms of CPU
> >> performance, then you can probably improve the situation by
> >> enabling
> >> server-side multithreading (export TVNC_MT=1 prior to launching
> >> vncserver.) This divides the VNC desktop into equal-sized tiles
> >> and
> >> uses a separate compression thread for each. Even though the
> >> client
> >> is
> >> not multithreaded yet, typically libjpeg-turbo can decompress a
> >> lot
> >> faster than it compresses, so enabling server-side multithreading
> >> will
> >> likely shift the CPU bottleneck to the client. Be sure to read
> >> the
> >> section on multithreading in the TurboVNC User's Guide.
> >>
> >> I have funding to work on multithreading the client as well and
> >> will
> >> be
> >> looking into that later this summer. Can you clarify which viewer
> >> you're using?
> >>
> >>
> >> On 6/14/13 6:12 PM, Paul McIntosh wrote:
> >>> Hi,
> >>>
> >>> I have done a couple of experiments with very large displays
> >>> (e.g.
> >>> 7680x4800, 7680x3200) and the performance has (understandably)
> >>> dropped significantly.
> >>>
> >>> Are there any tricks to improving the performance or is it not
> >>> worth trying? I recall multi-threaded builds but have not had a
> >>> chance to try them out.
> >>>
> >>> The tests so far have been on less than optimal links - we will
> >>> be
> >>> trying a long hall 1G network soon (across Australia) and
> >>> possibly
> >>> a shorter 10G link (from one facility on campus to another).
> >>> Would
> >>> bigger pipes solve the issue or is the bottle neck be elsewhere?
> >>>
> >>> Cheers,
> >>>
> >>> Paul
> >>>
> >>
> >> ------------------------------------------------------------------------------
> >> This SF.net email is sponsored by Windows:
> >>
> >> Build for Windows Store.
> >>
> >> http://p.sf.net/sfu/windows-dev2dev
> >> _______________________________________________
> >> VirtualGL-Users mailing list
> >> VirtualGL-Users@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/virtualgl-users
> >>
> >
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> VirtualGL-Users mailing list
> VirtualGL-Users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/virtualgl-users
>
--
Dr Paul McIntosh
Senior HPC Consultant, Technical Lead,
Multi-modal Australian ScienceS Imaging and Visualisation Environment
(www.massive.org.au)
Monash University, Ph: 9902 0439 Mob: 0434 524935
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
VirtualGL-Users mailing list
VirtualGL-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/virtualgl-users
