[Mesa-dev] [PATCH 1/2] egl/dri2: implement platform_null (v2).

[Chad Versace]

On Wed 08 Apr 2015, Frank Henigman wrote:
>On Wed, Apr 8, 2015 at 1:28 AM, Chad Versace <chad.versace at intel.com> wrote:
>> On Tue 07 Apr 2015, Kristian Høgsberg wrote:
>>>
>>> On Tue, Apr 7, 2015 at 6:46 PM, Frank Henigman <fjhenigman at google.com>
>>> wrote:
>>>>
>>>> The name "surfaceless" suits me.
>>>>
>>>> Does this platform need to provide a hint to the user about buffer
>>>> format?
>>>> Platform drm does this via the EGL_NATIVE_VISUAL_ID query of
>>>> eglGetConfigAttrib(), returning a gbm format value.  Unless we do the
>>>> same or similar here, how does the user robustly find the right format
>>>> for allocating buffers?
>>>
>>>
>>> GBM provides
>>>
>>> int gbm_device_is_format_supported(struct gbm_device *gbm, uint32_t
>>> format, uint32_t usage);
>>>
>>> and you can use that to find a format that works with
>>> GBM_BO_USE_RENDERING.
>>
>>
>> I don't think it makes sense to use EGL_NATIVE_VISUAL_ID here, so
>> Kristian's suggestion sounds good to me. The EGL_NATIVE_VISUAL_ID, of
>> course, has the same type as the native format of
>> EGLNativeWindowSurface. But this platform has no EGLNativeWindowSurface,
>> so therefore it has no EGL_NATIVE_VISUAL_ID.
>>
>> On first thought, it seems like re-purposing EGL_NATIVE_VISUAL_ID for
>> this platform setting it to a gbm format, might be a good idea. But
>> ultimately I think it's a bad idea because the platform isn't tied to
>> gbm in any way. Today we use gbm_bo_create() to create the dma_buf
>> storage, but tomorrow we might use a different API that doesn't
>> understand gbm formats.
>
>That's why I said "or similar."  It doesn't have to be a gbm format,
>it could be a fourcc or something that the user translates to whatever
>api they're using.

>Am I correct in thinking the alternative is to sift through all the
>gbm formats (if using gbm) to find one which satisfies
>gbm_device_is_format_supported() and has the right number of alpha and
>color bits?  So eglChooseConfig() does nothing for us anymore?  Will
>we in fact have to be careful to find an egl config that exactly
>matches the gbm format we choose?  Or should I not be calling
>eglChooseConfig() at all?  I see an extension
>EGL_MESA_configless_context...

Internally, this platform never uses the EGLConfig's color attributes.
So, two EGLConfigs which differ only in color attributes are effectively
identical. (It's possible that this platform never uses *any* of the
EGLConfig's attributes, but I'm not 100% sure).

Therefore it's not the EGLConfig that determines which gbm formats are
legal. Instead, it's the implementation details of the EGLImage code in
libEGL and i965_dri.so. So searching for a gbm format that matches the
EGLConfig is pointless. Instead, you need to search for gbm formats
supported by the gbm/KMS/EGLImage/GLRenderbuffer/GLTexture dance that the
gbm_bo will be used for. And I'm aware of no API to query for
those formats, unless you consider git-grep to be an API ;)

If I understand correctly, the user never needs to choose an EGLConfig
when using this platform.  See lines 291 to 295 of my Chrome OS patch
[1] that ported dEQP to this platform.

[1] https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/649becd1761d377d9714af58f55ecc2b0d3821a2/media-gfx/deqp/files/targets-drm-Add-new-target-to-support-Chrome-OS-s-EGL-null-platform.patch

>Surfaceless and configless - next step is egl-less.  (^:

EGL-less is on its way with Vulkan and its cousins :)