Plans for EGL

[Chia-I Wu-2]

Hi all,

I just pushed a new EGL driver (egl_g3d) to master.  The new driver is located
at src/gallium/state_trackers/egl_g3d/.  When built, it provides .a archives
that are later linked to by src/gallium/winsys/drm/<hw>/egl_g3d/ to provide the
final EGL drivers loadable by libEGL.

This new driver supports mixed client APIs (OpenGL, OpenVG, and OpenGL ES).  It
supports both HW/SW rendering on X11 and supports EGL_MESA_screen_surface on
bare KMS.  The goal of this driver is to provide _the_ EGL driver for Gallium
architecture.

I am working on merging opengl-es-v2 branch.  When that is done, I plan to work
on preparing EGL for easy/wide adoption.  The specific items I have right now
are

* 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/
* Non-working
  * src/egl/drivers/dri/
  * 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.

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

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.

-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@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Keith Whitwell-3]

On Mon, 2010-01-11 at 20:23 -0800, Chia-I Wu wrote:

> Hi all,
>
> I just pushed a new EGL driver (egl_g3d) to master.  The new driver is located
> at src/gallium/state_trackers/egl_g3d/.  When built, it provides .a archives
> that are later linked to by src/gallium/winsys/drm/<hw>/egl_g3d/ to provide the
> final EGL drivers loadable by libEGL.
>
> This new driver supports mixed client APIs (OpenGL, OpenVG, and OpenGL ES).  It
> supports both HW/SW rendering on X11 and supports EGL_MESA_screen_surface on
> bare KMS.  The goal of this driver is to provide _the_ EGL driver for Gallium
> architecture.
>
> I am working on merging opengl-es-v2 branch.  When that is done, I plan to work
> on preparing EGL for easy/wide adoption.  The specific items I have right now
> are
>
> * 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/
> * Non-working
>   * src/egl/drivers/dri/
>   * 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.
>
> 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
>
> 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.

This all sounds great to me.  I'm looking forward to seeing this happen.

Keith


------------------------------------------------------------------------------
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@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Jakob Bornecrantz-3]

On 12 jan 2010, at 04.23, Chia-I Wu wrote:

> Hi all,
>
> I just pushed a new EGL driver (egl_g3d) to master.  The new driver  
> is located at src/gallium/state_trackers/egl_g3d/.  When built, it  
> provides .a archives that are later linked to by src/gallium/winsys/
> drm/<hw>/egl_g3d/ to provide the final EGL drivers loadable by libEGL.
>
> This new driver supports mixed client APIs (OpenGL, OpenVG, and  
> OpenGL ES).  It supports both HW/SW rendering on X11 and supports  
> EGL_MESA_screen_surface on bare KMS.  The goal of this driver is to  
> provide _the_ EGL driver for Gallium architecture.
>
> I am working on merging opengl-es-v2 branch.  When that is done, I  
> plan to work on preparing EGL for easy/wide adoption.  The specific  
> items I have right now are
>
> * 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.

> * Non-working
>  * src/egl/drivers/dri/

Having the dri driver working would be desirable since it allows you  
to use none gallium drivers standalone.

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

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

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

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@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Chia-I Wu-2]

On Tue, Jan 12, 2010 at 10:52 PM, Jakob Bornecrantz <jakob@...> 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@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Jakob Bornecrantz-3]

On 12 jan 2010, at 16.16, Chia-I Wu wrote:

> On Tue, Jan 12, 2010 at 10:52 PM, Jakob Bornecrantz  
> <jakob@...> 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.

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

>>>  * 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@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Chia-I Wu-2]

On Wed, Jan 13, 2010 at 2:46 AM, Jakob Bornecrantz <jakob@...> wrote:

> On 12 jan 2010, at 16.16, Chia-I Wu wrote:
>>
>> On Tue, Jan 12, 2010 at 10:52 PM, Jakob Bornecrantz <jakob@...>
>> 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@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Chia-I Wu-2]

Sorry, I pressed the wrong button and sent it prematurely.

On Wed, Jan 13, 2010 at 8:41 AM, Chia-I Wu <olvaffe@...> wrote:

