By way of information, Intel has dropped support for its DirectFB OpenGL ES graphics driver as of the PR16 revision of our Intel CE SDK (June 2010). The rationale behind this decision was primarily based on the development experience of our customers and the usage complexities from the deferred mode rendering style it required with the SGX's tile-based architecture which didn’t mesh nicely with how most DirectFB applications are commonly implemented. As of PR16 our DirectFB graphics driver now only uses a proprietary API that's designed and optimized for traditional immediate-mode rendering using the SGX 3D unit. Our customers have been achieving good performance with this library.
We do still support OpenGL ES outside of DirectFB which offers a more flexible deferred rendering approach and optimizations, as well as its integration with DirectFB via the IDirectFBGL interface. -----Original Message----- From: directfb-dev-boun...@directfb.org [mailto:directfb-dev-boun...@directfb.org] On Behalf Of David Corvoysier Sent: Monday, December 06, 2010 4:42 AM To: directfb-dev@directfb.org Subject: Re: [directfb-dev] WebKit/DFB on top of EGL/GLES gfxdriver > Concerning the GLES blitter implementation, you might want to have a > look at the intel CE platforms. They provides a modified directfb > version which allows you to select between cpu(probably SSEE/MMX > implementation)/gpu(GL implementation) acceleration for the directfb > API. This is indeed an Intel CE target I want to address, and yes they have a dual-mode directfb driver. I couldn't manage to obtain good performances with the gpu accelerated mode however: I don't have the source code for their driver, but I think it may be due to the fact that they force the gpu to flush output to pixmaps before it is processed by directfb (this is exactly what I want to avoid by using an EGL surface pool). > The EGL API is always bound to an underlaying "windowing system", which > may be very basic (some vendor provides a framebuffer as windowing > system, so you just have give the buffer's pointer to EGL...). I > seriously doubt you will be able to reach a common code/windowing-system > on this, usually chipset vendors deliver a bunch of .so libs as OpenGL > library with a bunch of headers and can't change the underlaying > allocation API which is often proprietary... > In a perfect world the EGL API would sit on top of DirectFB, so you > would be able to "cast" already existing buffers into GL textures. Yes, in my case, the EGL API relies on Intel GDL. _______________________________________________ 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
