On Sat, Dec 26, 2009 at 07:27:09PM +0100, Luca Barbieri wrote: > > Screen surfaces are by definition scan-out buffers of the adapters. In > > theory, the extension is used by opengl applications in an environment > > without display server, or used by the display server itself. And the > > extension cannot be supported by any X11 driver. > > The main reason, at least for me, to "emulate" it under X11 is that > > about half of the demos require the extension to run. It might scare > > away those who are new to EGL when half of the demos fail to run under > > X11. But to emulate it, I would like it to be as simple as possible. > Another big advantage is that it is the only way to write EGL programs > without window system specific code. > Maybe an EGL_MESA_input could be added to abstract input in the same > way, but this is more tricky. Or to say it in another way, intead of staying window system neutral, EGL turns into a window system. There will never be enough extensions to cover the functions a real window system might provide. > I'm not sure if it can be made simpler. > Presenting a maximized window seems to me much more user friendly that > a randomly sized one, especially considering that the application may > not have code to handle resizing of the window, so I wouldn't cut that > out > You could cut out the xrandr modesetting, but that would prevent using > the extension to actually set a screen mode as it would happen on a > console implementation. > Outside of eglx11.c, the changes are minimal. > egl_glx support is required for acceleration. > egl_xlib support may be removed, but it is cheap to have. In my view, screen surfaces do not exist on X11. Even if we try to approximate all aspects of EGL_MESA_screen_surface on X11, we provide nothing but a convenient library that is capable of a limited subset of what native libraries could have done.
But as I said, some of the demos require the extension to run. It is not that bad if we could make them work under X11 with minimal work. Probably also print a warning when the demos run. I do not know how much is "minimal", but if you say eglx11.c is already minimal, I believe it is. > > What do you think if the changes are made minimal and are made to a > > single driver? I think eglx11.[ch] may be simplified for less > > flexibility and functionality, but still enough to support the demos. > > Also, I would like to move it to either egl_softpipe or egl_glx. I > > prefer egl_softpipe because it supports APIs other than OpenGL (which is > > why it is default). But if you would like to have acceleration, egl_glx > > is fine too. > For the purpose of making demos just work, egl_glx seems superior, as > it would be surprising for the user to have their demos possibly > taking several seconds per frame with egl_softpipe. > That allows to have EGL demos be as good as the GLX ones, and actually > better since they would automatically present sensibly sized (i.e. > maximized) windows and support fullscreen. I think either way is fine. While working on libEGL.so, I try to keep any window system (X11, Windows, Android, ...) dependencies from it. There is a problem when two drivers supporting the same window system want to share code. But I think it should be solved by changing the way drivers are built, just like what various gallium EGL drivers are built right now. Otherwise, let's add it to one of the drivers for now. > > There are 3 EGL drivers for X11 right now. Longer term, I would like to > > have a single driver that supports multiple APIs and acceleration. The > > driver should talk DRI2 (the protocol) and probably minimal GLX to the X > > server. > Yes, that probably should be done. > Ideally the following should probably happen: > 1. Make all the various components shared libraries (with git version > or whatever in the filename to allow ABI breaking): Mesa, the Mesa > state tracker, and the Gallium state trackers and drivers > 2. Make libGL.so GLX a driver loader > 3. Make a GLX indirect driver from src/glx/x11 > 4. Make a DRI GLX driver from src/glx/x11 and mesa/drivers/dri/common. Remove > 5. Make a Gallium software GLX driver from src/gallium/winsys/xlib > 6. Remove egl_xlib in favor of egl_glx over the Gallium software GLX > driver. This way X11 support is only done through GLX. > 7. Remove the non-Gallium fakeglx stuff in src/mesa/drivers/x11 in > favour of src/gallium/state_trackers/glx/xlib > 8. Remove egl_dri and egl_xdri > 9. Change src/gallium/state_trackers/egl to be an independent EGL > driver loading the shared librariy Gallium drivers > 10. Possibly remove swrast and all the Mesa drivers except state_tracker > This way we would have the Gallium EGL driver for console EGL and > egl_glx for X11. > Non-Gallium DRI EGL support probably doesn't matter since it will > hopefully go away relatively soon and there is no real installed base. Remember that EGL supports multiple APIs (OpenVG, OpenGL|ES, ...) and have extensions for resouce sharing between the APIs. For this reason, instead of adding extensiosns to GLX or to X11, I think EGL on X11 should be designed around DRI2 protocol, not GLX protocol. And indirect rendering will not be supported in general. This is basically what egl_xdri is doing, except that egl_xdri loads a DRI driver and is limited to OpenGL. Gallium EGL drivers are good base for the work. I plan to start working on it soon. -- Regards, olv ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
