[Mesa-dev] EGL/android: pbuffer implementation.

[Tapani Pälli]

On 11/22/2016 08:02 AM, Tomasz Figa wrote:
> On Tue, Nov 22, 2016 at 2:44 PM, Tapani Pälli <tapani.palli at intel.com> wrote:
>>
>>
>> On 11/21/2016 04:15 PM, Emil Velikov wrote:
>>>
>>> On 21 November 2016 at 07:23, Tomasz Figa <tfiga at chromium.org> wrote:
>>>>
>>>> Hi,
>>>>
>>>> On Wed, Nov 16, 2016 at 11:11 AM, Liu Zhiquan <zhiquan.liu at intel.com>
>>>> wrote:
>>>>> @@ -775,14 +837,6 @@ droid_add_configs_for_visuals(_EGLDriver *drv,
>>>>> _EGLDisplay *dpy)
>>>>>     for (i = 0; dri2_dpy->driver_configs[i]; i++) {
>>>>>        const EGLint surface_type = EGL_WINDOW_BIT | EGL_PBUFFER_BIT;
>>>>>        struct dri2_egl_config *dri2_conf;
>>>>> -      unsigned int double_buffered = 0;
>>>>> -
>>>>> -      dri2_dpy->core->getConfigAttrib(dri2_dpy->driver_configs[i],
>>>>> -         __DRI_ATTRIB_DOUBLE_BUFFER, &double_buffered);
>>>>> -
>>>>> -      /* support only double buffered configs */
>>>>> -      if (!double_buffered)
>>>>> -         continue;
>>>>
>>>>
>>>> Does it really just work like this? Last time I checked the list of
>>>> configs generated after such change it contained single-buffered-only
>>>> configs with window surface bit set and double-buffered-only configs
>>>> with pbuffer bit set, both of which are invalid. Moreover, this caused
>>>> some dEQP tests to fail. How was this patch tested?
>>>>
>>> Afaict the patch has (should have?) gone through the Intel CI,
>>> although I'm not sure if the latter builds/runs Android/ARC.
>>
>>
>> It did go through CI but it does not run any Android/ARC tests. AFAIK
>> Zhiquan did run pbuffer related tests and reported them passing on Android.
>> Which dEQP tests were regressed?
>
> The tests I'm concerned with are all
> dEQP-EGL.functional.query_context.get_current_context.*_pbuffer tests.
> In my testing on BSW and BDW, a change identical to the part quoted
> above made eglGetConfigs() return double buffered configs for
> pbuffers, which made the mentioned tests fail because of invalid
> config at surface creation time (or SIGSEGV, before my NULL pointer
> fix - 94282b6dd0 egl/android: Check return value of
> dri2_get_dri_config()).

OK thanks, we will run these tests today and see if something got broken.

> Note that I haven't tested exactly this patch, just a similar change,
> identical in terms of the quoted part above. It is also possible that
> something changed in other part of the EGL stack, which fixed the
> problem. I will retest current Mesa master a bit later.
>
> Best regards,
> Tomasz
>

// Tapani