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

[Tapani Pälli]

On 11/22/2016 08:08 AM, Tapani Pälli wrote:
>
>
> 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.

I did run all EGL tests now and all of the above 
'get_current_context.*pbuffer' tests pass (some formats are skipped 
though). I don't have specifically BSW and BDW right now though, this 
was run on Joule (BXT).

With my run I got 7 failing EGL tests:

dEQP-EGL.functional.image.modify.tex_rgb5_a1_tex_subimage_rgba8
dEQP-EGL.functional.image.render_multiple_contexts.gles2_renderbuffer_depth16_depth_buffer
dEQP-EGL.functional.multithread.window
dEQP-EGL.functional.multithread.pbuffer_window
dEQP-EGL.functional.multithread.window_context
dEQP-EGL.functional.multithread.pbuffer_window_context
dEQP-EGL.performance.make_current.multi_surface.context_windows_10

(1999 passing, 1616 skipped)

Not sure if multithread ones ever passed. On desktop many of them fail 
because dEQP does not call XInitThreads().


>> 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
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev