Hi folks, I'm new to the DFB dev list and have been working on just such a project, a GLES2/EGL driver for DirectFB 2.0 on the TI omap3430 chipset (specfically using a TI Omap Zoom board and the PowerVR GLES/EGL drivers for development).
Originally I had hoped to use EGLNativePixmapType to implement a shareable resource, like the X11 Pixmap, and construct EGL surfaces from them for hardware accelerated rendering through OpenGL ES 2.x. This would have been similar to the GL/GLX 2D acceleration that Denis implemented. I encountered several problems with this approach: 1) EGLNativePixmapTypes don't really exist without a native surface manager. The support packages for the Zoom only provide opaque implementations of EGLNativePixmapType (they are typedef'ed to void *), and therefore can't be used as sources and targets for Read() and Write() to/from system memory. 2) eglBindTexImage() only allows pbuffer surfaces to be directly bound to textures (in contrast to glXBindTexImage(), which allows GLXPixmaps), so this technique can't be used to lock a pixmap surface for reading as a blit source. 3) It doesn't seem to actually be possible to create an EGL pixmap surface from an EGLNativePixmapType, which isn't surprising given 1). I think it might be possible if software rendering is specified as an attrib to the EGLContext creation, but I wasn't particularly interested in that. So that makes it impossible to bind a native pixmap to the current GLES context for accelerated drawing or blitting when locking a surface for writing. I'm currently negotiating with Imagination Technologies for access to their native surface and window system header files, which may make it possible to actually implement EGLNativePixmapType as a DFB shareable pool surface, but it would result in a proprietary system module. In the meantime, I've developed a GLES/EGL DFB driver that uses GLES textures instead of native pixmaps. Read() and Write() are implemented through glTexSubImage2D() and glReadPixels() by binding texture objects as write targets and attaching them to framebuffer objects as read sources. Similarly, locking for read and write access is done by binding texture objects as blit sources for read and attaching them to framebuffer objects as targets for blit writes. But side from the main problem of the lack of shareable resources for concurrent applications (GLES textures can't be shared across address spaces), I'm getting surprising poor performance. I'm getting only slightly more than 25% of the performance of the fbdev driver on the df_andi demo (~12fps vs. ~40fps)! I haven't debugged this much yet or started on optimization at all, so it's possible that something brain-dead is going on, but it's not encouraging. I suspect that the PowerVR SGX is more optimized for rendering larger meshes with static textures rendered entirely from within vertex buffer objects on the GLES server side -- this doesn't make sense for DFB since we only have 4 positions and 2D texture coordinates for each blit, and they are almost always different for each blit, wiping out the advantage of VBO. For now I've not shipped a patch since it's really not buildable without access to the proprietary PowerVR GLES and EGL libraries. But if you'd like the code for the GLES2 gfxdriver I can tarball it and email it to you, it's pretty small. The EGL system module will require more cleaning up since I've entangled it with prototype calls to a native surface manager in anticipation of getting access to one someday. -- Mark Hood river wu wrote: > hi, nevo > thanks for your reply. > but i will implement this on the TI omap chipset. it use the powervr > 3D accelator. > so my idear is to implement one EGL surface pool which is used to > render the buffer before it render to the > framebuffer for visbility. > because it use egl to create one surface , this surface can use > opengles accelation .after the processing, > the result can be copy to the fbdev screen surface. > > is it possible or is it one way to implment such gfx driver? > > > > > > > Date: Tue, 9 Dec 2008 23:43:13 +0800 > > To: directfb-dev@directfb.org > > From: [EMAIL PROTECTED] > > Subject: Re: [directfb-dev] how to write one 2d accelated gfx driver > based on, EGL/opengles? > > > > > > > Date: Tue, 9 Dec 2008 00:52:35 +0800 > > > From: zhou jiangwei <[EMAIL PROTECTED]> > > > Subject: [directfb-dev] how to write one 2d accelated gfx driver based > > > on EGL/opengles? > > > To: <directfb-dev@directfb.org> > > > Message-ID: <[EMAIL PROTECTED]> > > > Content-Type: text/plain; charset="iso-8859-1" > > > > > > > > > hi, > > > i am a newer to DFB. and want to write one 2D accelated gfx driver > based on EGL/OPENGLES. > > > > > > i refer to the system X11 and want to migrated the same idear in > FBDEV system. > > > > > > just like X11, i want to add one EGL surface pool which is like > GLX_suface pool to cope with the texture combination. > > > but i cannot find the proper simlare cocept with the xpixmap used > in X11. > > > can some one give me some hint on how to implement a 2d hardweare > gfx driver for FBDEV using opengles? > > > > > > thanks. > > > > > Current DirectFBGL is implemented by use of DRI to enable hardware > > acceleration . As to OpenGLES, Mesa project has already defined a > > surface named "EGL_MESA_screen_surface" which you can refer to in mesa > > git tree, which is also relying on DRI for hardware acceleration . If > > you mean to create a native pixmap surface and render into FBDev by use > > of DirectFB,I think it is straightforward, but instead if you wanna > > implement a DirectFB surface as OpenGL ES surface, wow, Im also > > expecting that , I think this is for DirectFB 2.0 :) > > > > > > > > _______________________________________________ > > directfb-dev mailing list > > directfb-dev@directfb.org > > http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev > > > ------------------------------------------------------------------------ > Connect to the next generation of MSN Messenger Get it now! > <http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=wlmailtagline> > > > ------------------------------------------------------------------------ > > _______________________________________________ > directfb-dev mailing list > directfb-dev@directfb.org > http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev _______________________________________________ directfb-dev mailing list directfb-dev@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
