On 05/12/10 17:55, Lionel Landwerlin wrote: > Le dimanche 05 décembre 2010 à 17:20 +0100, David Corvoysier a écrit : >> Hi, >> >> I am new to DirectFB hacking though I have been using it for a few years >> as a graphical backend for embedded targets. >> >> I have an existing WebKit port that runs on top of either directfb (3 >> blitter-based embedded targets) or open gles (1 GPU-based embedded >> target). The port itself is a fork of OWB (Orygin Web Browser), and uses >> extensively the OWB Browser Abstraction Layer to "hide" target specifics. >> >> Since owb has now gone closed source, I am looking for a replacement, >> and WebKitDFB seems the perfect candidate for my three "traditional" >> directfb targets, but I would like also to support the fourth (For >> information, there is also a directfb driver that emulates a blitter for >> that target, but it is really slow and buggy). >> >> Looking at DirectFB internals, I came up with the idea of developing a >> dedicated gfxdriver that: >> 1 - provides an EGL surface pool to override DirectFB core surface pool >> (this part has unfortunately to be target-specific), >> 2 - performs all 2D operations on these internal surfaces through Open >> GLES (this is generic).
I have DirectFB acceleration on top of OpenGL ES 1.1 and also 2.0 (2 gfxdrivers). There's also a pure egl based system module and a system module that does mixed X11 and egl for nVidia Tegra. I will publish the code shortly. It's been already quite a while this exists *sigh* >> Now, I am not 100% sure this is actually feasible, especially the first >> part (though I have seen on this list that people have tried something >> similar on the TI OMAP 3). What do you think ? The pure egl based system module just creates a fullscreeen egl window surface and uses frame buffer objects for the surfaces. >> This done, another issue would be to have access to the underlying EGL >> surfaces to be able to do some 3D rendering directly into them (the main >> use-case is WebKit Canvas3D, ie WebGL). Looking at the IDirectFBGL >> interface it may do the trick, but I am not sure ... A few weeks ago I started a new interface called IDirectFBGL2 which allows you to create GL contexts independent of surfaces. Then you can call IDirectFBGL2Context::Bind( draw_surface, read_surface ). >> Anyway, advices from people more experienced than I am with DirectFB >> internals would be much appreciated ! >> > > Hello David, > > Concerning the surface pool to override, I did something like that a few > months ago. I added a "null" system into directfb which always returns > that it isn't possible to allocate a surface (look at the attached > patch, it probably do not apply "as it", but you've got the idea). That > forces the core of directfb to look at others available pools. Then you > have to write a gfxdriver that provides it's own surface allocator (the > davinci own is a good example) and each time an application needs a new > surface/window, the driver's allocator will be called. > You can probably reach the same behavior with framebuffer's size close > to 0. > > 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. The GL ES 2.0 based accelerated driver has different shaders for the most commonly used blitting and drawing flags. > 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. True. I have a basic egl API implementation on top of IDirectFBGL2 with the egl based gears example working (only egl and gl API used, no DirectFB). eglCreateWindowSurface with IDirectFBWindow and eglCreatePixmapSurface with IDirectFBSurface are working. -- Best regards, Denis Oliver Kropp .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" _______________________________________________ directfb-dev mailing list directfb-dev@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
