On 3/6/15 6:48 AM, Patric Schmitz wrote:
>>> yuv: does not work, failing with
>>> [VGL] ERROR: in operator=--
>>> [VGL] 437: Invalid compression type
>>> Any idea what's happening there?
>>>
>>> I want to know wether these are reasonable rates/limitations,
>>> especially the jpeg transport which seems CPU-bound (using 140% cpu
>>> in top). Increasing -np did not change anything significantly.
>>
>> JPEG probably will be CPU-limited on a fast network, but you're also
>> seeing a lot of unnecessary CPU time because you're running an
>> unrealistic benchmark.
>
> I see, this is on a very fast network so YUV might be an option.
> Any idea about the issue above?
Were you building the VirtualGL faker from source? In looking at the
source, this seems to be the culprit:
switch(f.hdr.compress)
{
case RRCOMP_RGB: compressRGB(f); break;
case RRCOMP_JPEG: compressJPEG(f); break;
#ifdef USEXV
case RRCOMP_YUV: compressYUV(f); break;
#endif
default: _throw("Invalid compression type");
}
I will have to investigate further, but I think that "#ifdef USEXV" is
probably erroneous in this case, since you can build the server-side
components with YUV compression capability even if you aren't building
the client with XV support. But the easiest workaround for now is just
to make sure you are building the whole solution with XV support
(install the libXv development package. VirtualGL will automatically
disable XV support in the build if it can't find the headers/libs for
libXv.)
> Well the Gentoo ebuild as well as the Arch Linux package deploy the
> package as usual below the /usr hierarchy. There were some
> hardcoded /opt pathes in the cmake files as well as the scripts
> themselves which needed to be made a bit more generic. Also for
> some reason I had to supply the absolute paths for the .so names in
> LD_PRELOAD, I am not sure why yet, but I will find that out.
>
> Is there any particular reason why you chose to deploy stuff in /opt
> instead of with any other regular package below the /usr hierarchy?
> FHS says on opt "This directory should contain add-on packages that
> contain static files". So the question would be why virtualgl is
> considered an "add-on" package. Normally this is used for 3rd party
> (ie not belonging to the distro) tools which are kind of
> self-contained folders not split up into bin/ include/ lib/ etc.
> But since the cmake install goes nicely in that fashion one might
> consider dropping the /opt specialities altogether. Well or just
> make both install locations work more generically. I will send you
> the patches I needed to do.
There shouldn't be any hard-coding in the latest release, and the latest
version of vglrun can accommodate installing the faker under any
arbitrary directory.
Historically, VirtualGL was distributed under /opt because of Sun
packaging requirements (VGL used to be a Sun product.) On Solaris, only
operating system packages were allowed to install anything under /usr.
We had to install under /opt/SUNWvgl (because of package naming
requirements) and put a symlink from /opt/VirtualGL --> /opt/SUNWvgl.
On Linux, we provided a similar interface to /opt/VirtualGL so it could
work similarly to the Solaris version, but the faker has always been
installed under /usr/lib* on Linux, because that's the only way it can
be loaded into setuid binaries (such as VirtualBox, for instance.)
I just examined the build system and can find no hard-coded instances of
/opt that aren't easily overridden using CMake variables. There should
be no reason why a build that overrides CMAKE_INSTALL_PREFIX to /usr
wouldn't work fine. The only thing that would still refer to
/opt/VirtualGL in such a build would be the documentation.
Please send me a specific list of files that you think should be
changed. In all likelihood, there's a good reason why they're doing
what they're doing. I've visited this issue several times before.
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
VirtualGL-Users mailing list
VirtualGL-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/virtualgl-users
