On Sun, Mar 13, 2011 at 3:35 AM, Denis Oliver Kropp <[email protected]> wrote: > On 13/03/11 08:29, Dave Airlie wrote: >> On Sun, Mar 13, 2011 at 5:15 PM, Denis Oliver Kropp <[email protected]> >> wrote: >>> On 13/03/11 08:09, Dave Airlie wrote: >>>> On Sun, Mar 13, 2011 at 5:02 PM, Denis Oliver Kropp <[email protected]> >>>> wrote: >>>>> Hi, >>>>> >>>>> thanks to all of you who contributed to Mesa/DRM/KMS. >>>>> >>>>> Following are some benchmark results of the new DirectFB on Mesa port. >>>>> >>>>> The code is checked into git.directfb.org now. >>>>> >>>>> >>>>> I also think I know how to map the buffers now (see my previous mails), >>>>> using intel specific ioctl (as in libkms bo_map) with the handle returned >>>>> by >>>>> eglExportDRMImageMESA. >>>>> >>>> >>>> I don't know the right answer, but that isn't it. You really don't >>>> want to be using libkms at all >>>> for that use case I don't think. libkms buffers aren't meant to be >>>> used in acceleration situations. >>> >>> Right, I'm not going to use libkms. >>> >>> I'll stay with the Mesa based allocation, but thought I can map the bo >>> similar to how it is done in libkms' bo_map implementation for intel: >> >> You should probably use libdrm_intel I'm not following the >> architecture of what you are doing though, >> if directfb has a loadable per-gpu driver that isn't mesa etc. > > At the moment there's one module for all Mesa specific code, > including whole DRM Mode setup and DRM Image creation, as well > as wrapping into render buffer and texture objects. > > Then there's a module providing the acceleration of the 2D API > of DirectFB which uses GLES 2.0 calls. > > There's no vendor specific code so far, but it seems we need that.
The only missing piece is mapping bos? What do you need that for? Would something like EGL_lock_surface2 work? Kristian _______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
