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

  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.

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

Reply via email to