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. -- Best regards, Denis Oliver Kropp .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" _______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
