[Paraview] offscreen display trouble revisited

[John Biddiscombe]

setting VTK_USE_DISPLAY to yes, didn't make any differnce (though most 
of vtk rebuilt itself!)

If I start a single pvserver on the headless machine and connect to it 
it does this
1) if I allow ssh X forwarding (undesired) it opens up a window and 
renders on it (slow), but the client correctly displays it
2) if I ensure DISPLAY is localhost:0 I get an error about no display 
available (ie offscreen impossible).

It seems that the VTK_USE_OFFSCREEN is being ignored

Just to set my mind at rest...

On the headless server which has paraview compiled with Mesa and 
offscreen=yes. The display is set to localhost:0

what should happen when you type 'xterm'?
xterm Xt error: Can't open display: localhost:0

JB





> Francois
>
> vtk is compiled with OSMesa, I was using a cvs version around the end 
> octobers - I just did a cvs update and clean build and the same 
> problem exists. However, I believe I had problems /before /26 oct. I 
> originally attributed my trouble to using pvserver from pv3 and 
> pvclient from pv2, but I'm not doing that any more - it was working in 
> early oct, but I don't know exactly when I broke it.
>
> I tried various DISPLAY localhost:0.0 and :0 combinations, with and 
> without xservers available, but always the same trouble.
>
> (The machines are headless, so offscreen rendering must be software)
>
> Anything else I can try?
>
> JB
>> Hi,
>>
>> Assuming you use cvs version of ParaView, there was some change 
>> related to offscreen rendering in VTK on October 26. Is it when the 
>> warnings started to occur?
>>
>> Under X11, if vtk was compiled with OSMESA (OS=OffScreen) it creates 
>> an OSMesa window and an OSMesa context.
>> Otherwise, (NEW) it tries to use a hardware accelerated offscreen 
>> rendering by creating a window and an OpenGL context and asking for 
>> OpenGL extensions GL_EXT_framebuffer_object and 
>> GL_ARB_texture_non_power_of_two.
>> It those extensions are not available, the OpenGL context and window 
>> are destroyed and it tries to use a Pbuffer offscreen. If not 
>> available, it uses a GLX Pixmap.
>>
>> Under Win32, it first tries the hardware accelerated offscreen 
>> rendering (NEW). If the extensions are not available, an Offscreen 
>> Device Context is used.
>>
>> The source code is in VTK/Rendering: vtkXOpenGLRenderWindow, 
>> vtkWin32OpenGLRenderWindow and the superclass vtkOpenGLRenderWindow.
>>
>> Kent Eschenberg wrote:
>>  
>>> No fixes here - just some related info.
>>>
>>> --On 11/16/2006 02:55:05 PM +0100 biddisco at cscs.ch wrote:
>>>    
>>>> I keep getting a warning that one or more of the servers cannot access
>>>> a display and so compositing will be disabled.
>>>>       
>>> ...
>>>    
>>>> It used to work ok, but I must have broken something. Anyone got 
>>>> any idea?
>>>>       
>>> 1) Another possible cause is that something changed in your OS' 
>>> defaults. Upgrades to some of our systems sometimes replaces various 
>>> graphics header files.
>>>
>>> 2) You might try changing
>>>
>>>    
>>>> and set environment to (also tried blank for DISPLAY)
>>>> DISPLAY :0
>>>>       
>>> to instead set DISPLAY to localhost:0.0.
>>>
>>> 3) Using X Windows and using OpenGL are two different issues; 
>>> linking t Mesa does not always eliminate the need to access X.
>>>
>>> For example, the code may ask X for a font definition that it uses 
>>> to prepare the equivalent font in Mesa.
>>>
>>> There is also a bug (may not be on the formal list) where pvbatch 
>>> (and maybe pvserver) still need to see an X server though they don't 
>>> really use it.
>>>
>>> 4) Finally, keep in mind that there are 2 different types of "off 
>>> screen rendering".
>>>
>>> The one that is officially known by that name has been in OpenGL 
>>> from the beginning (see glXCreateGLXPixmap). It writes to an X 
>>> pixmap instead of the screen (I suspect there is also a Windows 
>>> version). I *think* this approach still uses the graphics card
>>> for acceleration.
>>>
>>> In addition, Mesa can render off screen, into a buffer, and does not 
>>> need a graphics card or an X pixmap - it tries to hide all that from 
>>> the application.
>>>
>>> Of course, all this is just a list of options; perhaps someone who 
>>> knows the internals can comment on how VTK/ParaView actually does 
>>> things???
>>>
>>> Kent
>>> Pittsburgh Supercomputing Center
>>>     
>>
>>
>>   
>
>


-- 
John Biddiscombe,                            email:biddisco @ cscs.ch
http://www.cscs.ch/about/BJohn.php
CSCS, Swiss National Supercomputing Centre  | Tel:  +41 (91) 610.82.07
Via Cantonale, 6928 Manno, Switzerland      | Fax:  +41 (91) 610.82.82