00:53 airlied: anyone want to ack me some vulkan headers https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27421
00:56 Sachiel: acked
00:59 airlied: thanks!
03:55 airlied: zzoon[m]: you never looked at av1 on anv did you?
03:57 zzoon[m]: airlied: I have looked into your branch and tested some time ago.
03:58 zzoon[m]: I'm almost finishing h265 encoding, so I could look into it again.
04:06 airlied: zzoon[m]: I was just going to clean up the branch on top of the released spec at least
04:33 zzoon[m]: that'll be good
06:36 airlied: zzoon[m], Lynne : https://gitlab.freedesktop.org/airlied/mesa/-/commits/anv-vulkan-video-decode-av1 at least builds here, but I don't have a dg2 plugged in, so untested at all
06:36 airlied: (I'll try and plug a dg2 in next week, the machine I was using is doing nvk cts runs at the moment, and I'd rather not stop it :-P
07:17 airlied: okay I plugged it in elsewhere, and it decodes green garbage
07:42 airlied: okay now decoding frame tiles in wierd places, which I suppose is better
07:58 mripard: airlied: so should I just send a patch to get rid of the ones embedded in the kernel?
07:58 kode54: I thought dg2 got dropped under the bus to pave the way for xe2
07:58 mripard: and use that as the starting point for a discussion with the RPi folks to see why they are really using it for?
07:59 mripard: I have the feeling it's much more prevalent than it's original intent, but I might very well be wrong
08:13 tzimmermann: airlied, sima, hi! did you merge the early PR for drm-misc-next? https://lore.kernel.org/dri-devel/20240111154902.GA8448@linux-uq9g/
08:21 jani: airlied: sima: ack for enabling most W=1 warnings by default across the subsystem? https://lore.kernel.org/r/b3f9cfa3304e4db1a964ec962dc0974857c0edf0.1706797803.git.jani.nikula@intel.com
08:50 zzoon[m]: airlied: does it necessarily need dg2? as far as i know gen12 supports av1 dec, which is what I have now.
09:09 pq: mripard, if dropping those pre-baked EDIDs does not go through for any reason, then just don't add any more of them and let people get the breakage they ask for? :-)
09:09 mripard: pq: but then my HDMI series is stalled because there's a regression :)
09:10 pq: mripard, ugly hack special case to skip validation on pre-baked EDIDs? That should make a strong point.
09:12 pq: struct drm_edid { ... +bool user_is_doing_seriously_broken_things; }? :-p
09:22 mripard: fair enough :)
09:28 airlied: zzoon[m]: yeah gen12 or dg2, i have no intergrated gen12 here
09:28 zzoon[m]: ah okay. cool
09:29 airlied: tzimmermann: not yet , will do it tmrw or maybe monday unless sima feels up to it
09:30 tzimmermann: airlied, ok, no problem
09:30 airlied: mripard: what causes the regression?
09:32 mripard: airlied: so my series tries to figure out the best output format for a given state. Part of figuring that out is testing the formats the HDMI sink supports. The EDID parsing code will only fill the (mandatory) RGB444 format if it's a digital display (which makes total sense), but since the EDID being loaded is an analog one the monitor we detect reports that no format is supported
09:33 mripard: which then totally confuses my code
09:35 mripard: we could also just assume that RGB444 is always supported there too, but it feels to me like the issue really is that we're loading an EDID that is completely broken for the sink
09:39 airlied: mripard: ouch, yeah maybe just always assume 444 is a good baseline
09:50 sima: airlied, I figured we might as well wait for -rc3
09:52 pq: RGB444... that does not seem to exist, but there is DRM_FORMAT_XRGB4444 ;-)
09:52 sima: mripard, yeah I guess adding some special case including drm_warn logging if the user loads a non-digital edid on a hdmi output is probably best
09:54 sima: pq, they're bus formats, so MEDIA_BUS_FMT_* namespace
09:55 sima: which is unfortunately a lot less precisely documented than the drm_fourcc.h stuff
09:55 sima: ah no it is nicely documented, just not where I looked :-P
09:57 jani: airlied: sima: ack for enabling most W=1 warnings by default across the subsystem? https://lore.kernel.org/r/b3f9cfa3304e4db1a964ec962dc0974857c0edf0.1706797803.git.jani.nikula@intel.com
09:58 sima: jani, I'm assuming we're currently clean? also kinda wondered why there's not a patch to remove the stuff for i915/amd, or at least reduce it to the delta ...
09:58 sima: but yeah ack from me, but imo needs a bunch of the major drivers (amd and msm would be good I guess) on board too
09:58 jani: sima: I've tried with the configs in drm-rerere, x86-64 (gcc and clang), arm, arm64
09:59 jani: and it's clean
09:59 jani: I've merged a handful of patches for that
09:59 jani: dropping the extra warnings from i915 and amd Makefiles would follow
09:59 sima: yeah I thinkj that should cover compile testing
10:00 sima: jani, ah good, then just add those two bits to the commit message and should be good
10:00 jani: kernel test robot also didn't complain (on the previous version, no reply yet on the latest)
10:01 sima: maybe an ack from one of the drm-misc maintainers would be good too, the more the merrier
10:01 jani: tzimmermann: mripard: mlankhorst: ^
10:04 mripard: pq: sorry, spent too much time reading the HDMI spec. It's what we call RGB888 :)
10:04 mripard: jani: ack
10:04 pq: 4:4:4, I know :-)
10:40 mripard: jani: do you know what the semantics of the Broadcast RGB property were meant to be? in particular, swick[m] had some questions I couldn't answer
10:40 mripard: https://lore.kernel.org/all/20240115143308.GA159345@toolbox/
10:40 mripard: and https://lore.kernel.org/all/20240115143720.GA160656@toolbox/
11:05 jani: mripard: replied on the list, hth
12:28 mripard: jani: thanks!
13:04 mripard: jani: sorry, I just replied to a subthread without realising you weren't part of it: https://lore.kernel.org/dri-devel/73peztbeeikb3fg6coxu3punxllgtyrmgco34tnxkojtsjbr3s@26bud3sjbcez/
13:28 jani: mripard: would have to read the specs again... unless vsyrjala remembers this ^
13:32 mripard: the spec allows it (Section Video Quantization Range, section 6.6 in the hdmi 1.4b spec)
13:32 mripard: but judging from https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/i915/display/intel_hdmi.c#L2158 there's a limitation of the driver /hardware
22:49 mareko: what is with gitlab that it doesn't send some MR emails anymore?
22:49 mareko: how are we supposed to track when a new merge request is created?
22:50 jenatali: mareko: Are you subscribed to labels? Or were you just getting emails for every MR?
22:50 mareko: jenatali: on the project page, I press the bell and select which notifications I want to receive via email
22:52 emersion: mareko: when did that happen?
22:52 emersion: we had email issues yesterday
22:52 emersion: but should be fine now
22:52 mareko: emersion: during the last 1-2 weeks
22:53 emersion: did it happen again today?
22:54 mareko: no idea
22:57 mareko: also we have 147 labels, we don't need that many, how about we reduce them to ~30
22:58 jenatali: I do see some that are probably unused, but I think most of them do actually get used. I think you can propose to drop some but you'll probably get push back
23:25 mareko: zmike: is it possible to lower vertex formats in VS for zink? just curious