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 >>>> * 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 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? > >> >> 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
