summaryrefslogtreecommitdiff
path: root/docs/specs/MESA_image_dma_buf_export.txt
blob: cc9497e437d449a56abcfe219ef15dde36651101 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
Name

    MESA_image_dma_buf_export

Name Strings

    EGL_MESA_image_dma_buf_export

Contributors

    Dave Airlie

Contact

    Dave Airlie (airlied 'at' redhat 'dot' com)

Status

    Complete, shipping.

Version

    Version 3, May 5, 2015

Number

    EGL Extension #87

Dependencies

    Requires EGL 1.4 or later.  This extension is written against the
    wording of the EGL 1.4 specification.

    EGL_KHR_base_image is required.

    The EGL implementation must be running on a Linux kernel supporting the
    dma_buf buffer sharing mechanism.

Overview

    This extension provides entry points for integrating EGLImage with the
    dma-buf infrastructure.  The extension allows creating a Linux dma_buf
    file descriptor or multiple file descriptors, in the case of multi-plane
    YUV image, from an EGLImage.

    It is designed to provide the complementary functionality to
    EGL_EXT_image_dma_buf_import.

IP Status

    Open-source; freely implementable.

New Types

    This extension uses the 64-bit unsigned integer type EGLuint64KHR
    first introduced by the EGL_KHR_stream extension, but does not
    depend on that extension. The typedef may be reproduced separately
    for this extension, if not already present in eglext.h.

    typedef khronos_uint64_t EGLuint64KHR;

New Procedures and Functions

    EGLBoolean eglExportDMABUFImageQueryMESA(EGLDisplay dpy,
                                  EGLImageKHR image,
				  int *fourcc,
				  int *num_planes,
				  EGLuint64KHR *modifiers);

    EGLBoolean eglExportDMABUFImageMESA(EGLDisplay dpy,
                                        EGLImageKHR image,
                                        int *fds,
				        EGLint *strides,
					EGLint *offsets);

New Tokens

    None


Additions to the EGL 1.4 Specification:

    To mirror the import extension, this extension attempts to return
    enough information to enable an exported dma-buf to be imported
    via eglCreateImageKHR and EGL_LINUX_DMA_BUF_EXT token.

    Retrieving the information is a two step process, so two APIs
    are required.

    The first entrypoint
       EGLBoolean eglExportDMABUFImageQueryMESA(EGLDisplay dpy,
                                  EGLImageKHR image,
				  int *fourcc,
				  int *num_planes,
				  EGLuint64KHR *modifiers);

    is used to retrieve the pixel format of the buffer, as specified by
    drm_fourcc.h, the number of planes in the image and the Linux
    drm modifiers. <fourcc>, <num_planes> and <modifiers> may be NULL,
    in which case no value is retrieved.

    The second entrypoint retrieves the dma_buf file descriptors,
    strides and offsets for the image. The caller should pass
    arrays sized according to the num_planes values retrieved previously.
    Passing arrays of the wrong size will have undefined results.
    If the number of fds is less than the number of planes, then
    subsequent fd slots should contain -1.

        EGLBoolean eglExportDMABUFImageMESA(EGLDisplay dpy,
                                         EGLImageKHR image,
					 int *fds,
                                         EGLint *strides,
                                         EGLint *offsets);

    <fds>, <strides>, <offsets> can be NULL if the infomatation isn't
    required by the caller.

Issues

1. Should the API look more like an attribute getting API?

ANSWER: No, from a user interface pov, having to iterate across calling
the API up to 12 times using attribs seems like the wrong solution.

2. Should the API take a plane and just get the fd/stride/offset for that
   plane?

ANSWER: UNKNOWN,this might be just as valid an API.

3. Does ownership of the file descriptor remain with the app?

ANSWER: Yes, the app is responsible for closing any fds retrieved.

4. If number of planes and number of fds differ what should we do?

ANSWER: Return -1 for the secondary slots, as this avoids having
to dup the fd extra times to make the interface sane.

Revision History

    Version 3, May, 2015
        Just use the KHR 64-bit type.
    Version 2, March, 2015
        Add a query interface (Dave Airlie)
    Version 1, June 3, 2014
        Initial draft (Dave Airlie)