[Mesa-dev] Fwd: Re: [directfb-dev] First results of Mesa/DRM based DirectFB on i915 (GLES2.0 acceleration)

[Kristian Høgsberg]

On Sun, Mar 13, 2011 at 3:35 AM, Denis Oliver Kropp <dok at directfb.org> wrote:
> On 13/03/11 08:29, Dave Airlie wrote:
>> On Sun, Mar 13, 2011 at 5:15 PM, Denis Oliver Kropp <dok at directfb.org> wrote:
>>> On 13/03/11 08:09, Dave Airlie wrote:
>>>> On Sun, Mar 13, 2011 at 5:02 PM, Denis Oliver Kropp <dok at directfb.org> 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