[Paraview] offscreen display trouble revisited

[John Biddiscombe]

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