Dri2 buffer format

[Jerome Glisse]

On Wed, Nov 10, 2010 at 9:49 AM, Chia-I Wu <olvaffe at gmail.com> wrote:
> On Wed, Nov 10, 2010 at 10:22 PM, Jerome Glisse <j.glisse at gmail.com> wrote:
>> On Tue, Nov 9, 2010 at 9:11 PM, Russell Shaw <rjshaw at netspace.net.au> wrote:
>>> On 10/11/10 12:47, Kristian Høgsberg wrote:
>>>>
>>>> On Tue, Nov 9, 2010 at 8:43 PM, Russell Shaw<rjshaw at netspace.net.au>
>>>>  wrote:
>>>>>
>>>>> On 10/11/10 12:32, Jesse Barnes wrote:
>>>
>>> ...
>>>
>>>>>>>> DRI2 is not mean to be use by end user application, it's only use by
>>>>>>>> Xorg to comunicate with library such as opengl that want to provide
>>>>>>>> direct rendering to X pixmap/window.
>>>>>>>
>>>>>>> Ok. How do i plot a pixel in Wayland? I'm not using
>>>>>>> gtk/qt/OpenGL/OpenVG
>>>>>>> etc.
>>>>>>
>>>>>> Allocate an shm buffer based on an mmap you've done in your client.
>>>>>> Then you can draw to it and notify wayland of the damage.
>>>>>
>>>>> Ok. I'm already using shm buffers in X. Is there example code in wayland
>>>>> of getting the shm pixel format? (i couldn't see one last time i looked)
>>>>
>>>> Look at the smoke.c example.
>>>
>>> Hi,
>>> smoke.c uses cairo http://cairographics.org/
>>> I don't want cairo.
>>>
>>> Please could i have that one bit of code for the pixel format?:)
>>
>> Wayland is not intended to work that way, GPU might pack pixel in strange
>> format (especialy newer GPU where sometimes you can only use tiled
>> buffer). The format of the buffer that GPU can understand would thus vary
>> from one GPU to another, making any application which try to directly
>> access pixel non portable at all.
>>
>> The format of the underlying buffer should thus only be understable
>> by the associated GPU driver (wayland use EGL driver and in your
>> app you can use another api as long as it has a driver for the GPU
>> but i could only encourage anyone to stick to api such as EGL or
>> cairo GL as this have proper driver for all 3 big GPU amd,intel &nividia)
> Though I think it is a good idea to be able to lock/unlock a buffer
> for CPU access.  It is what libkms does.  But in light of
> EGL_MESA_drm_image, it could be EGL_MESA_drm_image_cpu:
>
>  eglLockDRMImageMESA - maps an image for CPU access
>  eglUnlockDRMImageMESA - unmap and flush changes
>> Cheers,
>> Jerome

My point was that in some GPU we might never have linear pixel
packing, it might always be tiled. Thought i expect  here is a way to
until them using the GPU and retile them. Also the stride|pitch might
not be evident.

Of course we can hide that in EGL driver and driver might allocate
temporary memory that will be easily accessible from CPU (linear and
maybe return the pitch) and on unlock will update the GPU copy
properly. That would still mean that app need to start an EGL context
and allocate their buffer using EGL even thought they don't want to
use EGL. But i am fine with that :)

Cheers,
Jerome