I think that would be a good idea. It's not that big and it helps - afaik
it's not something that is easily available (unless one digs around in the
tests Phoronix Test Suite offers).
--
This SF.net email is sponsored by Wi
I apologize for my semi-rant. I didn't piece together that you were the one who
was trying to build VGL in order to run glreadtest.
I should maybe consider shipping that test as part of the binary package.
On Jun 15, 2013, at 11:16 PM, Vadim Peretokin wrote:
> The likely issue was that I was u
Here is the data for a GTX 560 (not Ti), 310.14 drivers, Ubuntu 12.04
64bit: http://pastebin.com/raw.php?i=xW8v7UpF
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2de
The likely issue was that I was using Ubuntu's libjpeg-turbo. Using the
.deb off the website + libjpeg-turbo sources built VGL okay. Sorry about
the noise!
--
This SF.net email is sponsored by Windows:
Build for Windows St
I'd like to run the glreadtest binary, which doesn't seem to come with the
.deb and is integrated into the make cmake files for compilation.
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.
Why can't you use the pre-built VirtualGL DEB? Or, if you absolutely must build
VGL from source, try using the official libjpeg-turbo DEB from SourceForge?
There's a good reason why the build instructions suggest using the "official"
libjpeg-turbo binaries to build VGL-- because the static libjp
Hi,
I'm having an issue building VirtualGL sources (2.3.2) on Ubuntu 12.04. The
turbojpeg library isn't where the sources expect, so I update the variable
to locate it - but it still fails with a non-obvious error:
vadi@gooseberry:~/Programs/VirtualGL-2.3.2$ cmake .
-DTJPEG_LIBRARY=/usr/lib/x86_6
glreadtest in the VirtualGL source.
On Jun 15, 2013, at 7:22 PM, Vadim Peretokin wrote:
> I have a GTX 560 that I could run a test on, if there are any easily
> available and anyone wants to look at the number.
> --
> T
I have a GTX 560 that I could run a test on, if there are any easily
available and anyone wants to look at the number.
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev
That doesn't ring true, but I have no way of verifying it, either. The
only Linux machine I have with a GeForce is slow in general (it won't
even memcpy() at more than about 200 Mpixels/sec), so it's not a good
basis for comparison.
On 6/15/13 3:32 PM, Arthur HUILLET wrote:
> On Sat, Jun 15,
Ah, well for the purposes of simulating the full-size display,
client-side scaling (which is already implemented in both the Windows
and Java viewers) is probably what you want. When you use client-side
scaling, the server still sends full-sized updates, and they are
decompressed on the client
> 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
On Sat, Jun 15, 2013 at 12:50:01PM -0500, DRC wrote:
> I dunno about that. My modest Quadro 600 can read back about a
> gigapixel/second. I don't think that's likely to ever be the bottleneck
> on a reasonably modern system.
I have seen some slides that suggest that nVidia cripples the readbac
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
On 6/15/13 11:13 AM, Paul Melis wrote:
> I've done some similar tests, mostly at 3840x2160 over a 10G link. I
> seemed to hit a bottleneck of about 10 fps, but so far assumed it was
> the readback from the GPU that was the problem (GTX680 in a PCI Express
> x16 slot), judging from the vglrun +pr ou
Hi Paul,
On 06/15/13 01:12, Paul McIntosh wrote:
> 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 recal
16 matches
Mail list logo