Nicolai Hähnle | 6b0d390 | 2017-01-24 13:10:01 +0100 | [diff] [blame] | 1 | Name |
| 2 | |
| 3 | MESA_drm_image_formats |
| 4 | |
| 5 | Name Strings |
| 6 | |
| 7 | EGL_MESA_drm_image_formats |
| 8 | |
| 9 | Contributors |
| 10 | |
| 11 | Nicolai Hähnle <Nicolai.Haehnle@amd.com> |
| 12 | Qiang Yu <Qiang.Yu@amd.com> |
| 13 | |
| 14 | Contact |
| 15 | |
| 16 | Nicolai Hähnle <Nicolai.Haehnle@amd.com> |
| 17 | |
| 18 | Status |
| 19 | |
| 20 | Proposal |
| 21 | |
| 22 | Version |
| 23 | |
| 24 | Version 1, January 26, 2017 |
| 25 | |
| 26 | Number |
| 27 | |
| 28 | EGL Extension #?? |
| 29 | |
| 30 | Dependencies |
| 31 | |
| 32 | This extension requires the EGL_MESA_drm_image extension. |
| 33 | |
| 34 | This extension is written against the wording of EGL_MESA_drm_image |
| 35 | specification. |
| 36 | |
| 37 | Overview |
| 38 | |
| 39 | This extension extends the functionality of EGL_MESA_drm_image by adding |
| 40 | additional formats required by Glamor for use with DRM buffers. |
| 41 | |
| 42 | IP Status |
| 43 | |
| 44 | Open-source; freely implementable. |
| 45 | |
| 46 | New Procedures and Functions |
| 47 | |
| 48 | None |
| 49 | |
| 50 | New Tokens |
| 51 | |
| 52 | Accepted as values for the EGL_IMAGE_FORMAT_MESA attribute: |
| 53 | |
| 54 | EGL_DRM_BUFFER_FORMAT_ARGB2101010_MESA 0x3290 |
| 55 | EGL_DRM_BUFFER_FORMAT_ARGB1555_MESA 0x3291 |
| 56 | EGL_DRM_BUFFER_FORMAT_RGB565_MESA 0x3292 |
| 57 | |
| 58 | Additions to the EGL_MESA_drm_image Specification: |
| 59 | |
| 60 | Remove the sentence "The only format specified ..." from the paragraph |
| 61 | describing eglCreateDRMImageMESA and add the following paragraph: |
| 62 | |
| 63 | The formats specified for use with EGL_DRM_BUFFER_FORMAT_MESA are: |
| 64 | |
| 65 | * EGL_DRM_BUFFER_FORMAT_ARGB32_MESA, where each pixel is a CPU-endian |
| 66 | 32-bit quantity, with alpha in the upper 8 bits, then red, then green, |
| 67 | then blue, |
| 68 | |
| 69 | * EGL_DRM_BUFFER_FORMAT_ARGB2101010_MESA, where each pixel is a CPU- |
| 70 | endian, 32-bit quantity, with alpha in the most significant 2 bits, |
| 71 | followed by 10 bits each for red, green, and blue, |
| 72 | |
| 73 | * EGL_DRM_BUFFER_FORMAT_ARGB1555_MESA, where each pixel is a CPU-endian |
| 74 | 16-bit quantity, with alpha in the most significant bit, followed by |
| 75 | 5 bits each for red, green, and blue, and |
| 76 | |
| 77 | * EGL_DRM_BUFFER_FORMAT_RGB565_MESA, where each pixel is a CPU-endian |
| 78 | 16-bit quantity, with red in the 5 most significant bits, followed by |
| 79 | 6 bits of green and 5 bits of blue. |
| 80 | |
| 81 | Issues |
| 82 | |
| 83 | 1. Should we expose the full set of channel permutations for the formats, |
| 84 | e.g. ABGR2101010, RGBA1010102, and BGRA1010102 in addition to |
| 85 | ARGB2101010? |
| 86 | |
| 87 | RESOLVED: No. |
| 88 | |
| 89 | DISCUSSION: The original extension sets a precedent of only exposing one |
| 90 | of the possible permutations of 8-bit channel formats. It is also not |
| 91 | clear where the additional permutations would be used. For example, |
| 92 | Glamor has a fixed mapping from pixmap/screen depth to format that |
| 93 | doesn't allow for the other permutations. |
| 94 | |
| 95 | Revision History |
| 96 | |
| 97 | Version 1, January, 2017 |
| 98 | Initial draft (Nicolai Hähnle) |