From: Tom C. <tom...@go...> - 2008-01-19 00:39:43
|
> >> The MESA_screen_surface spec hasn't been touched in a few years, but > >> it's probably pretty close to being workable and implementable. Some > >> code was written to support it but not finished, like the rest of Mesa's > >> EGL code. I suspect we'll get back to it one of these days... > >> > > > > The extension's great if all you want is have a single client access > > the graphics hardware. It falls down if other processes want to use > > the graphics hardware too. I.e. It's not possible to write a window > > system using EGL (which is what I want to do :-)). What could make > > this possible however is if other clients render into off-screen > > buffers and the window system's process is then able to access those > > off-screen buffers and draw them to the screen. I think I'm right in > > saying there's 2 ways to render into an off-screen buffer for this > > purpose: (1) a texture bindable pbuffer (the render_texture extension) > > and (2) a framebuffer (the GL_EXT_framebuffer_object extension). > > > > I envisage a client obtaining a handle/id/address of an off-screen > > buffer it's just rendered into and passing it to the server via some > > form of IPC mechenism. The server then uses the handle/id/address and > > draws the client's off-screen buffer onto the screen possibly using > > some fancy animated transition. :-) > > > > Am I dreaming? Would it be easier/better to implement a new window > > system using the gallium interface? What docs do people recommend I > > read to understand this better? > > EGL & this mesa extension have been exactly though for that. > You create your window manager which implement EGL base > window system and your composite manager use the mesa > extension to display on screen. Other scheme can fit. So a client process can use mesa's EGL implementation to create a pbuffer EGLSurface, create a context, render into the surface then pass the EGLSurface to a server process through a socket. The server can then bind the EGLSurface to a texture using eglBindTexImage and use it to render into a Mesa screen surface. This sounds exactly what I want to do, but the EGL spec says: "EGL objects and related context state cannot be used outside of the address space in which they are created." So I guess if Mesa does allow EGLSurfaces to be shared across processes, it will be against the EGL spec? Another option would be to serialise all the GL commands, but I guess without GLBegin() & GLEnd(), there'd be no (easy) way to buffer commands up for packets. Thoughts? :-) Cheers, Tom |