> On Wed, Jan 13, 2010 at 2:46 AM, Jakob Bornecrantz <jakob@...> wrote:
>> On 12 jan 2010, at 16.16, Chia-I Wu wrote:
>>>
>>> On Tue, Jan 12, 2010 at 10:52 PM, Jakob Bornecrantz <jakob@...>
>>> 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@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Ian Romanick-4]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jakob Bornecrantz wrote:

> On 12 jan 2010, at 16.16, Chia-I Wu wrote:
>> On Tue, Jan 12, 2010 at 10:52 PM, Jakob Bornecrantz  
>> <jakob@...> wrote:
>>>> * 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.

Not entirely true.  There is quite a movement within Khronos to get
platforms off the platform-specific window system bindings and onto EGL.
 I support this plan as it provides a lot of benefit to Linux / X.

 * Windows applications written to EGL instead of WGL are just a little
bit easier to port to a version of Linux that supports EGL on X.

 * Linux applications written to EGL instead of GLX are just a little
bit easier to port to a version of Linux that doesn't use X.

 * iPhone / Palm Pre / misc. hand-held OS applications written to EGL
are just a little bit easier to port to a version of Linux that supports
EGL on X.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAktOEuwACgkQX1gOwKyEAw9BAACgn1qqN8JolfHrBmWjVg5egS1P
zzAAn3btB5FKivfvrkv1sBKAgJ7kFOhI
=S2Jt
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
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@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

On Mon, Jan 11, 2010 at 11:23 PM, Chia-I Wu <olvaffe@...> wrote:
> Hi all,
>
> I just pushed a new EGL driver (egl_g3d) to master.  The new driver is located
> at src/gallium/state_trackers/egl_g3d/.  When built, it provides .a archives
> that are later linked to by src/gallium/winsys/drm/<hw>/egl_g3d/ to provide the
> final EGL drivers loadable by libEGL.

This is good news. I'm glad to see someone picking up EGL support
again. As time permits I'll give the standalone OpenGL ES support a
try.

Currently I'm involved in an audio signal processing project on
embedded hardware.

>
> This new driver supports mixed client APIs (OpenGL, OpenVG, and OpenGL ES).  It
> supports both HW/SW rendering on X11 and supports EGL_MESA_screen_surface on
> bare KMS.  The goal of this driver is to provide _the_ EGL driver for Gallium
> architecture.
>
> I am working on merging opengl-es-v2 branch.  When that is done, I plan to work
> on preparing EGL for easy/wide adoption.  The specific items I have right now
> are
>
> * 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/
> * Non-working
>  * src/egl/drivers/dri/
>  * 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.
>
> 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
>
> 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.
>
> -olv
>

--
Jon Smirl
jonsmirl@...

------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Chia-I Wu-2]

On Tue, Jan 12, 2010 at 12:23 PM, Chia-I Wu <olvaffe@...> wrote:

> I just pushed a new EGL driver (egl_g3d) to master.  The new driver is located
> at src/gallium/state_trackers/egl_g3d/.  When built, it provides .a archives
> that are later linked to by src/gallium/winsys/drm/<hw>/egl_g3d/ to provide the
> final EGL drivers loadable by libEGL.
> This new driver supports mixed client APIs (OpenGL, OpenVG, and OpenGL ES).  It
> supports both HW/SW rendering on X11 and supports EGL_MESA_screen_surface on
> bare KMS.  The goal of this driver is to provide _the_ EGL driver for Gallium
> architecture.
> I am working on merging opengl-es-v2 branch.  When that is done, I plan to work
> on preparing EGL for easy/wide adoption.  The specific items I have right now
> are

I just merged opengl-es-v2 to master.  I will wait for a couple days, in case
there is any build problem or regression, and move on to EGL driver removal.

I will remove src/gallium/state_trackers/egl/ and rename egl_g3d to egl.  A new
egl_x11_swrast based on egl_g3d will replace egl_softpipe.  Most of the others
will be removed as mentioned.

There were some discussions with Jakob about demodriver, egl_dri, and egl_xdri.
I prefer demodriver to be removed, but I couldn't decide for the other two.
Suggestions?

-olv

------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Brian Paul-3]

Chia-I Wu wrote:

