[vtk-developers] GLXPixmap vs OSMesa
Jeff Lee
jeff at cdnorthamerica.com
Fri Mar 11 08:53:52 EST 2005
John Shalf wrote:
> On Mar 10, 2005, at 2:49 PM, Jeff Lee wrote:
>
>> Moreland, Kenneth wrote:
>>
>>> Jeff,
>>> I like the idea of the UseOffScreenRendering flag working without Mesa.
>>> However, we also often use Mesa builds on clusters that do not have
>>> an X
>>> host running. I think using GLXPixmap still requires a connection
>>> to an
>>> X host. Thus if you stripped out the Mesa stuff, our applications may
>>> cease to work. Could you implement this such that if you build with
>>> Mesa you use Mesa offscreen rendering and otherwise use a GLXPixmap?
>>>
>> Hi Kenneth,
>> I was under the impression that mesa has its own glx implementation -
>> fakeglx. I could be wrong, but I think it just turns everything into
>> X. I was hoping that if an application uses mesa, the fakeglx
>> implementation of glxPixmap would just work (mapping down to
>> Pixmap). I think pbuffers will work the same way. Does this make
>> sense? If not, mabey someone could straighten me out on this.
>
>
> I think Ken is right. The mangled Mesa writes directly to an osmesa
> (offscreen mesa) context, thereby completely circumventing X11. The
> 'osmesa' context is purely a feature of Mesa -- not something you
> would see in a standard OpenGL 1.3 implementation. Unfortunately,
> osmesa also leaves you without the benefit of hardware accelerated
> rendering. Both the glxPixmap and the pbuffers require an XServer to
> be running -- in the latter case, pbuffers seems to depend primarily
> on X11 security to mediate access to the framebuffer. I believe the
> people at Tungsten Graphics are working on a way to leverage Chromium
> to do hardware accelerated offscreen rendering without X11 getting in
> the way (kudos to them if it works).
>
> Regardless, it would be nice to have hardware accelerated offscreen
> rendering capability available for people who *do* run an xserver on
> the render nodes of their cluster. So, it would be very cool if the
> pbuffers/glxpixmap stuff gets into the mainstream VTK releases.
> However, Mangled Mesa will need to stay there for people who are not
> running their XServers.
Thanks John,
OK, so if we need to keep osmesa for headless, then I think mabey the
right way forward is to make some new object, say and vtkOffscreenImpl
class which the RenderWindow can delegate to when in offscreen mode
(vtkOffscreenPixmap, vtkOffscreenPbuffer, vtkOffscreenHeadless -for
osmesa). I think that the glxPixmap/pbuffers flavors of OffscreenImpl
are straightforward, as there is no major difference between the mesa
and hardware vendor api(except mesa glxpixmap needs a colormap if the
visual is not truecolor/directcolor), and we can check glx versions and
extensions to see if the offscreen implementation are valid at runtime.
I guess that vtkOffscreenHeadless can just be hash-defined the way
vtkXOpenGLRenderWindow does it now - if vtk is built with osmesa, then
it will work, otherwise it's a noop.
I think that there are 2 main ways this will be used:
1. Batch rendering->hardcopy. This is straightforward, the
RenderWindow is always rendering to an offscreen pixmap, pbuffer,
or osmesa context.
2. Interactive hardcopy. The user is viewing/interacting with a
scene and wants to save to file/printer. What I do now is use
vtkWindowToImageFilter to render to printer resolution and save
the image. The drawbacks of this are that I need to have the
window visible and in front the whole time. What I would like to
do is tell the RenderWindow to open up its offscreen
implementation, render into it and save the file or send the image
to the printer. I'm still not 100% on what the cleanest/fastest
way to do this is - does it make sense to reuse an offscreen
implementation, or just rebuild one every time you hardcopy?
Also, osmesa can do 8-bit, 16-bit, and 32-bit color channels. Right
now, vtk only works with 8-bit, so we'd need to fix up MakeCurrent to
pass the correct size (gl_unsigned_short for 16bit, and gl_float for
32bit). The configuration (cmake) would have to be beefed up to handle
all 3 versions of libOSMesa too.
Any suggestions, criticisms are welcome.
-Jeff
>
> -john
>
>>>> -----Original Message-----
>>>> From: vtk-developers-bounces at vtk.org
>>>> [mailto:vtk-developers-bounces at vtk.org] On Behalf Of Jeff Lee
>>>> Sent: Thursday, March 10, 2005 3:02 PM
>>>> To: vtk-developers
>>>> Subject: [vtk-developers] GLXPixmap vs OSMesa
>>>>
>>>> Hi All,
>>>> I have been tooling around with glpixap for offscreen rendering. I
>>>> started with vtkXOpenGLRenderWindow and managed to strip out the
>>>> osmesa stuff and replace its implementation with rendering to a
>>>> glxpixmap instead (a'la John Schalf and Glenn Lehmann). All of
>>>> this works great, all I have to do is call SetOffScreenRendering(1)
>>>> on the renderWindow, and then I can dump the image to a file.
>>>> Eventually I can have it such that switching between
>>>> onscreen/offscreen will work similar to windows. I can also see a
>>>> pbuffer implementation as a straightforward extension of this.
>>>>
>>>> The question is, can anyone see any major drawbacks of dropping
>>>> osmesa for this approach? The benefits that I can see are;
>>>>
>>>> 1. No more mangled mesa, this approach (glxPixmap) works both in
>>>> mesa and in hardware drivers.
>>>> 2. We can stop tiling the display to get high-resolution images.
>>>> 3. Similar behavior to that of vtkWin32OpenGLRenderWindow.
>>>> 4. Can further extend to hardware-accelerated pbuffers with drivers
>>>> that support it.
>>>>
>>>> Possible Drawbacks:
>>>>
>>>> 1. Perhaps not everyone has a driver which supports glx1.3.
>>>> 2. glxpixmap is slow (not when compared to osmesa).
>>>>
>>>> I would like to eventually replace what's in vtkXOpenGLRenderWindow
>>>> with glxpixmap. Does anyone have other arguments which I am
>>>> perhaps not seeing, or reasons for not doing this? Thanks in advance.
>>>> Regards,
>>>> Jeff
>>>>
>>>> --
>>>> Jeff Lee
>>>> Senior Software Engineer
>>>> Computational Dynamics North America Ltd
>>>> 21 Lafayette Street, Suite 230
>>>> Lebanon NH 03766 USA
>>>> fax: 603 643 9994
>>>> phone: 603 643 9993 x109
>>>> http://www.cd-adapco.com
>>>>
>>>> _______________________________________________
>>>> vtk-developers mailing list
>>>> vtk-developers at vtk.org
>>>> http://www.vtk.org/mailman/listinfo/vtk-developers
>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> vtk-developers mailing list
>>> vtk-developers at vtk.org
>>> http://www.vtk.org/mailman/listinfo/vtk-developers
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> vtk-developers mailing list
>> vtk-developers at vtk.org
>> http://www.vtk.org/mailman/listinfo/vtk-developers
>
>
>
--
Jeff Lee
Senior Software Engineer
Computational Dynamics North America Ltd
21 Lafayette Street, Suite 230
Lebanon NH 03766 USA
fax: 603 643 9994
phone: 603 643 9993 x109
http://www.cd-adapco.com
More information about the vtk-developers
mailing list