On 11/22/2016 08:39 AM, Xu, Randy wrote:
Hi ,Tapani
With this pbuffer patch, only three EGL dEQP failure remained on Android
platform , they are under investigation now
dEQP-EGL.functional.image.create#gles2_renderbuffer_depth16_depth_buffer fail due to
"=== with config {glformat=rgba8888d24s8ms0,rotation=unspecified,surfacetype=window}
==="
dEQP-EGL.functional.image.modify#renderbuffer_depth16_renderbuffer_clear_depth fail due
to "=== with config
{glformat=rgba8888d24s8ms0,rotation=unspecified,surfacetype=window} ==="
dEQP-EGL.functional.image.render_multiple_contexts#gles2_renderbuffer_depth16_depth_buffer
fail due to "=== with config
{glformat=rgba8888d24s8ms0,rotation=unspecified,surfacetype=window} ==="
The multithread cases can pass on Android.
Not for me
Thanks, Randy -----Original Message----- From: Palli, Tapani Sent: Tuesday, November 22, 2016 2:32 PM To: Tomasz Figa <tf...@chromium.org> Cc: Long, Zhifang <zhifang.l...@intel.com>; Liu, Zhiquan <zhiquan....@intel.com>; Xu, Randy <randy...@intel.com>; Emil Velikov <emil.l.veli...@gmail.com>; Kondapally, Kalyan <kalyan.kondapa...@intel.com>; ML mesa-dev <mesa-dev@lists.freedesktop.org> Subject: Re: [Mesa-dev] EGL/android: pbuffer implementation. 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.pa...@intel.com> wrote:On 11/21/2016 04:15 PM, Emil Velikov wrote:On 21 November 2016 at 07:23, Tomasz Figa <tf...@chromium.org> wrote:Hi, On Wed, Nov 16, 2016 at 11:11 AM, Liu Zhiquan <zhiquan....@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@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
