On Fri, 2018-06-01 at 09:39 +0100, Brendan King wrote:
> The IMG patch Eric was referring to was to dEQP. I submitted bug
> reports to Google and Khronos:
>
> https://issuetracker.google.com/issues/64059452
>
> https://gitlab.khronos.org/Tracker/vk-gl-cts/issues/594
>
> I've attached the patch to this email. The problem is that the dEQP
> *resize.surface_size* tests check the native window
> dimensions after creating the window, without having called
> eglSwapBuffers, and hence get back a width and height of zero,
> resulting in the tests failing.
Thanks for the reference.
My question then: is mandatory to call eglSwapBuffers() to ensure
wl_egl_window_get_attached_size() returns the right window size? Because I
found nothing related about this. If it is mandatory, then calling
eglSwapBuffers() in the test should fix the problem (including the patch I've
summited with Daniel's changes).
J.A.
>
>
> Here is the patch description:
>
>
> The Wayland version of deqp-egl calls wl_egl_window_get_attached_sizeto
> get window dimensions. On Mesa at least, this initially returns awidth and
> height of zero for a new window. The surface resize testscheck the initial
> surface size, and fail as a result.
> Add a new native window capability,
> CAPABILITY_INITIAL_SURFACE_SIZE_QUERY,which is only set if the initial window
> size can be queried aftercreation. If native windows don't have the
> capability, return therequired size from getNativeSurfaceSize, rather than
> the size obtainedfrom the window system.
> A parameter has been added to getNativeSurfaceSize, to indicate ifthe initial
> size of a surface is being queried.
> Brendan.
>
> On 01/06/18 09:12, Juan A. Suarez
> Romero wrote:
>
>
>
> > On Thu, 2018-05-31 at 16:57 +0100, Daniel Stone wrote:
> >
> >
> > > Hi Juan,Thanks for picking this up!
> > > On 31 May 2018 at 16:44, Juan A. Suarez Romero <jasua...@igalia.com>
> > > wrote:
> > >
> > >
> > > > @@ -255,6 +257,12 @@ dri2_wl_create_window_surface(_EGLDriver
> > > > *drv, _EGLDisplay *disp, goto cleanup_surf; }
> > > > + dri2_surf->base.Width = window->width;+ dri2_surf->base.Height =
> > > > window->height;++ window->attached_width = dri2_surf->base.Width;+
> > > > window->attached_height = dri2_surf->base.Height;
> > > >
> > > >
> > >
> > > We should definitely not initialise attached_{width,height}
> > > here,because no buffer has ever been attached.
> > >
> > >
> > >
> > > > @@ -574,8 +582,8 @@ update_buffers(struct dri2_egl_surface
> > > > *dri2_surf) struct dri2_egl_display *dri2_dpy =
> > > > dri2_egl_display(dri2_surf->base.Resource.Display);
> > > > - if (dri2_surf->base.Width != dri2_surf->wl_win->width ||-
> > > > dri2_surf->base.Height != dri2_surf->wl_win->height) {+ if
> > > > (dri2_surf->wl_win->attached_width != dri2_surf->wl_win->width ||+
> > > > dri2_surf->wl_win->attached_height != dri2_surf->wl_win->height) {
> > > > dri2_wl_release_buffers(dri2_surf);
> > > > @@ -1629,8 +1637,8 @@ swrast_update_buffers(struct dri2_egl_surface
> > > > *dri2_surf) if (dri2_surf->back) return 0;
> > > > - if (dri2_surf->base.Width != dri2_surf->wl_win->width ||-
> > > > dri2_surf->base.Height != dri2_surf->wl_win->height) {+ if
> > > > (dri2_surf->wl_win->attached_width != dri2_surf->wl_win->width ||+
> > > > dri2_surf->wl_win->attached_height != dri2_surf->wl_win->height) {
> > > >
> > > >
> > >
> > > Not initialising attached_{width,height} should not cause any
> > > problemswith these checks. By definition there cannot have been any
> > > buffersallocated or attached between creation and the first draw call,
> > > sothere are no old buffers to release.
> > >
> > >
> >
> > Eric explained pretty well the reason to touch
> > attached_{width,height};otherwise dEQP-EGL.functional.resize.surface_size.*
> > tests continue to fail.
> >
> > J.A.
> >
> >
> >
> >
> > > So with that initialisation removed, this is (assuming dEQP still
> > > passes):Reviewed-by: Daniel Stone <dani...@collabora.com>
> > > Cheers,Daniel
> > >
> > >
> > >
> >
> > _______________________________________________mesa-dev mailing
> > listmesa-dev@lists.freedesktop.orghttps://lists.freedesktop.org/mailman/listinfo/mesa-dev
> >
> >
>
>
>
>
> _______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
