00:00 alyssa: so maybe texwrap doesn't test what I think it does.
03:55 Nyaa: the big endian girl has been summoned lol
04:10 Danct12: hi big endian
04:11 Danct12: where's little endian, did you invite them?
04:19 Nyaa: lol
08:18 tzimmermann: danvet, your fbdev proposal is what i had in mind, sort of
08:19 danvet: ah I guess then we just talked past each another yesterday, it happens :-/
08:19 tzimmermann: we interpret the prefered_bpp parameter not as raw bpp, but as color-mode value similar to video=
08:19 tzimmermann: yeah
08:19 tzimmermann: i'll make a patchset and test a bit
09:07 danvet: tzimmermann, I just noticed that there's a bunch of drivers with preferred_depth = 32
09:07 danvet:sighs
09:07 tzimmermann: yeah. that makes no sense unless they what argb8888
09:08 tzimmermann: danvet, are you on the latest drm-tip?
09:08 tzimmermann: because i cleaned that up IIRC
09:09 tzimmermann: it was in the recent patchset that caused the current troubles
09:09 tzimmermann: logicvc legitimatelly set 32 bit. the others not su much
09:11 Lynne: grr, the whole **point** of the vulkan API is flexibility
09:11 Lynne: yet the video API is horridly limiting because it wants to know which codecs, right down to the profile and level, an image would be used
09:11 danvet: 6f9f15e63de607ffbe621d33e8c8d49481e1e845 <- this really should be in fbdev code :-)
09:13 tzimmermann: danvet, the problem is that bpp==24 is legitimate if you want rgb888
09:14 danvet: yeah I know, we need mode_config.preferred_format
09:14 danvet: but also need a stopgap for the regression, since this broke a ton of drivers
09:15 tzimmermann: let me get my patchset done and discuss there. i'm having trouble following and getting things done
09:15 danvet: I'm out this lunch/afternoon
09:28 tzimmermann: danvet, i'll send out an RFC patch now, so that you can comment
09:34 tzimmermann: sent
09:36 danvet: tzimmermann, I'm confused ... we need a minimal regression fix
09:36 danvet: because afaics you've broken every single driver that doesn't set mode_config.preferred_depth
09:36 danvet: and we need to fix that asap with the most minimal patch
09:36 danvet: not more refactoring and rfc, that stuff is for later
09:37 tzimmermann: in that case, set XRGB8888 unconditionally
09:38 tzimmermann: let me try to minimize
09:39 danvet: adding yet another slightly funny way to select formats doesn't sound like a good short term fix, because it'll probably change/break something else
09:40 danvet: imo there's two options a) revert, start over by sorting the color mess first b) most minimal fix (the thing I sketched is probably close)
09:40 danvet: anything that tries to sort out this mess for real is probably way too much
09:40 danvet: for the regression fix
09:42 danvet: because atm more than half the kms drivers we have look like they're broken
09:43 danvet: (all the drivers which don't set mode_config.preferred_depth)
09:43 danvet: and we need a minimal fix for just that
09:44 tzimmermann: the RFC patch i send out fixes this problem already.
09:44 tzimmermann: it does not rely in preferred_depth any longer
09:44 tzimmermann: i can try to minimize the amont of changes
09:44 tzimmermann: but i think, it is what we want
09:44 tzimmermann: and it still works with the odd cases of 16/15 and 32/24
09:46 danvet: imo the long term direction should be drm_fourcc for all internal interfaces
09:47 danvet: so both preferred_bpp for fbdev and for mode_config.preferred_depth
09:47 danvet: anything else is just not wellspecificied enough
09:47 danvet: also xrgb8888 default needs to take host byte order hack into account probably
09:47 danvet: so this is all really tricky and needs care imo, and way too much for a regression fix
09:48 danvet: plus you don't handle vc4 correctly
09:56 tzimmermann: for host-byte order. can we use FORMAT_HOST_XRGB8888 unconditionally?
09:56 tzimmermann: danvet ^
09:57 tzimmermann: or does it need that flag thing
09:57 danvet: drm_driver_legacy_fb_format()
09:57 tzimmermann: make sense
09:57 danvet: I think it needs the flag thing
09:57 danvet: not sure
09:57 tzimmermann: and why does not not handle vc4 correctly?
09:58 danvet: oh you ditch preferred_depth outright
09:58 danvet: so that should work
10:01 tzimmermann: simpledrm/ofdrm may run on 15-bit frambuffers. so they have that special case. we can put that into a helper later
10:06 tzimmermann: danvet, updated patch is out
10:08 mripard: tzimmermann: I think your patch is broken on ofdrm, I guess you want s/sdev/odev/ ?
10:09 tzimmermann: mripard, indeed. thanks
10:11 danvet: https://paste.debian.net/hidden/e2187093/ this is imo the minimal regression fix
10:11 danvet: and more refactoring/rework/driver changes are for later
10:11 danvet: not opposed to more work, just not as regression fix
10:12 danvet: hm this could again go wrong badly
10:13 tzimmermann: ok, i now made sure that ofdrm is being build
10:15 tzimmermann: danvet, wouldn't your patch return things like argb8888?
10:15 danvet: yeah :-)
10:16 danvet: tzimmermann, entirely different idea, but maybe better long term
10:17 danvet: 1) add mode_config.preferred_format as a fourcc (0 means first try mode_config.preferred_depth, otherwise legacy xrgb8888)
10:17 danvet: 2) if that is set, use that directly as the right format in fbdev helpers fallback code, ignore all the preferred_bpp and preferred_depth confusion we have
10:17 danvet: 3) set that in ofdrm and simpledrm
10:18 danvet: 4) revert your patch
10:18 danvet: and then eventually long slog to move all other drivers over to that fourcc thing
10:18 tzimmermann: that's not minimal :)
10:18 danvet: yeah
10:18 danvet: well, do 4) first and then 1-3 to fix simpledrm/ofdrm
10:18 danvet: then it's more minimal
10:19 tzimmermann: setting a fourcc code as default certainly makes sense in the longer term
10:19 danvet: I just feel like trying to make sense out of this legacy mess without breaking one of the 100 or so kms drivers we have is impossible
10:19 danvet: so just leave legacy mess as it was last year, and outrigh replace it with something simple we can understand
10:19 tzimmermann: i'm pretty sure that my patch is now fairly small and covers all cases
10:19 danvet: i.e. single fourcc
10:20 danvet: tzimmermann, minimally needs v3 to explain that's it's a regression, Fixes: tag, why things broke and how it's getting fixed
10:20 danvet: and then cc the msm reporters too for tested-by I guess
10:20 tzimmermann: ok
10:20 danvet: if mripard can also add a t-b I guess that might be good enough?
10:20 danvet: but I'm really not sure
10:21 danvet: imo the mode_config.preferred_format is the way to go long term
10:27 tzimmermann: danvet, you'll be out later today? with fixes: and t-b:s added, can i add your a-b to the patch. i'd like to get it merged today
10:28 danvet: yeah a-b me
10:28 tzimmermann: thanks
10:28 danvet: I'm trying to think a bit what mode_config.preferred_format should look like
10:29 tzimmermann: ok
10:29 tzimmermann: it still has to be optional, i guess.
10:29 tzimmermann: with a default of xrgb8888
10:29 danvet: yeah
10:30 tzimmermann: fbdev should be able to override it via function argument
10:30 danvet: but I think it shouldn't be too hard to rip out mode_config.preferred_depth
10:30 tzimmermann: (for cases like vc4)
10:30 tzimmermann: i hope so
10:30 danvet: and then in the next step, rip out the function argument from most drivers for fbdev or so
10:30 danvet: and the remaining few pass a fourcc instead of bpp
10:31 danvet: I think that might work as a refactoring approach
10:31 danvet: since I tried to fix this mess a few times and got stuck over the years
10:32 tzimmermann: actually, i think we're close already. that format-selection code was the worst part
10:32 danvet: yeah for cmdline->fourcc conversion
10:32 danvet: I'm not sure it's entirely right, since essentially we should have a list of fbdev helper supported formats
10:32 danvet: and walk that, intersected with whatever the driver wants
10:33 danvet: but I guess fbdev for now doesn't support that much really so meh
10:40 tzimmermann: mairacanal, if you have a minute, please test https://lore.kernel.org/dri-devel/20230106101643.31497-1-tzimmermann@suse.de/T/#u on the rpi
10:43 mairacanal: tzimmermann, I'll test on the rpi and vkms
10:43 tzimmermann: thank you
10:52 mairacanal: tzimmermann, I'm getting "[drm] unsupported color mode of 0" on the vc4 and vkms. is this suppose to happen?
11:14 tzimmermann: mairacanal, one minute. that one check got lost.
11:24 tzimmermann: mairacanal, thanks a lot for testing. an updated patch is out. it should resolve the problem. it was just cosmetically
11:52 shadeslayer: kusma: re assert before calling align64, that sounds a lot more invasive than my change :(
11:53 shadeslayer: I don't understand why there's so much friction to move to a data type that would be able to handle both uint32_t and uint64_t
11:54 kusma: Because it makes the code slower
11:54 kusma: shadeslayer: Really? You said you identified two call-sites... Adding two asserts doesn't sound very invasive?
11:55 shadeslayer: I found 2 on casual inspection, I didn't go through every single align64 call
11:55 kusma: Right. Then what's the problem?
11:56 kusma: What are you trying to solve here? Is there a problem with the current code?
11:56 shadeslayer: Well, adding asserts before the call doesn't prevent future proof'ing align64 calls from accepting out of bounds alignments?
11:57 shadeslayer: I don't think there's a bug at the moment, but I'm just trying to make sure we don't run into issues for the future because of mis matched types
11:58 kusma: I'm not following. Do we need future proofing? Currently, the code is clear about not supporting passing 64-bit alignments... Shouldn't we be getting warnings if we throw away bits without explicit casts here?
11:58 shadeslayer: I didn't see any when downcasting from the uint64_t to a uint32_t in the current code, so I'm not sure ...
11:58 kusma: Right, but what I think Marek is saying (and if he's not, then I would be saying it), is that this is not a realistic problem.
11:59 kusma: There should be no reason for code to try to align to that large values...
12:00 shadeslayer: okay, I suppose I'll just drop that change then
12:01 kusma: If you add those asserts, I suspect that nobody is going to get confused about this in the future ;)
12:08 shadeslayer: kusma: since it's not realistic ... I'll just not bother :P
12:09 kusma: Sure 🤷
12:33 mripard: danvet: unfortunately, I won't be able to test it today
13:46 DavidHeidelberg[m]: mupuf: lol, sorry I clicked on Marge at exactly moment u did "D
13:47 mupuf: DavidHeidelberg[m]: ha ha
13:48 DavidHeidelberg[m]: Could someone ack mold 1.9 bump? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20546
13:49 DavidHeidelberg[m]: everything seems to be green + it solves -gsplit-dwarf bug for s390x (used in core dumps MR)
13:56 DavidHeidelberg[m]: lygstate: Hey! I seen you been improving mingw, what do you think about trying some useful linker (anything except ld.bfd)? I cc'd you on the issue, it would help me a lot with split debug builds :)
14:22 MrCooper: tzimmermann: FYI, there were working Linux OpenGL drivers before OpenGL 2.0 was a thing (and we didn't use them only for glxgears :)
16:29 tzimmermann: MrCooper, i know. i began C programming with 3dfx+mesa+linux back then :)
16:30 MrCooper: then you know there are lots of OpenGL 1.x apps
16:34 tzimmermann: of course. my point in that mail was that it's all long gone. there's nothing in those old drivers that cannot be done in software today.
16:35 tzimmermann: (it would be somewhat cool to have a modern drm 3d driver for 3dfx or matrox, though.)
16:38 ccr:pokes a crumbly G200 with a long stick.
16:41 KitsuWhooa: I ran extreme tux racer on my S3 Savage IX relatively recently before the old drivers got ripped out from mesa :p
16:43 ccr: I remember trying to get S3 Virge DX-something work under Utah-GLX. it was so slow that software rendering GLQuake was way faster. :)
16:44 KitsuWhooa: I think for me it's faster than using the CPU on that laptop
16:44 KitsuWhooa: That said, the original S3 Virge was rightfully called a decelerator :p
16:44 ccr: indeed
16:53 MrCooper: tzimmermann: "there's nothing in those old drivers that cannot be done in software today" is doubtful, such old GPUs tend to be paired with weak CPUs
16:59 KitsuWhooa: extremely weak ones indeed :p
17:27 tzimmermann: MrCooper, maybe reply to the emails, so that your comments won't get lost
17:39 MrCooper:not sure he cares enough
17:46 danvet: tzimmermann, so I pondered this all a bit more, and I think we have 2 more complications to think through for a long term approach
17:46 danvet: a) drivers which don't really support addfb2 (or are crap at it, I think we have a few problems there)
17:46 danvet: and b) big endian
17:46 danvet: they're kinda related :-)
17:47 danvet: mairacanal, ^^ I think I need to come up with an addfb format validation for non-atomic drivers too
17:48 danvet: eae06120f1974 only plugged one half of this mess
17:49 mairacanal: danvet, I can add this idea of validation for non-atomic drivers on the todo list
17:51 mairacanal: and thanks for the feedback about framebuffer_check()!
17:59 ice9: on hybrid graphics laptop while using the intel driver; if the laptop is left locked for sometime, the screen doesn't turn on again, sometimes the whole laptop freezes and I have to hard reset from the power button; this doesn't happen if using nvidia's driver; any idea?
18:05 alyssa: well, asahi is passing texwrap. i do not understand why.
18:09 HdkR: Hand waving magic
18:10 alyssa: Ohhh
18:10 alyssa: I hate C
18:10 alyssa: init_float_texture is fixing up the border colours to match the base format
18:10 alyssa: so texwrap doesn't check the 0.5 vs 1.0 case
18:10 jenatali: Why is that a problem with C?
18:11 alyssa: jenatali: see the impl of init_float_texture in texwrap
18:11 alyssa: I get what's happening now
18:11 alyssa: it's just
18:11 alyssa: extremely subtle
18:11 alyssa: and very C.
18:12 alyssa: also, I don't see any coverage of ASTC + GL_CLAMP_TO_BORDER in either dEQP or piglit, yeet
19:29 gekret005: https://gitlab.freedesktop.org/drm/amd/-/issues/2310
19:29 gekret005: does anyone know what mode the valve index sets to get 144hz?
19:46 HdkR: gekret005: https://gist.github.com/Sonicadvance1/0390b3ea1c7ffaa2ef47f0303700dfdc Maybe useful?
19:49 gekret005: https://tomverbeure.github.io/video_timings_calculator
19:50 gekret005: as far as I'm aware there needs to be set some timings to fit 144hz into the 1.2dp which this graphics card configuration doesn't take automatically
19:51 HdkR: xrandr output in the comment of the gist
19:53 HdkR: Also edid
19:55 gekret005: need something like "Modeline "2880x1600_144" 730.575 2880 2888 2920 2960 1600 1700 1708 1714 +HSync -VSync"
19:55 gekret005: no idea how display timings work personally
19:57 HdkR: Theoretically the edid should have that same information but since the displays aren't used by x11, modeline doesn't make much sense
20:19 agd5f: gekret005, it's possible the device doesn't like the reduced blanking timing even if the GPU were to use it
20:32 danvet: sravn, if lee/daniel ack for merging the backlight stuff through drm-misc, do you plan to apply them too?
20:50 gawin: bonjour, what would you say to putting some shaders from gles 2.0 CTS into shaderdb? iirc CTS has ok license(?)
20:51 gawin: I mean elemental stuff which often ends with workaround on older hardware/mobile (so no stuff like loops)
20:52 gawin: (recently I've caused trivial regression on r300 and unfortunately shaderdb didn't catch this)
21:10 DavidHeidelberg[m]: robclark: Hey, do you have in mind any config option which needs to be enabled to get adreno working on 6.1.x? we've already enabled the CONFIG_MSM_* but that doesn't seems to be enough
21:12 robclark: hmm, olddefconfig has more or less always worked for me with only one or two exceptions
21:12 robclark: but if you've got dmesg I could look
21:15 sravn: danvet: I will take care, but Lee is usual good at taking care pending review from Daniel.
21:16 sravn: I am resurrecting an old patchset of mine that replaces direct use of fb_blank with helpers in many more places. If I can get is in shape I plan to post it this weekend.
21:59 alyssa: dcbaker: trying to figure out the sanest way to run clang-format as a lint in meson
21:59 alyssa: per previous discussion
22:00 alyssa: basicaaalyssa@applejack:~/mesa/build$ clang-format-14 --Werror ~/mesa/src/gallium/drivers/panfrost/*.c --dry-run && echo "success"
22:01 alyssa: err
22:01 alyssa: alyssa@applejack:~/mesa/build$ clang-format-14 --Werror ~/mesa/src/gallium/drivers/panfrost/*.c --dry-run && echo "success"
22:01 alyssa: this does the right thing -- print success if it passes, prints a detailed error if not
22:01 alyssa: Just unsure how to integrate `clang-format-14 --Werror --dry-run` into meson in a reasonable way, with the following considerations
22:02 alyssa: 1. running in meson means devs get feedback before submitting an MR (so assuming people build-test their patches, reviewers should never have a style nit ever again)
22:02 alyssa: 2. running in meson means that CI checks it as part of the regular build-testing without any gitlab-ci changes
22:03 alyssa: 3. need a way to disable the linting to avoid adding a dev dependency on clang-format for distros who just want to build but not modify
22:03 alyssa: 4. should use the normal build system smarts to avoid relinting files that haven't changed (so there's no increased build time in an asymptoptic sense)
22:04 alyssa: seems like it should be easy meson glue, but IDK meson as well as I'd like
22:05 alyssa: meson likes to invoke the compiler itself so I'm trying to figure out how to sneak clang-format in there and pretend it's a compiler that doesn't produce build artefacts
22:06 alyssa: meson's clang-format integration is solving a different problem (reformatting vs linting)
22:10 alyssa: unless meson really doesn't want to work that way architecturally
22:11 dcbaker: alyssa: Is it clang-format or clang-tidy that meson just automatically runs if a .clang-tidy exists in the root directory?
22:12 dcbaker: err, automatically creates a target for
22:12 dcbaker: https://mesonbuild.com/Code-formatting.html#clangformat
22:13 dcbaker: I guess that only gives you a run target which changes files in place...
22:13 dcbaker: but you want a target that can run as a test...
22:13 dcbaker: we should fix that
22:13 dcbaker: on to your actual question
22:14 dcbaker: I'll write a quick gist of how I'd approach this
22:15 alyssa: oh, I see the clang-format-check on there now "intended to be used by CI"
22:16 alyssa: one of the proposed solutions was checking clang-format in CI, which I guess meson gives clang-format-check to do
22:16 alyssa: however I think we agreed that it's probably better to do the check as part of the regular build, so contributors get feedback immediately
22:16 alyssa: (I don't feel strongly but meh)
22:17 alyssa: what I'm really trying to do is make the on-boarding process as easy as possible
22:17 alyssa: in the past, trying to find the code style doc or mimicking existing code and then getting nitpicked when your patches aren't quite right ... is not fun
22:18 alyssa: in the present, having clang-format but not knowing you're supposed to use it and then the reviewer telling you to install clang-format ... is better but not great
22:18 alyssa: but everyone writing a patch has to (presumably) compile that patch before submitting it
22:19 Sachiel: nah, gcc takes too much space
22:19 dcbaker: alyssa: what about this: https://gitlab.freedesktop.org/-/snippets/7316
22:19 alyssa: if the act of compiling the patch is enough to check for formatting and give instructions on how to get setup properly before the patch even leaves the developer's machine, that's probably ideal from a UX standpoint
22:19 dcbaker: which runs clang-format as a unit test?
22:19 alyssa: ahahaha that's brilliant, thank you :)
22:19 alyssa: although
22:19 alyssa: hm
22:19 dcbaker: I did write that such that it will just silently skip if clang-format is not installed
22:19 alyssa: right, and also that only runs if you actually `meson test`
22:20 alyssa: which ... well, I don't :-p
22:20 alyssa: if it turns out that trying to run the lint on dev machines is unreasonable, then ok, I guess we'll do that (or the existing meson clang-format-check) in CI
22:20 dcbaker: We honestly should have a meson lint or ninja -C builddir lint pass
22:21 alyssa: https://mesonbuild.com/Code-formatting.html#clangformat says that clang-format-check is autogenerated
22:21 dcbaker: yeah, but it's a run-target, so you ahve to do ninja -C builddir clang-format-check
22:21 dcbaker: and if you have multiple linters (say whenever I give the same treatment to rustfmt) then you'd have to run two passes
22:22 alyssa: right ok
22:22 alyssa: I guess there are two separate issues here
22:22 dcbaker: You cold use a custom_target I guess
22:22 alyssa: one is enforcing the lint in CI and the other is onboarding
22:22 dcbaker: which, is kinda mean, but...
22:22 alyssa: for #1 the existing stuff is fine and maybe just .gitlab-ci is the way to go
22:23 alyssa: for #2 maybe trying to automate this entirely is unreasonable and having a "How to contribute to Panfrost" document on docs.mesa3d.org that includes a blurb on clang-format is the best way to go
22:23 alyssa: minus the whole "people don't read" thing
22:24 dcbaker: maybe a git commit hook?
22:24 alyssa: a hook to run the lint? that might be a reasonable compromise, yeah
22:24 alyssa: and that neatly avoids the distro problem
22:25 alyssa: (since you don't run the hook if you're just building and not trying to contribute upstream)
22:25 alyssa: It does duplicate the commit hook + `meson lint` in CI but that's probably maybe ok
22:27 dcbaker: I think ideally we would add a meson lint command upstream, which would make the CI + hook burden lower. You could just have the CI and the hook call call into meson lint, which would be very cheap to maintain
22:27 alyssa: *nod*
22:28 dcbaker:will go write an issue and add it to his every growing backlog of things to do
22:28 alyssa: mood
22:39 alyssa: starting to write the gitlab ci changes needed
22:40 alyssa: hitting the "whoops need to add clang-format to the container" step >>
22:41 alyssa: oh and here's a "fun" problem... clang-format-14 isn't in bullseye
22:41 alyssa: let's see if -13 has any "interesting" breaking changes
22:44 alyssa: seems compatible :)
22:56 dcbaker: alyssa: https://github.com/mesonbuild/meson/issues/11252