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