Bug 75390 - Weston's gl-renderer affected by GL_MAX_TEXTURE_SIZE
Summary: Weston's gl-renderer affected by GL_MAX_TEXTURE_SIZE
Alias: None
Product: Wayland
Classification: Unclassified
Component: weston (show other bugs)
Version: unspecified
Hardware: Other All
: medium enhancement
Assignee: Wayland bug list
QA Contact:
Depends on:
Reported: 2014-02-23 04:19 UTC by nerdopolis1
Modified: 2018-06-04 09:33 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Note You need to log in before you can comment on or make changes to this bug.
Description nerdopolis1 2014-02-23 04:19:18 UTC
With older, but still feasable hardware such as a Dell Inspiron E1405 with an integrated Intel card, It's possible for clients to be larger than GL_MAX_TEXTURE_SIZE.

Right now it's possible to size a Weston client larger then GL_MAX_TEXTURE_SIZE, in which the surface becomes invisible when I do so.

I don't know how possible it would be to offer a protocol for the client to tile multiple textures on a single window, or if the server can tile it itself, or offer them a way to not exceed GL_MAX_TEXTURE_SIZE...

Comment 1 Pekka Paalanen 2014-02-24 07:09:54 UTC
My opinion on the matter is still the same as in the email quoting an irc conversation:
- for wl_shm, clients do not need to care, and compositors need to be prepared to deal with huge sizes
- for EGL Wayland platform, rendering such a big size will probably fail anyway, or it should be made to fail if the compositor cannot texture from the render target.

Any crashing or hanging is of course a bug and needs to be fixed. These should be separate bug reports.

I guess the problematic case you are hitting is a software rendered client on a Weston with gl-renderer, right? I'm slightly surprised the hw can do GLESv2 to begin with, but maybe you have a huge desktop over multiple monitors?

I'm not totally sure it must be fixed, but if anyone cares, it would be a change limited inside the gl-renderer, and hence be fairly self-contained work. No protocol work would be involved. A proper fix would be to split the surface into several GL textures. A hack to prevent the window becoming invisible and hence almost unrecoverable would be to just clamp the GL texture size to what the hw can support, ignore the rest of the wl_shm buffer, and use something like GL_CLAMP_TO_EGDE for rendering the surface so it is obvious something is going wrong without misplacing the surface parts that can be rendered fine.

A stupid suggestion for users: use Weston's pixman renderer, it should not have size restrictions.

Having clients tile themselves is likely not worth it, IMO. Using wl_shm is already a fallback that should work, and clients could refuse to resize to larger than what the GL stack supports. I guess this would be another reason to have wl_egl_* size API to be able to report errors on invalid sizes before rendering.

If clients really do want to tile, they can do so with sub-surfaces.
Comment 2 nerdopolis1 2014-02-28 01:38:29 UTC
Yes. I can reach this limit by connecting a 1920x1080 screen, with the laptop screen. Resizing a window vertically causes this limit to be reached.

And I can confirm that with the pixman renderer I can resize a window far beyond the vertical size of both screens, even a qt wayland-egl client. 

This testing laptop I am using I think is from 2006.
Comment 3 Daniel Stone 2018-06-04 09:33:01 UTC
Right, it would be an error for clients to resize themselves larger than GL's declared limits and expect it to work. There's nothing we can do in the compositor or protocol to steer them away from this.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.