Wayland and GL_MAX_TEXTURE_SIZE

[nerdopolis]

Hi.

So a discussion that was on the IRC earlier was about how GL_MAX_TEXTURE_SIZE can prevent larger surfaces or windows from appearing. This is a snip of the IRC.

I decided that it might be a good idea to bring the discussion to the mailing list?

[16:55:04] <nerdopolis> So when I specify a --width of 5000 pixels to Wayland running nested under Wayland in DRM or X11 mode it gets garbled...
[23:42:02] <soreau> nerdopolis: You might be exceeding the mts for your card. Check the output of 'glxinfo -l|grep -i max_texture_size'
[23:46:57] <nerdopolis> soreau: hang on... It's not on my image... I'll need to install mesa utilites
[23:51:42] <nerdopolis> soreau: it comes to 2048
[23:53:08] <soreau> nerdopolis: That number (squared) is the maximum texture size your gpu hardware is capable of
[23:53:27] <nerdopolis> I have heard about that limit before, and I heard something once about tiling textures... if that was ever done, would that be a weston thing or a wayland thing?
[23:56:57] <soreau> Maybe the compositor could copy portions of the texture into surfaces and stitch those together, I'm not sure how that works exactly
[23:58:12] <soreau> There was some form of implementation in compiz 0.9's copytex plugin but didn't work 100% from my tests
[00:03:40] <nerdopolis> soreau: do you think that's something worth looking into before the protocol is finalized? 
[00:26:41] <soreau> nerdopolis: I'm thinking it can happen in the compositor. For now, there should probably be some warning message at least
[00:27:26] <soreau> nerdopolis: What happens when you resize a client larger than mts btw?
[03:12:09] <pq> nerdopolis, soreau, yeah, dealing with oversized surfaces is an interesting question. For shm surfaces, it can be dealt with in Weston alone, but (EGL) hw buffers is the difficult case.
[03:29:52] <soreau> pq: Maybe the egl part needs to be handled in mesa?
[03:30:30] <pq> that's a given
[03:32:45] <pq> but how: should wl_drm protocol pass multiple buffers? Should the splitting be hidden from clients or server? If it is hidden, how to repeat all rendering for all pieces? If it is not hidden, how to allow clients assign which piece they render to?
[03:34:15] <soreau> A tricky case.. have to trick the hardware into doing what you want while tiptoeing around it's physical limitations
[03:35:02] <pq> and will the server need to use a new extension to be able to composite all pieces, or will it be hidden inside mesa, which is near impossible?
[03:38:03] <pq> soreau, that is not exactly possible for texturing: you are allowed to sample a single texture from anywhere for any fragment, so what if you sample from a different piece? hw simply doesn't work that way.
[03:50:25] --> rafalm (~rafalm at public14139.xdsl.centertel.pl) has joined #wayland
[03:50:35] <soreau> pq: But we're talking about compositing a complete image.. the use wont ever (sanely) actually have a resolution larger than mts
[03:51:26] <soreau> for texturing directly, of course not but for such a workaround, there should be someway to piece it together I'd imagine
[03:56:05] <soreau> Actually, in the case of multiple outputs, you could potentially have a total res larger than mts but I'm thinking as long as a single surface does not exceed the limit, it should be possible to piece them together in the compositor(?)
[03:56:27] <fredrikh> the texture size limit on current generation gpu's is 16384
[03:57:36] <fredrikh> you can have 8 full-hd monitors connected in a row without exceeding the limit
[03:57:56] <soreau> yes but the limit shouldn't be ignored 1) because there is still older hardware in use with lower limits (such as 2048) and 2) it should be handled anyway
[03:57:57] <fredrikh> so i'm not convinced that this is something wayland needs to be able to deal with
[03:58:40] <fredrikh> yes, but you're talking about graphics cards that are 10 years old
[03:58:58] <soreau> and I'm saying those should not be ignored
[03:59:33] <soreau> for all we know, the next gen output hw could be ultra hd, with tens of thousands of pixels packed into the physical size we use today
[04:00:04] <thiago> 4K resolution
[04:00:09] <soreau> the point is, this case should be handled
[04:00:20] <pq> soreau, scanout-limits can be higher than render target limits, IIRC, given old cards. And texture size is again a different limit, and usually smaller than render size.
[04:01:32] <fredrikh> i actually think it is perfectly reasonable to tell people who are using 10 year old computers that they may need to upgrade to be able to use their brand new display server with multiple monitors
[04:01:36] <fredrikh> call me crazy :)
[04:01:44] <pq> and a single surface maximised over multiple screens could cross the limits
[04:02:17] <soreau> For instance, a simple case: Try resizing and surface beyond your mts
[04:02:27] <soreau> s/and/any/
[04:02:45] <pq> fredrikh, yes, that is what all proprietary driver vendors do. "We cannot be bothered to support you anymore, go buy a new one."
[04:03:20] <pq> that's a huge load of negative PR
[04:03:26] <soreau> indeed
[04:03:56] <thiago> did cards 10 years ago support multiple monitors?
[04:04:40] <pq> let's see, the earliest nvidia chips that might support GL ES 2... are nv30 maybe? So that's geforce FX and 6 series, IIRC.
[04:04:55] <pq> thiago, I have nv28 supporting dual head
[04:05:12] <thiago> and what's the limit on those?
[04:05:48] <pq> I'd guess maybe 2k for textures? I have to google it, can't recall.
[04:05:49] <fredrikh> pq: there is a difference between supporting something for 2 years after it's been released, and still supporting it in new software 10+ years later
[04:06:18] <pq> fredrikh, is there? If hw is used, it is relevant.
[04:07:04] <fredrikh> pq: how large do you think that user base is?
[04:07:18] <pq> see the commentary on R128 EXA support on e.g. phoronix, many happy comments which is very surprising on phoronix forums.
[04:07:57] <pq> fredrikh, I don't know any specifics, I'm just saying you will get bad PR if you way things like that.
[04:08:03] <pq> *say
[04:09:32] <fredrikh> pq: there was also a user on the xorg list asking questions about developing athena apps for his 286 laptop a week ago
[04:11:24] <pq> ah, nv20 family seems to have 4k tex size limit.
[04:11:39] <pq> fredrikh, I do not mean such people.
[04:11:42] <fredrikh> that doesn't make me think it's a good idea to complicate the wayland specification and make life more difficult for 99.99% of developers just to appease an extremely vocal minority who doesn't want to upgrade ever, but still wants to be able to run the latest software
[04:12:02] <pq> fredrikh, it is not complicating *wayland* specification
[04:12:12] <pq> it complicates Mesa internals
[04:12:13] <fredrikh> and it's not like anyone is going to test this feature ever
[04:12:51] <pq> it's "just" an implementation detail
[04:12:55] <fredrikh> if it breaks, it could take years before anyone notices
[04:13:00] <pq> sure
[04:13:30] <fredrikh> so why waste time implementing it?
[04:13:55] <pq> not fixing it is a valid option, which I ignored because it is obvious, and started discussing the interesting choices
[04:14:30] <pq> oh, I'm not saying someone must implement it
[04:14:41] <pq> we are just thinking about how or if it could be done
[04:15:33] <soreau> fredrikh: It's not about testing, it's about handling as many known cases as possible, gracefully. It's about not noticing a problem in the event that a user does hit the case
[04:16:32] <soreau> For example, there are bug reports about tooltips exceeding mts due to some large text string and the client not trying to limit the allocated window size
[04:17:01] <soreau> in ubuntu, they have patched compiz to fallback to metacity if mts is exceeded
[04:17:42] <soreau> which might be confusing to users who hover over The Wrong Thing and get a giant tooltip, then compiz 'crashes'
[04:18:17] <pq> on Wayland, clients would only need to fall back to shm buffers for the too large surfaces, and Weston can fairly easily handle those internally.
[04:20:48] <soreau> Naturally, there are different solutions for the same problems on different platforms. This particular case could use some attention
[04:20:58] <pq> I guess the real issue here is to guarantee, that Mesa does not try lie, and clearly signals a failure, if an app tries to allocate too big of a surface.
[04:21:43] <soreau> Clients used to crash when resizing beyond mts, now it seems weston hangs
[04:22:22] <pq> that certainly is a bug :-)
[04:24:15] <soreau> pq: That sounds like a good idea, mesa should have some error for this when issuing whatever appropriate call
[04:24:55] <soreau> You'd think something like this would already be in opengl specs (is it?)
[04:25:08] <pq> or likely a cascade of two: 1) client EGL somehow avoids size limit checks and creates a bad wl_drm buffer, and 2) server EGL not erroring on that, 3) weston actually trying to use the bad buffer. Oops, that's three, I guess.
[04:25:28] <pq> well, of course
[04:26:17] <pq> like you cannot create a texture if you run out of memory, for instance
[04:26:31] <pq> both GL and EGL have error states
[04:31:01] <soreau> pq: So it errors wherever the call is to actually create the texture? glTexImage2D or the like?
[04:33:37] <pq> IIRC yeah, GL sets an error state, and you have to remember to check it.
[04:34:34] <pq> but that doesn't cause hangs
[04:35:08] <soreau> I imagine that's where you'd try to find out if the requested texture is too big and try the workaround path
[04:45:09] <pq> yes, but more important would be to fix any hangs, crashes or corruptions (that are not just pitch black).
[04:46:41] <pq> and make sure there's a way for apps to know that some size won't work. I'm not sure how wayland-egl API is supposed to handle it or punt it to EGL.