> On Tue, Jan 12, 2010 at 12:23 PM, Chia-I Wu <olvaffe@...> wrote:
>> I just pushed a new EGL driver (egl_g3d) to master.  The new driver is located
>> at src/gallium/state_trackers/egl_g3d/.  When built, it provides .a archives
>> that are later linked to by src/gallium/winsys/drm/<hw>/egl_g3d/ to provide the
>> final EGL drivers loadable by libEGL.
>> This new driver supports mixed client APIs (OpenGL, OpenVG, and OpenGL ES).  It
>> supports both HW/SW rendering on X11 and supports EGL_MESA_screen_surface on
>> bare KMS.  The goal of this driver is to provide _the_ EGL driver for Gallium
>> architecture.
>> I am working on merging opengl-es-v2 branch.  When that is done, I plan to work
>> on preparing EGL for easy/wide adoption.  The specific items I have right now
>> are
> I just merged opengl-es-v2 to master.  I will wait for a couple days, in case
> there is any build problem or regression, and move on to EGL driver removal.
>
> I will remove src/gallium/state_trackers/egl/ and rename egl_g3d to egl.  A new
> egl_x11_swrast based on egl_g3d will replace egl_softpipe.  Most of the others
> will be removed as mentioned.
>
> There were some discussions with Jakob about demodriver, egl_dri, and egl_xdri.
> I prefer demodriver to be removed, but I couldn't decide for the other two.
> Suggestions?

I wouldn't mind if demodriver were removed.  It was never fully
maintained.  I haven't looked things over enough yet to determine if
the other two should be kept around.  Let's hang onto them for a bit.

-Brian


------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Chia-I Wu-2]

On Wed, Jan 20, 2010 at 07:55:30AM -0700, Brian Paul wrote:
> >There were some discussions with Jakob about demodriver, egl_dri, and egl_xdri.
> >I prefer demodriver to be removed, but I couldn't decide for the other two.
> >Suggestions?
> I wouldn't mind if demodriver were removed.  It was never fully
> maintained.  I haven't looked things over enough yet to determine if
> the other two should be kept around.  Let's hang onto them for a
> bit.
I want to write a short document for EGL tomorrow, talking about how to
build the library, how to use it, and its design and status.  It will
includes the status of each EGL drivers.

--
Regards,
olv

------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Brian Paul-3]

Chia-I Wu wrote:

> On Wed, Jan 20, 2010 at 07:55:30AM -0700, Brian Paul wrote:
>>> There were some discussions with Jakob about demodriver, egl_dri, and egl_xdri.
>>> I prefer demodriver to be removed, but I couldn't decide for the other two.
>>> Suggestions?
>> I wouldn't mind if demodriver were removed.  It was never fully
>> maintained.  I haven't looked things over enough yet to determine if
>> the other two should be kept around.  Let's hang onto them for a
>> bit.
> I want to write a short document for EGL tomorrow, talking about how to
> build the library, how to use it, and its design and status.  It will
> includes the status of each EGL drivers.

Excellent!

-Brian


------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Chia-I Wu-2]

On Wed, Jan 20, 2010 at 11:41 PM, Brian Paul <brianp@...> wrote:
>> I want to write a short document for EGL tomorrow, talking about how to
>> build the library, how to use it, and its design and status.  It will
>> includes the status of each EGL drivers.
> Excellent!
I've added docs/egl.html.  Please have a look.

Of the items listed, only the driver removal and EGL demo re-organization
remain unfinished.  I will move on to either or both of them Friday.

-olv

------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Chia-I Wu-2]

On Wed, Jan 20, 2010 at 10:36 AM, Chia-I Wu <olvaffe@...> wrote:
> I just merged opengl-es-v2 to master.  I will wait for a couple days, in case
> there is any build problem or regression, and move on to EGL driver removal.
> I will remove src/gallium/state_trackers/egl/ and rename egl_g3d to egl.  A new
> egl_x11_swrast based on egl_g3d will replace egl_softpipe.  Most of the others
> will be removed as mentioned.
I've pushed the changes to remove/rename the EGL drivers.  Please remember to
run autogen.sh before testing the changes.

I tried to be very careful not to break anything, but I don't have many
environments to test the builds.  I will stay up late today and be around :)
If anyone experiences any trouble, please inform me so that I can fix it.

-olv

------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev