[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... Best regards, Tomasz _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
