Gerard,
You can still run paraview but you don't use VirtualGL if you don't have
software acceleration .
If you
ssh -X nemo (from the sun ray client)
and then run paraview, it will use indirect OpenGL to do software
rendering on the Sun Ray server.
Linda
Steve Nash wrote:
> Gerard Henry wro
Steve Nash wrote:
>
> Gerard,
>
> My config is:
> - paraview running on S10U5 Sun Ultra 24 (amd64)
> - display on Sun Ray DTU, with Sun Ray server: Sun v440 S10U2 (Xsun)
>
> From my Sun Ray session, I:
>sunray> ssh -X ultra24
>ultra24> paraview --data=polyex.vtk
>When it comes u
Steve Nash wrote:
> Gerard,
>
> When using a Sun Ray as the client, the graphics server needs to be able
> to talk directly to the Sun Ray DTU. That is, the DTU should not be on
> a separate private network.
>
i'm not agree with this comment, if i understand well what i read in the
820-3256
Gerard Henry wrote:
> Steve Nash wrote:
>> Gerard,
>>
>> When using a Sun Ray as the client, the graphics server needs to be able
>> to talk directly to the Sun Ray DTU. That is, the DTU should not be on
>> a separate private network.
>>
>
> i'm not agree with this comment, if i understand well
hello all,
back from vacation, i'm trying to test your suggestions with SharedViz,
but the results are bad yet.
calypso is the sunray server
nemo is the paraview server
SharedViz is installed on nemo, but also on calypso (OpenGL is
up-to-date on calypso)
here are some messages:
nemo-henry% /op
Gerard,
Just to be clear. The sequence of events should be:
login to the Sun Ray.
ssh -X nemo (the server with graphics)
vglrun paraview
Linda
Steve Nash wrote:
> Gerard,
>
> When using a Sun Ray as the client, the graphics server needs to be able
> to talk directly to the Sun Ray DTU. That
Gerard,
When using a Sun Ray as the client, the graphics server needs to be able
to talk directly to the Sun Ray DTU. That is, the DTU should not be on
a separate private network.
Additionally, you should not need to specify the '-cl' and '-d' vglrun
options. The display that should be used
Gerard,
I am building up an S10U5 system like yours to see if I can reproduce
the problem.
The resolvepath directory in your truss output is from how Qinghuai
build paraview, and is harmless other than an unnecessary search by the
run time linker. When Qinghuai gets back from vacation we can
Steve Nash wrote:
> Gerard,
>
> I tried it with a Solaris 10 U3 box and didn't have any problems. Are
> you doing anything special with the model? I load it in, and make it
> visible and then spin it around.
>
> I will try to upgrade a system to S10 U5 like you have to see if that
> makes a
Steve Nash wrote:
> Gerard,
>
> I was able to remote display Paraview 3.0.2 using your model file from a
> Linux box (SLES10) to both a Sun Ray and a Solaris SPARC desktop w/o
> problems. I tried both a very old Sun Ray server version (3.1) and a
> newer 4.0 with the same results.
>
if i unde
Linda Fellingham wrote:
> Gerard,
>
> Qinghuai is on vacation this week, else I am sure he would respond to
> your email.
>
> Are you running paraview directly on the Sun Ray server or are you
> using Shared Viz to remote the display to Sun Ray, while running
> paraview (both client and server)
mismatch in the supported
extensions available between the server and client. What OS is running
on the nemo box?
Steve
>
> Original Message
> Subject: Re: [hpcdev-discuss] problems with paraview on sunrays
> Date: Mon, 21 Jul 2008 21:34:12
Gerard,
Qinghuai is on vacation this week, else I am sure he would respond to
your email.
Are you running paraview directly on the Sun Ray server or are you using
Shared Viz to remote the display to Sun Ray, while running paraview
(both client and server) on another system?
Linda
Gerard Henr
hello all,
we have a problem with paraview 3.0.2. It works well, but many users are on
Sunrays here, and we found a case where paraview is totally hanging. The same
example works well if i display paraview on my laptop with Solaris Express
(snv_79a and Xorg), so i suspect a problem with Xsun on
14 matches
Mail list logo
