Sorry, I pressed the wrong button and sent it prematurely. On Wed, Jan 13, 2010 at 8:41 AM, Chia-I Wu <olva...@gmail.com> wrote: > On Wed, Jan 13, 2010 at 2:46 AM, Jakob Bornecrantz <ja...@vmware.com> wrote: >> On 12 jan 2010, at 16.16, Chia-I Wu wrote: >>> >>> On Tue, Jan 12, 2010 at 10:52 PM, Jakob Bornecrantz <ja...@vmware.com> >>> wrote: >>>> >>>> On 12 jan 2010, at 04.23, Chia-I Wu wrote: >>>>> >>>>> * Write up documentation >>>>> * Remove unused/non-working EGL drivers >>>>> * Remove drivers that are deprecated by egl_g3d >>>>> * Automatic driver selection (like DRI) >>>>> * Re-organize EGL demos >>>>> >>>>> The drivers to be removed are >>>>> >>>>> * Unused >>>>> * src/egl/drivers/demo/ >>>>> * src/egl/drivers/xdri/ >>>> >>>> I think that at least demo should remain if for nothing more then to >>>> serve >>>> as a empty skeleton for anybody wishing to make their own driver. >>> >>> The idea is that src/egl/drivers/glx/ has already provided a simple EGL >>> driver >>> that works. The demo driver, though compiles, is outdated or may outdate >>> over >>> time since it is not a working driver that can be verified. >> Hmm, maybe you are right. But it doesn't cost anything to keep it around. > The demo driver does not free resources at eglTerminate. It does not > initialize surfaces with _eglInitSurface. There may be more, which makes it a > bad demo driver. > > It may be updated, but since the driver won't run, it is hard to find if > anything is missing there. >>>>> * Non-working >>>>> * src/egl/drivers/dri/ >>>> >>>> Having the dri driver working would be desirable since it allows you to >>>> use >>>> none gallium drivers standalone. >>> >>> The only problem with the dri driver is that no one is maintaining it. I >>> agree >>> that there might still interests in loading DRI drivers from EGL drivers. >>> I >>> wrote one for Android. >>> >>> How about we keep the xdri driver and leave dri driver in the git history? >>> The >>> xdri driver >>> >>> * dlopen()s DRI1/DRI2 drivers >>> * talks with the X server using DRI1/DRI2 (the protocol) to implement >>> functions like getBuffersWithFormat >>> * works well >>> >>> The first point is the key idea shared by both dri and xdri drivers. >> The xdri driver is pretty much deprecated by the glx driver as it does >> pretty much the same thing. The dri is more interesting then the xdri driver >> since it is standalone from X. > However, it lacks maintenance. Th I tried to fix it once, but I gave up soon. Because the fix to it is not trivial and even if that is done, the egl dri driver supports only DRI1, which is fading out. egl_xdri is doing what egl_glx is doing, but in an interesting and different way. With direct access to DRI drivers, it is capable of doing what egl_glx can't (e.g. eglBindTexImage requires pbuffer but GLX_EXT_texture_from_pixmap supports only pixmaps).
My concern with keeping these drivers is that, when I first came to EGL in Mesa, there were 4 drivers under egl/drivers/. Three of them did not work, and two of them even didn't compile. It confused me. There are two EGL implementations I know of that load DRI(2) drivers and support non-X window system. One is egl_android. The other is libeagle for Wayland. egl_android works great but it uses a different build system (Android.mk). libeagle is a standalone library, but it is more promising. I do have some interests in porting it to egl_eagle and have Wayland use standard libEGL, but I haven't found the time. It would be great if someone is willing to help port libeagle. Otherwise, I prefer egl_xdri over egl_dri, or removing both. What do you think? >>>>> * src/mesa/drivers/dri/fb/fb_egl.c >>>>> * src/mesa/drivers/dri/radeon/server/radeon_egl.c >>>>> * src/mesa/drivers/dri/r600/server/radeon_egl.c >>>>> * src/mesa/drivers/dri/r300/server/radeon_egl.c >>>>> * src/mesa/drivers/dri/r200/server/radeon_egl.c >>>>> * Deprecated by egl_g3d >>>>> * src/gallium/state_trackers/egl/ >>>>> * src/gallium/winsys/egl_xlib/ >>>>> >>>>> If anyone has any concern or is actively using any of the driver listed >>>>> above, >>>>> please let me konw. The removal, especially of those in the last >>>>> category, is >>>>> still a plan, and is supposed to be several weeks away. If anyone has >>>>> any >>>>> trouble using/testing egl_g3d, please let me know too. >>>> >>>> I'm okay with removing s/g/st/egl and moving egl_g3d to s/g/st/egl. >>>> Actually >>>> I'm more then okay with the move since I'm not a big fan of the name name >>>> egl_g3d. >>> >>> Thanks. I will do the rename after the removal :P >>>>> >>>>> As for the re-organization, I want to move various demos using EGL to >>>>> progs/egl/. The directory structure will be like >>>>> >>>>> progs/egl/opengl >>>>> progs/egl/opengles1 >>>>> progs/egl/opengles2 >>>>> progs/egl/openvg >>>> >>>> Also progs/egl/interop once we get inter API communication working. >>> >>> Yes. Actually, inter API communication should be working with egl_g3d. >>> It >>> just lacks demos. >> >> Ah cool, I'm looking forwards to when we get EGLImage. There is working EGLImage support in egl_android, which uses DRI. st_public.h is not enough to support EGLImage and its family. I plan to add it to egl_g3d after reworking st_public.h. >> >>>>> >>>>> There will be simple window-system glue code that the demos may use. >>>>> Simple >>>>> demos who use the glue code will be able to run on multiple window >>>>> systems >>>>> like >>>>> X11 and bare KMS. >>>>> >>>>> There are also plans for new features and internal cleanups. But I want >>>>> to >>>>> start with attracting new users/developers first, as EGL is almost ready >>>>> to >>>>> shine. >>>> >>>> Nice work! >>>> Can you write down a list of what drivers that the new code produce? >>> >>> When configured with --egl-native-displays=x11,kms, egl_g3d will give >>> libeglx11.a and libeglkms.a. They are used by winsys/drm/ to give >> >> Just a nitpick --egl-native-displays should be somehow marked as being >> gallium only as the native display interface is dependent on gallium, also >> why do you have to include egl_g3d there shouldn't that just be common? Sorry, I had some typos. It is "--with-egl-native-displays=x11,kms". It is used by gallium to decide which drivers to compile. And, it will be used by libEGL to decide which drivers to probe. I am thinking having libEGL look for egl_x11_*.so or egl_kms_*.so depending on an environment variable, say EGL_DISPLAY=x11 or EGL_DISPLAY=kms, respectively. When the variable is not set, it will assume a default value, which is the first display listed in --with-egl-native-displays. >> >>> >>> egl_x11_i965.so >>> egl_x11_i915.so >>> egl_x11_nouveau.so >>> egl_x11_r300.so >>> egl_x11_vmwgfx.so >>> egl_kms_i965.so >>> egl_kms_i915.so >>> egl_kms_nouveau.so >>> egl_kms_r300.so >>> egl_kms_vmwgfx.so >>> >>> I only tested the i915 ones. Luca reported success with nouveau ones. >>> The >>> others are only compile tested. Automatic driver selection is also part >>> of the >>> plan. >> >> Ok cool stuff. >> >> Cheers Jakob. >> > ------------------------------------------------------------------------------ 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
