Re: [Mesa3d-dev] Plans for EGL
On Wed, Jan 20, 2010 at 10:36 AM, Chia-I Wu olva...@gmail.com 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Plans for EGL
Chia-I Wu wrote: On Tue, Jan 12, 2010 at 12:23 PM, Chia-I Wu olva...@gmail.com 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Plans for EGL
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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Plans for EGL
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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Plans for EGL
On Tue, Jan 12, 2010 at 12:23 PM, Chia-I Wu olva...@gmail.com 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Plans for EGL
On Mon, Jan 11, 2010 at 11:23 PM, Chia-I Wu olva...@gmail.com 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 jonsm...@gmail.com -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Plans for EGL
-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 ja...@vmware.com 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Plans for EGL
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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Plans for EGL
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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Plans for EGL
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
Re: [Mesa3d-dev] Plans for EGL
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. * 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Plans for EGL
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
Re: [Mesa3d-dev] Plans for EGL
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
[Mesa3d-dev] Plans for EGL
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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
