On 15 July 2016 at 18:57, Tomasz Figa <tf...@chromium.org> wrote: > [Adding Haixia to the thread.] > > On Sat, Jul 16, 2016 at 2:52 AM, Eric Anholt <e...@anholt.net> wrote: >> Tomasz Figa <tf...@chromium.org> writes: >> >>> From: Haixia Shi <h...@chromium.org> >>> >>> Set config attributes EGL_MAX_PBUFFER_WIDTH and EGL_MAX_PBUFFER_HEIGHT to >>> hard-coded non-zero values. These two attributes are required on Android. >>> >>> Signed-off-by: Tomasz Figa <tf...@chromium.org> >>> --- >>> src/egl/drivers/dri2/platform_android.c | 2 ++ >>> 1 file changed, 2 insertions(+) >>> >>> diff --git a/src/egl/drivers/dri2/platform_android.c >>> b/src/egl/drivers/dri2/platform_android.c >>> index b33f4e8..f42febc 100644 >>> --- a/src/egl/drivers/dri2/platform_android.c >>> +++ b/src/egl/drivers/dri2/platform_android.c >>> @@ -655,6 +655,8 @@ droid_add_configs_for_visuals(_EGLDriver *drv, >>> _EGLDisplay *dpy) >>> EGL_NATIVE_VISUAL_TYPE, 0, >>> EGL_FRAMEBUFFER_TARGET_ANDROID, EGL_TRUE, >>> EGL_RECORDABLE_ANDROID, EGL_TRUE, >>> + EGL_MAX_PBUFFER_WIDTH, 4096, >>> + EGL_MAX_PBUFFER_HEIGHT, 4096, >>> EGL_NONE >> >> It seems weird to me to pick a plausible value that hardware might have, >> without actually asking the hardware for the value. Could we use some >> MAX_INT-type value to make it obvious that we're just lying and leaving >> it up to buffer creation time to error out? > > If I remember correctly, there are dEQP tests which attempt to use > pbuffers bigger and bigger until reaching the limits and checking if > they work properly. Haixia, what was the story behind hardcoding these > values? > > I suppose the proper way would be to query the driver indeed... > IIRC we had a similar case, where when requesting the EGL_LARGEST_PBUFFER we were capping to the width/height 4k in _eglInitSurface. The reason behind the hardcoded (gross?) workaround was that one cannot query the sane limits, at least from the xlib/xcb side of EGL. See commit 582ae91e3a615afdecbb8c3dc98d1397ebee1cd6 for more.
Perhaps the dEQP tests should set EGL_LARGEST_PBUFFER ? Alternatively I'm wondering if we cannot have a common path for this/these workarounds ? Thanks Emil _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
