00:40mareko: Kayden: it's fixed by my MR
00:43mareko: I wonder why people don't notice it
00:47mareko: Kayden: also https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7679/diffs?commit_id=f0d5a0485d861dcd1465737ecda8f88c5f1d9ccb
00:49anholt: it would be nice to get some real commit messages. like, was the code being removed in that commit a bug, or something where we were using a 0 before and you're preparing to make it be undef?
00:59Kayden: mareko: ah, thanks!
00:59Kayden: ngcortes: have you seen https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8046 ?
01:14ngcortes: Kayden, running through CI :)
01:15ngcortes: mareko, ^
02:50onox: anholt: why not drop i915g as well?
03:55mareko: anholt: yeah the commit message don't explain much, the MR does
04:04alyssa: commit messages tend to outlive their corresponding MRs (and mailing lists before that..)
04:41mareko: I'll try to make better commit messages
09:58danvet: mlankhorst_, btw you can backmerge now, drm was the very first pull request
09:58danvet: so I could just fast-forward
09:59danvet: well maybe wait a few minutes until I landed the pull from tzimmermann that got lost
10:01danvet: mlankhorst_, ok it's out there now
10:05mlankhorst_: Hm weird.. dim: Upstream drm/drm-next not merged into drm-tip, aborting.
10:10mlankhorst_: o well, silenced that error
10:11danvet: mlankhorst_, there's a conflict
10:11danvet: I think könig didn't fix it
10:11danvet: still rebuilding
10:11danvet: mlankhorst_, maybe wait with pushing
10:11mlankhorst_: too late
10:13mlankhorst_: But it shouldn't affect anything, even if drm-misc-next backmerge is not part of drm-tip, it will be there next time someoen pushes anyway.
10:14mlankhorst_: brb, on a break :)
10:22mripard: mlankhorst_: thanks :)
10:53tomba: danvet: mlankhorst_: can I push the "drm: automatic legacy gamma support" with only Laurent's RB, or should I wait for an ack from one of the maintainers given by get_maintainer.pl? It's not always clear to me who needs to ack the core changes...
11:12mlankhorst_: tomba: you can add my ack if you want, took a quick glance
11:12mlankhorst_: either way its ok to push
11:12tomba: mlankhorst_: thanks
11:30danvet: tomba, yeah for core changes the rule is "proper review and tests and stuff"
11:31danvet: not "maintainers must ack"
11:32tomba: danvet: ok, thanks
11:34danvet: tomba, maintainer should be just master of ceremonies, all the merge criteria should be documented somewhere and committers can just push
12:24emersion: lrusak: if you wanted test YUV data https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/534
12:55pq: aagh aagh aagh
12:56pq: emersion, lrusak, please do read the long list of caveats documented for that MR. :-P
12:56emersion: ahah yeah
12:59pq: wl_shm YUV formats are ill-defined even, because wl_shm just doesn't carry any information about the extra planes, like offset and stride
12:59pq: and I don't think the assumptions are documented anywher
13:01pq: so I can't write a proper test, even if I had code for correct chroma siting/filtering
13:05tzimmermann: emersion, danvet, thanks for fixing the issue with dim
13:05testy12: HI freinds
13:05emersion: np :)
13:06emersion: testy12: this question is off-topic for this channel
13:06testy12: where can I ask this??
14:51ajax: onox: re i915g, the current theory is to set the bar at gles2-capable. (where i guess by "the current" i mean "my")
15:09ayaka: May I ask whether the GPU for AMD Ryzen r3 4350 pro is supported in mesa
15:13ajax: ayaka: probably? that's a radeon vega, which mesa does generally support, but there's always the question of whether a specific pci id is supported. if you can find that out we can probably give you a more definite answer
15:23amonakov: most of the non-trivial support is on the kernel side
15:28zmike: Kayden: I have a st series coming up that I imagine you'll be interested in for iris, providing full argb/abgr emulation in the hw path instead of the ultra slow sw fallback
15:28agd5f_: ayaka, all AMD GPUs are supported
15:29ajax: zmike: niiiice
15:30zmike: zink can now push about 15fps in rpcs3 vs iris's 0.2fps with this and some other changes :D
15:31linkmauve: I’m very interested, last time I tried to optimise rpcs3 on iris I didn’t really manage to.
15:32zmike: well without native argb format support a driver basically can't run it
15:33ajax: yeah but here in the fully-swizzled future there's no excuse for not supporting arbitrary permutations
15:33zmike: there's certainly a lot of swizzling involved
15:36danvet: agd5f_, btw have you seen the nag from sfr about some kerneldoc warning in amdgpu?
15:36danvet: if you have a fix somewhere, I guess I need to do a pull request to linus anyway
15:37agd5f_: danvet, yeah, it's easy enough to fix, but, I don't understand why that warns, but none of the other members of that struct that lack doumentation warn
15:37ayaka: my problem is that, I found the vaapi won't not work
15:37ayaka: I think I need amdgpu pro for decoding
15:37danvet: agd5f_, maybe just tracking new stuff, dunno
15:38agd5f_: ayaka, you don't need pro for decoding. The pro driver for video is mesa, just packaged
15:39ayaka: agd5f_, then I don't know why gstreamer vaapi doesn't work
15:39agd5f_: ayaka, make sure you install the mesa video drivers for your distro
15:40ayaka: agd5f_, yes, vainfo shows it has been installed
15:40ayaka: but I checked, the problem is that some va-api call doesn't return the right value
15:40ayaka: is there any way to debug va-api in mesa ?
15:40agd5f_: ayaka, vainfo works? than it's probably a configuration issue with gstreamer
15:41emersion: what's the vaapi error message?
15:41ayaka: well, in the other case, an Intel ApolloLake would work
15:42ayaka: emersion, invalid id for vabuffer, I am uninstalled the old driver
15:42ayaka: I would check the log again
15:48ceyusa: ayaka: what are you trying to do? encoding which what codec?
15:49ayaka: ceyusa, you are right man here, it is about that drm modifier case
15:49ayaka: I want to know the situation in amd platform, whether it request drm modifier for dma buffer in decoding
15:50ceyusa: what's happening?
15:51emersion: amd only recently added support for modifiers, you likely don't have it yet
15:52emersion: also only for GFX9+
15:53amonakov: is the decoder ring for GFXfoo names published anywhere? :)
15:53agd5f_: amonakov, gfx9 is vega so anything vega or newer
15:54amonakov: yes, but then I need another ring to know what a Vega is (it's just another codename...)
15:54emersion: https://www.x.org/wiki/RadeonFeature/ has a few decoder rings
15:55amonakov: you know that neither lscpu nor /proc/cpuinfo mention Vega on Renoir SoCs, right?
15:56ayaka: for the issue of gstreamer, I would left it for #gstreamer
15:57ayaka: maybe I would just download libva I remember there is a demo program for decoding slices
15:57emersion: amonakov: what about lspci
15:57amonakov: emersion: lspci says Renoir (I actually meant lspci rather than lscpu in that message)
15:58emersion: renoir doesn't seem to be vega
15:59emersion: renoir is missing from the "Decoder ring for engineering vs marketing names" table, though
15:59emersion: well, sounds like that table is not complete anyways
16:00agd5f_: renoir is vega
16:01bnieuwenhuizen: emersion: Renoir is GFX9 and the name of the GPU proper as provided by the windows driver is still Vega AFAIU
16:01emersion: eh, ok
16:02ayaka: also my CPU r3 4350 is also one of Renoir serial
16:02ayaka: I can't figure the relation between vega serials and radeon serials at all
16:03emersion: i guess we're just missing a "vega" family entry in the table then
16:07ceyusa: ayaka: perhaps you're hit by https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7949
16:09agd5f_: there are too many marketing names. Use the wikipedia page for that
16:12MrCooper: in a nutshell though, all Ryzen APUs released so far are Vega
16:29danvet: agd5f_, same for intel, I use wikipedia as my decoder :-)
16:39ayaka: ajax, thank
16:39ayaka: agd5f_, thank you
16:39ayaka: emersion, and thank you for telling the detail about amd
18:02ajax: deqp is remarkably annoying to invoke by hand
18:19anholt: ajax: can I help you use deqp-runner? :)
18:22zmike: I concur
18:47zmike: maybe a dumb question but has anyone yet written some kind of script to translate gitlab review attribution to commit log?
18:48zmike: e.g., "git lab 'ab <gitlab_id>'" would print "Acked-By: <real name + email>"
18:50anholt: the problem is that review in MRs is free-form, so you can't really parse it in general, so i don't think anyone's done one. ("the following commit summaries are acked by me, the last commit is r-b if you've done xyz")
18:51anholt: personally, I recommend dropping commit attribution requirements for your driver. it's really nice!
18:51zmike: well I'm mostly talking like for !8107
18:51zmike: where you and ajax both chimed in and then I need to add that into the commit log before I marge
18:52anholt: yep, this process sucks!
18:52zmike: it's faster for me to type 'rb anholt' than to do git log, search for you, and copy/paste
18:52zmike: so I'm not really looking for automating it on gitlab (though that would be awesome), just simplifying the manual process
18:53jenatali: +1, finding the right email to stick in the attribution from a 'r-b' comment can be a pain
18:53anholt: I've got some macros in my editor for common reviewers I get, until the project as a whole can come around.
18:55ajax: i try to remember to write `Reviewed-by: Adam Jackson <firstname.lastname@example.org>` explicitly so people have an easy thing to copypaste
18:55ajax: but that, too, is awful
18:56zmike: I have it as an autoreplace in my irc client so I can just trigger it there and copy/paste it in
18:56ajax: if the Approve button could turn into r-b, perhaps
18:56zmike: that's what I was 🤔
18:56zmike: though then we'd lose a-b
18:56zmike: and whatever other variants
18:56zmike: so people would have to manually add "noticed by ajax" to all their patches
19:01jenatali: I remember a discussion about that a while ago, the concern was that you'd lose the ability to have different people review different patches
19:02zmike: it seems like something that should be solved at the gitlab level
19:02zmike: I can imagine a ui where there's a couple buttons for ab and rb that actually applies the tag to the specified commit and then the 'approve' button does the marge
19:10zmike: aha https://gitlab.com/gitlab-org/gitlab/-/issues/1089
19:10zmike: huh there's a comment here saying that marge supports doing this?
19:11anholt: approval is for ee only
19:11anholt: and marge doesn't use it on ce
19:14zmike: anholt: is approval for ee only or is gating on approval ee only?
19:14zmike: at a casual glance it looks like the latter
19:14anholt: they promoted the approval button up to ce, but not hooking it up to anything.
19:15zmike: ah so the approver data doesn't get passed on
19:15anholt: the data's in gitlab so you could query it if you wanted
19:15anholt: and so one *could* write a marge patch to do it
19:16anholt: but marge upstream doesn't want to do that because stealing business from gitlab
19:16anholt: and also, seriously, we should just drop this commit tags requirement.
19:43tlwoerner: if there are any vc4/userland/dispmanx people who would be so kind as to give the first couple paragraphs of the following a read i'd much appreciate it
19:44tlwoerner: i'd just like to make sure i have all the wording correct
19:58Kayden: zmike: oh wow. I wasn't aware we had ultra slow SW fallbacks...
19:58zmike: Kayden: yea it's basically just with stuff that heavily uses pbos I think?
19:59zmike: rpcs3 was the first (and only) time I've encountered it
19:59zmike: it's so slow that even 1fps is a big ask
19:59Kayden: yeah, I could definitely see our pbo paths not do enough swizzling
19:59Kayden: and just fall back to map with cpu
19:59zmike: yea exactly
20:01emersion: > I'm explicitly disabling VC4GRAPHICS (which refers to the fully open-sourced Mesa support), thereby enabling support for the blob+userland graphics stack
20:04Kayden: not quite clear why it's being disabled from skimming the article
20:06emersion: because tlwoerner doesn't want a compositor, and apparently the proprietary stuff has demos that run on bare metal via proprietary magic
20:07emersion: this still makes me sad
20:09anholt: I can't understand doing anything new with dispmanx at this point.
20:31tlwoerner: emersion: yes, *if* a user/customer wants what's behind door #2...
20:31tlwoerner: anholt: neither can i, but just showing what's possible
20:47emersion: if a user wants to run something without a display server, i still woudln't recommend proprietary blobs
22:03Kayden: this mbcnt trickery is pretty cool
22:06tlwoerner: emersion: i'm happy to take suggestions
22:09robclark: tlwoerner: kmscube!
22:15tlwoerner: robclark: thanks :-)
22:22emersion: there are a bunch of kms clients out there
22:22emersion: some EGL and Vulkan clients making use of the direct display extensions
22:22emersion: mpv, kodi
22:32ajax:makes the mistake of reading wine/dlls/winex11.drv/opengl.c
22:58tlwoerner: very very nice! thank you. kmscube and glmark2-es2-drm work great
22:58tlwoerner:feels another blog post coming on, lol
22:59tlwoerner: is kmscube 64-bit only?
22:59tlwoerner: (i.e. without a compositor, just for fun)
23:01robclark: I'm not aware of any 64b dependencies.. I guess I don't actually use 32b stuff much these days.. but kmscube predates aarch64
23:01linkmauve: tlwoerner, no, it also works on AArch32 (and basically any architecture supported by your compiler).
23:01linkmauve: robclark, I’ve tested it on ARMv7 just earlier today on a Cortex-A7 board. :)
23:01linkmauve: With Lima.
23:02robclark: ahh, cool.. so we haven't broken something along the way :-)
23:02tlwoerner: OpenEmbedded isn't letting me build it for rpi-32, so i'm guessing that's a restriction OE is adding, not something inherent in the code
23:17anholt: ajax: throw your xlib-glx comparisons up somewhere I can look at them, maybe?
23:17ajax: anholt: will do. need to rerun some though, i think i measured the wrong thing.
23:18ajax: super tedious to keep your LD_LIBRARY_PATHS straight for n different targets
23:19anholt: yeah, trusting one's collection of scripts for doing this kind of tesitng is rough.
23:19anholt:has 11 build trees in their main mesa repo
23:19ajax: definitely not opposed to deleting the xlib targets tbh
23:20anholt: I don't think I have a good sense of what the xlib targets offer over the dri swrast paths
23:20anholt: looks like debian doesn't even package one?
23:21ajax: i think historically their value was a) gdb that sucked at dlopen b) xserver that didn't have a glx extension
23:21ajax: that second one i think i could paper over in libGL proper if we really cared
23:22ajax: i'm somewhat disinclined to care, but
23:23ajax: i think debian used to have it for like s390x and m68k where hwaccel isn't a thing?