02:56 mareko: I just noticed that zink has an exact copy of the some of the juicy amdgpu winsys code, including comments
03:03 jenatali: Oof
03:18 mareko: I don't mind that, sharing that code would make refactoring difficult for us, but the downside is that Mike will have more copying to do next year
08:26 MrCooper: ChaosPrincess: if you mean libGL.so.1, that symbol isn't part of its ABI, you need to retrieve it using glXGetProcAddress
09:32 nektro: is there any function i can call or env var i can set to make mesa panic when encountering an error instead of always requiring calls to glGetError?
09:32 nektro: like a debug mode thats super strict
09:45 ishitatsuyuki: nektro: you probably want to enable https://www.khronos.org/opengl/wiki/Debug_Output and put whatever you want in the handler (breakpoint, abort, log, etc.)
10:34 nektro: thanks!
10:34 nektro: from https://www.khronos.org/opengl/wiki/OpenGL_Context#Debug_contexts,
10:34 nektro: > A context can be created in debug mode. This allows, among other things, debug output functionality to work more effectively.
10:35 nektro: is this referring to mesa being built in debug mode?
10:35 nektro: i have added glEnable(GL_DEBUG_OUTPUT); but am not sure if that's all
10:36 HdkR: You also want to use glDebugMessageCallback
10:41 nektro: thank u :)
11:10 nektro: got both hooked up and it found my issue super quick, thanks HdkR + ishitatsuyuki !
12:32 tomba: I've been trying to understand what exactly DRM_PLANE_TYPE_PRIMARY and DRM_PLANE_TYPE_OVERLAY mean. Are they just hints to the userspace, or does a plane being primary/overlay imply some kind of specific behavior from that plane?
12:34 tomba: For a bit of context, the TI display subsystem has 4 identical generic planes. Currently the driver doesn't restrict those in any way, but there have been requests to artificially limit the planes a bit so that the userspace has it easier. I don't particularly like that idea, but if "everyone" is using that, it's good to be on the same train. However, I can't find any mention about the expected behavior.
12:38 mripard: tomba: the "artificial" restriction is at least what we're doing on sun4i and vc4 which are in similar situations
12:39 tomba: And to be more specific, the idea would be to dedicate one plane for each crtc, and mark those as primary. I'm not sure if additionally we need to restrict the zpos, so that the primary is always behind any possible overlay planes.
12:40 mripard: yeah, that's what I was refererring to too
12:41 mripard: sun4i has 4 planes with the same features, vc4 has... something else, but for that discussion is in the same situation :)
12:41 mripard: I don't think we can have the expectation that the primary plane is the background plane though
12:41 tomba: mripard: Yep. but is that good, or is it just the easy way out so that the userspace doesn't have to be fixed? =). In the embedded world not everyone uses X or weston, and I'm a bit hesitant to essentially remove planes from possible use cases. Then again, to be honest, I don't specifically _know_ anyone requiring the full plane configurability.
12:42 javierm: tomba: AFAIU the problem is that there are user-space that can't handle universal planes
12:42 javierm: tomba: e.g: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3428
12:42 mripard: tomba: I hear what you say about embedded, but also if your driver can't work with weston or X, your driver is broken
12:43 mripard: so yes, there will be embedded-specific problems and solutions
12:44 mripard: but I think the general expectation is that its "standard" behaviour is the same than everyone else
12:44 mripard: but pq and emersion are the ones to poke on this :)
12:44 tomba: mripard: well, I agree but not fully. new features are being added to weston all the time. those weston features might be broken, even if they work on certain set of drivers but not all.
12:46 tomba: afaik, tidss used to work fine with weston, but doesn't anymore because... magic stuff that I'm not quite aware of. gpu hw recovery, overlay plane features, perhaps.
12:46 tomba: (I'm trying to get more information about the actual issues, so sorry my vagueness =)
12:52 tomba: javierm: I'm not sure that's the case, at least in the particular case I'm looking at. I think the related apps use universal planes (but I have to say I'm not sure). However, what's said there in a comment makes sense: "Once the client passes DRM_CLIENT_CAP_UNIVERSAL_PLANES, it should not bother with the primary vs cursor vs overlay planes". I'm not sure if that's a real rule, though.
13:04 emersion: tomba: not sure if i have all context, but the driver can expose stuff differently if user-space doesn't announce support for universal planes
13:05 mripard: emersion: I think the main question is: is there any expectation wrt to primary planes, and whether or not they should be tied down to a given CRTC or can be moved between CRTCs
13:05 tomba: emersion: Hmm good point. But what is the "right" way for non-universal and universal cases?
13:06 emersion: primary planes do not need to be tied to a specific CRTC, no
13:07 mripard: emersion: and so it's "fine" if a CRTC doesn't have an available primary plane?
13:07 emersion: oh, no, that one is not ok
13:07 emersion: a primary plane needs to have >1 possible CRTC
13:07 emersion: a CRTC needs to have exactly 1 primary plane
13:07 tomba: mripard: "available" in what sense? in my cases there's always a plane for each crtc.
13:07 mripard: but if they aren't tied to a given CRTC, they can be assigned to another
13:08 mripard: so you could have a CRTC with a primary plane but currently being used on another
13:10 mripard: tomba: available == not currently used
13:14 tomba: A related question/point: I don't think drm drivers do any kind of reset when a drm application exits or starts. So, let's say we have app A, which uses universal planes, and moves all planes to crtc0 from the other crtcs. And then exits. App B starts, which doesn't use universal planes (well, actually, no app "uses" universal planes until they set the client cap). I think here the planes would still be assigned to the crtc0, and app B wouldn't be
13:14 tomba: able to cope with that.
13:16 emersion: yeah, that's kind of expected
13:16 pq: tomba, that KMS hand-off from complex to simpler app problem is already unsolved. You're nothing bringing anything new to it by the planes situation.
13:16 emersion: user-space A sets NEW_FANCY_PROP, user-space B doesn't understand it and can't unset it
13:16 pq: practically all KMS properties have the same problem: what if someone set it to something weird, and I don't even understand what it is
13:17 pq: today's solution to that is: don't leave weird state behind, if you want to play nice with others
13:17 emersion: indeed
13:17 emersion: we've requested multiple times a way to reset the KMS state in same way
13:17 tomba: right, been there, done that =).
13:18 emersion: but kernel devs don't like this for some reason
13:18 pq: It's a bit unfortunate, but not pressing enough that anyone would invest the effort to solve it.
13:18 tomba: I wanted to bring that point up, as I think that complex-simple switch is one part of the simplify-planes-argument.
13:19 pq: well, in production, when do you even switch between KMS apps?
13:19 tomba: the users, they do silly stuff...
13:21 pq: Firmware to Plymouth to graphical login compositor to session compositor. Often login and session compositors are the same, or at least cooperative.
13:22 pq: I totally see the problem, and I can see how to trigger it, but somehow it still hasn't been important enough to solve. Not for me, either.
13:22 tomba: Anyway, looking at the discussion above, is my summary here correct: With universal planes, the app should be allowed to move primary planes around, and with universal planes the plane type doesn't really mean much. Switching between KMS apps goes into uncharted territory, and there can be problems.
13:23 pq: yeah
13:23 pq: you can mark a plane to be usable on more than one CRTC, so you'd probably mark all to be usable on all CRTCs
13:24 pq: what would be really nice towards userspace is to have enough primary planes so that every CRTC can get one.
13:24 mripard: how does zpos (and in particular immutable zpos) work in that case then?
13:24 tomba: pq: yes, that what the driver (tidss) does currently, and there's a primary plane for each crtc. but (reportedly) weston gets very confused in some cases (I'm trying to get more details).
13:25 pq: When userspace is looking to light up a CRTC+connector, it usually first looks for a primary plane for that CRTC, because that is the most probable configuration to work.
13:25 emersion: mripard: immutable zpos, but different zpos depending on CRTC>
13:25 emersion: ?
13:25 pq: tomba, would be nice to have a Weston bug report filed, indeed.
13:26 mripard: emersion: I think most of the kernel drivers will set the immutable zpos of primary planes to 0
13:26 emersion: note, multiple drivers advertise multiple possible CRTCs per primary plane
13:27 emersion: i think some drivers are also lazy and set possible CRTCs to 0xFFFFFFFF
13:27 pq: mripard, probably those drivers do not mark the plane compatible with more than one CRTC - if they do, they could use some fixing.
13:27 emersion: (ie, have bits in possible CRTCs that refer to non-existing CRTCs)
13:27 pq: IIRC, if zpos values are equal, the plane z-ordering is undefined, isn't it? That's what I'd expect in userspace anyway.
13:28 emersion: yes
13:28 pq: so if all planes have immutable zpos=0, userspace would just not use more than one plane on a CRTC, because it won't know what would happen.
13:29 emersion: pq, "of primary planes" only
13:29 tomba: I don't think the zordering is undefined, exactly. With the zpos normalization, the normalized zpos (if zpos=0 for all planes) will be based on plane index. But if the userspace sets the same zpos on multiple planes and gets problems, I think it can only blame itself...
13:29 mripard: pq: the kernel will order them by plane index
13:29 mripard: but I'm not sure it's guaranteed, so it would fit under undefined :)
13:29 pq: mripard, kernel internals, not supposed to be relied upon.
13:30 pq: as long as zpos exists, at least
13:30 emersion: the plane index thing is documented in case zpos doesn't exist
13:30 emersion: if zpos exists, the order is documented as undefined
13:32 pq: emersion, in the example, I understood there are 4 primary planes, each capable of all 4 CRTCs, and no other planes. Is there any rule that userspace should not attempt multiple primaries on the same CRTC? unless all have identical zpos.
13:33 emersion: no such rule
13:33 emersion: right
13:33 emersion: in that case, order is undefined
13:33 emersion: a helpful driver might try to come up with a device-wide unique zpos
13:35 pq: a driver should, indeed, or make zpos mutable
13:35 emersion: yea
13:36 pq: Userspace could choose to never use more than one primary plane per CRTC. This would make it much more likely that it can light up additional CRTCs easily. But if more complex logic is implemented in userspace, that's not necessary.
13:37 emersion: to light up more CRTCs, you'll need to start from scratch, basic configuration on all CRTCs
16:22 karolherbst: mareko: do you have some time today to do a quick review of the radeonsi changes (just enabling some opts on lower_subgroup) in https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26504 ? thanks
16:40 DodoGTA: Hopefully https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26630 can get the Marge Bot treatment
17:01 agd5f: airlied, sima can we get a backmerge of 6.7-rc5 to drm-next? I need the drm/prime unexport revert for some kfd changes
17:15 gfxstrand: dcbaker: What's the min python version we support?
17:23 mattst88: DavidHeidelberg: just curious if you know whether there's been any progress upstream in VK-GL-CTS on reducing the number of tests added in 1.3.7.0?
17:25 mattst88: gfxstrand: not definitive, but we reduced the required version to 3.6 in bca22a65781665054a7d9d964e548459c610593e 11 months ago
17:26 mattst88: since then ChromeOS has moved from 3.6 to 3.8 though, so we don't need older than 3.8
17:26 mattst88: that's the most recent Python version-related change I can find, so 3.8 seems plausible
17:28 DavidHeidelberg: mattst88: about Python 3.6, there was some RHEL person who was fighting for this I think :D
17:30 gfxstrand: As long as we're okay with cpython || version >= 3.8, I think we're fine.
17:30 gfxstrand: karolherbst assumed ordered Dict in a patch
17:44 mattst88: DavidHeidelberg: did you see my question about VK-GL-CTS?
17:50 mattst88: daniels: maybe you know?
17:52 DavidHeidelberg: mattst88: yup, but not sure (not from my side)
17:57 karolherbst: gfxstrand: list of tuples sounds like a good idea here though
17:59 karolherbst: gfxstrand: funny enough, it just works with the changes 🙃
18:00 karolherbst: mhh...
18:01 karolherbst: python is weird
18:01 karolherbst: now that I changed the default to `[]` it doesn't anymore...
18:02 karolherbst: ohh nvm.. I disabled nvk for $reasons
18:18 karolherbst: gfxstrand: btw, ping on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26541#note_2201546
18:19 karolherbst: the annoying part of printf is `format must be a pointer(constant) to i8. ` anyway....
18:19 karolherbst: I hope we can just wing it until we hit somebody actually passing in format strings from outside 🙃
20:41 nektro: is there any way to make texture cube maps have their origin in the top left
20:41 gfxstrand: As in change the ordering of the planes? No.
20:42 nektro: rn its in the bottom left and my texture loaded in upside down
20:42 gfxstrand: Yeah, you need to flip your texture.
20:42 gfxstrand: There's no way you can re-configure the texture once it's uploaded.
22:00 karolherbst: jenatali: wanna remove more cl feature flags to clc? otherwise I'll just marge https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26504
22:01 jenatali: karolherbst: R-b on c9ce0a44
22:01 jenatali: I'll comment on the MR
22:03 karolherbst: in hindsight we should have checked if that `c->getPreprocessorOpts().addMacroDef` and `c->getPreprocessorOpts().addMacroUnDef
22:03 karolherbst: ...
22:03 karolherbst: works
22:04 karolherbst: maybe I'll try that later and submit a cleanup MR for that
22:04 karolherbst: it's kinda weird having those two places...
22:05 karolherbst: thanks!
22:21 karolherbst: jenatali: what ya say? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26641/diffs?commit_id=363ff196ecba1dcaa2c5bb30eb3d528dd88735c1
22:22 karolherbst: kinda annoying that the other block is some llvm-14+ thing, but... oh well
22:22 jenatali: Assuming it works, LGTM
22:23 karolherbst: yeah.. didn't test the CL CTS, but the subgroup_shuffle ext worked as expected with this still
22:23 karolherbst: anyway, I think it's a bit saner this way
22:24 karolherbst: (and probably also lower CPU overhead)
22:24 jenatali: Yeah, probably