[Mesa-dev] [PATCH 01/10] egl/android: Set EGL_MAX_PBUFFER_WIDTH and EGL_MAX_PBUFFER_HEIGHT

Emil Velikov emil.l.velikov at gmail.com
Fri Jul 15 19:29:44 UTC 2016


On 15 July 2016 at 18:57, Tomasz Figa <tfiga at chromium.org> wrote:
> [Adding Haixia to the thread.]
>
> On Sat, Jul 16, 2016 at 2:52 AM, Eric Anholt <eric at anholt.net> wrote:
>> Tomasz Figa <tfiga at chromium.org> writes:
>>
>>> From: Haixia Shi <hshi at 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 <tfiga at 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


More information about the mesa-dev mailing list