00:04 airlied: gfxstrand: got the latest firmwares to work, so going to see if I can get Linus to allow it in 6.7 which might be a stretch
00:04 airlied: the tlb invalidation will probably have to go with the big hammer fix for now
00:06 airlied: gfxstrand: you planning on nak by default once it merged?
00:06 daniels: NAK for all
00:07 gfxstrand: airlied: NAK for Turing+
00:07 gfxstrand: I want the default config to be the conformant one
00:07 gfxstrand: We'll fix bugs from there
00:09 gfxstrand: Once I figure out warp barrier spilling, we should be able to get 1.1
00:14 gfxstrand:makes supper
00:15 DavidHeidelberg:thanks for breaking his brain which has special category for a NAK
00:17 DavidHeidelberg: wish I could NAK NAK name; Thanks got we have Salad, right mupuf ? Now only Nah, Yes, No, Aladeen and Hello remains as a available names.
00:18 DavidHeidelberg: ok, I was too harsh, we have these options also in all other popular spoken languages :D
00:51 Company: is there a good way to autodetect if a device runs better with Vulkan or with GL?
00:51 Company: I'm trying to figure out how to choose between my 2 renderers
00:52 HdkR: Microbench your renderer at runtime and select
00:55 Company: not sure that's a good idea with GTK - the demands of apps vary a lot
00:55 Company: and usually the thing people worry more about is which one has fewer bugs
00:56 Company: Gnome Settings is fast enough either way
00:58 HdkR: That's the problem, "apps vary a lot." A render path that is faster on vulkan versus GL on one hardware and driver combination could easily change for either hardware or software changing
00:58 Company: I am very aware
00:59 airlied: I'd just pick vulkan where it exists
00:59 airlied: and move forward
01:00 Company: I think medium-term that's definitely the best way
01:01 Company: but I wonder if it's the right time for that yet
01:01 airlied: at least for all the desktop vendors it is
01:01 airlied: on mobile if you are on qualcomm it's probably fine
01:02 airlied: not sure on non-Linux
01:03 Company: macos doesn't have Vulkan ootb
01:03 Company: and on Windows, I suspect preferring Vulkan works, too - because the bad driver vendors don't ship Vulkan?
01:04 HdkR: Qualcomm is just starting to ship Vulkan there, not available on any current WoA devices there :)
01:04 airlied: yeah I think it's mostly fine if you have vulkan use vulkan
01:04 Company: I suppose I should bring that up internally too wrt RHEL10
01:13 Company: a benefit of keeping GL is that the rest of the stack uses GL, too - compositor and XWayland
01:13 Company: so GTK won't be the odd one out
01:31 gfxstrand: Do wraps not work in the CI build containers?
01:31 gfxstrand: NAK kinda depends on them for crates to work
01:36 gfxstrand: Ah, --wrap-mode=nofallback. Well, that's not gonna work...
01:37 gfxstrand: We'll have to chat about what to do about that in the morning
01:40 cmarcelo: for those familiar with hawkmoth/doxygen, is there an equivalent of "@file" section?
04:54 DemiMarie: gfxstrand: distributions will hate you if they cannot build in nodownload mode. Fedora at least requires building against system packages.
05:12 DemiMarie: From a distribution PoV, C not having an easy way to use third party dependencies is a feature, not a bug. It means that programmers use dependencies sparingly.
05:15 DemiMarie: If you really want to make distro maintainers upset, have a security patch that bumps a dependency major version to something not in the distro, so the distro now has to bump that dependency and risk breakage.
05:16 DemiMarie: Personally I think Mesa should at least bundle LLVM but distros tend to not like that.
05:21 DemiMarie: Distros, especially LTS ones, prefer few and slow-moving dependencies, as that means less work for the distro vendor.
08:24 daniels: gfxstrand: —force-fallback-for?
08:33 MrCooper: DemiMarie gfxstrand: FWIW, Debian package autobuilders have no network access
09:58 karolherbst: gfxstrand: fyi.. I kinda wanted to land https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22580 but you also have this new MR messing with indirects, and I was wondering if we should just leave glsl_get_length alone...
11:38 alyssa: jenatali: https://gitlab.freedesktop.org/mesa/mesa/-/issues/8635#note_2151669 thoughts?
11:39 alyssa: ideally we could get that warning caught in gcc/clang so it's hit before marge hits it
11:39 alyssa: failing that can we allow the warning in ci?
11:40 alyssa: ./src/compiler/spirv/spirv_to_nir.c(7277): error C2220: the following warning is treated as an error
11:40 alyssa: ../src/compiler/spirv/spirv_to_nir.c(7277): warning C4047: 'return': 'bool' differs in levels of indirection from 'void *'
11:40 jenatali: Yeah I would've expected GCC to hit that too
11:40 alyssa: wild.
11:41 alyssa: not upset about this one
11:41 alyssa: mostly. confused lol
11:41 jenatali: Werror has been useful for me, I don't want to turn it off
11:46 alyssa: you are valid ^^
13:21 gfxstrand: daniels: Oh, nice! Let me give that a go
13:24 gfxstrand: DemiMarie: I plan to keep the number of dependent crates small. However, there is a suite of 4 crates that is basically required if you want to write proc macros. If distros are going to have any mechanism at all for packaging crates, they'll package those 4.
13:28 gfxstrand: daniels, DavidHeidelberg: Any ideas why my update to the CI script won't marge?
13:28 gfxstrand: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25999#note_2151305
13:28 gfxstrand: It looks like CI is failing because there's nothing to CI.
13:29 daniels: gfxstrand: oh, hilarious, guess there's a crevice where it doesn't create any pipeline
13:30 daniels: the rules filter down to only the jobs which need to be run, but ... nothing needs to be run
13:30 daniels: you could either go through test-source-dep.yaml and find something to stick it on, or just roll it into your next MR
13:36 pq: hwentlan__, bwt. did Mario Kleiner ever tell you about their unsigned int 16 bpc research displays, and driving them with false-color mode because KMS hardware just can't do that deep?
13:38 pq: and that Linux is currently the best OS for driving those displays in spite of all the unknowns in KMS
13:39 vsyrjala: mario added proper 16bpc formats to kms at some point. i should probably get the i915 supported merged finally
13:40 pq: can HDMI, DVI-D or DP actually carry 16 bpc RGB?
13:42 vsyrjala: DP can, in theory. HDMI 2.0 has "16bpc" 4:2:0 iirc
13:42 pq: is there i915 hardware that can deliver 16 bpc to display, too? or would the kernel driver somehow encode that as 8 bpc double-wide image or something?
13:44 pq: I understood that Mario has displays that expect 8 bpc double-wide image ("false-color"), and display that as 16 bpc single-wide image.
13:54 vsyrjala: i don't think we have support for 16bpc output even in the latest hw. so yeah, you'd still need magic tricks to make it happen
14:01 gfxstrand: dcbaker: Could you glance at the top half-dozen patches or so of my NAK MR when you get the chance. It's building in CI now and I would love to assign it to Marge. :)
14:01 gfxstrand: But I'd also like review in case I'm committing grave meson or CI sins.
14:01 gfxstrand: I just threw the CI and meson tags on it too in case someone else wants to take a look
15:44 dcbaker: gfxstrand: Reviewed. It looks like everything else I'd noticed had already been spotted by other people. I had one minor question, but otherwise things looked good to me
16:13 gfxstrand: dcbaker: You happy with daniels' answer?
16:15 dcbaker: gfxstrand: yeah
16:15 dcbaker: locking to an RC makes me nervous, but I guess it isn't too big of a deal to update it to a non-rc later
16:15 gfxstrand: Would you look at that! I have a 32-bit driver :tada:
16:15 gfxstrand: dcbaker: Yeah, I'm fine with bumping to a real version the moment the RC is done.
16:17 dcbaker: sounds like a plan to me
16:17 gfxstrand: I should probably test said 32-bit driver before I declare total victory but the fact that it linked is encouraging.
16:19 alyssa: dcbaker: btw, is clc on i386 going to kabloom?
16:20 dcbaker:hopes not
16:22 alyssa: k
16:22 alyssa: ty
16:26 gfxstrand: Okay, we're assigning this mess to Marge.
16:27 gfxstrand: Looks like there's two things ahead of it in the queue.
16:27 gfxstrand: Something something a watched MR never merges...? ¯\_(ツ)_/¯
16:29 alyssa: real
16:55 mattst88: I'm working on updating vulkan-cts from 1.3.6.0 to 1.3.7.1 in ChromeOS and 1.3.7.1 seems massively slower than 1.3.6.0 -- is that known or expected?
16:56 Sachiel: shader object tests got added there, I think
16:56 Sachiel: so there's roughly double the number of tests
16:56 mattst88: okay, thanks
16:57 Sachiel: my usual deqp-runner runs on one machine went from ~1:10 hours to ~2. 50 extra minutes of largely NotSupported tests
16:57 mattst88: looks like on a TGL 1135 the estimated duration goes from 1:15 to like 5 hours :(
16:57 Sachiel: that... is a bit too much
16:57 daniels: mattst88: yep, can confirm
16:58 daniels: that's the fast one too. 1.3.7.0 was worse
17:00 mattst88: ouch
17:03 mattst88: are there any significant perf improvements in deqp-runner since 0.16.1?
17:18 gfxstrand: mattst88: Yeah, ESO did a number on the CTS
17:19 DemiMarie: Why do e.g. browsers not have VA-API support?
17:30 alyssa: 7
17:30 alyssa: the number it did was 7
17:30 alyssa: ("7 what?" "7.")
17:32 mattst88: DemiMarie: I think FF and Chrome do
17:35 DemiMarie: mattst88: Chrome doesn’t support it officially.
17:37 DemiMarie: How useful is acceleration for free codecs only.
17:39 DemiMarie: If acceleration with free codecs only is not worthwhile, then the answer is probably flatpaks from places where software patents are invalid.
17:45 Lynne: it's useful now that av1 has become somewhat widespread
17:47 gfxstrand: dcbaker: It'd be cool if you could take one more look at the top patch.
17:47 gfxstrand: Unless you trust me to write meson...
17:47 gfxstrand: (Narrator: He really shouldn't)
17:48 gfxstrand: If you're happy with that, I'll rebase it in so my git branches never existed
18:02 jenatali: Ugh. Why is there a "create merge request" button on an issue? How is that ever a useful thing to do straight from an issue page?
18:07 gfxstrand: I don't know...
18:10 daniels: it's primarily intended for one-liners and smaller changes, where you can usefully and quickly do it from the web IDE
18:10 daniels: Mesa is obviously not that project
18:20 Company: I use it for docs typos or updates of links in docs all the time
18:23 jenatali: I mean, I get going to the web editor first and creating a MR from there, but starting from an issue seems wrong 🤷‍♂️
19:07 greenjustin: DemiMarie: Chrome definitely uses VA-API. https://source.chromium.org/chromium/chromium/src/+/main:media/gpu/vaapi/
19:20 HdkR: Would be nice if Chrome had runtime selection between vaapi and v4l2 rather than compile time
19:23 greenjustin: Are there any devices that support both simultaneously?
19:23 HdkR: Bigger issue is packaging, you have to select one versus the other
19:25 gfxstrand: Are there non-Intel devices that support va-api?
19:25 greenjustin: Ah, I see why that would annoying for mainline.
19:25 greenjustin: AMD
19:26 gfxstrand: I mean, generally anything you're likely to see on x86 isn't going to have v4l2 and anything you're likely to see on arm isn't going to have va-api
19:26 gfxstrand: So it's maybe not as big of a problem as it sounds
19:26 gfxstrand: It's still pretty terrible that they have code for both and can't select at runtime.
19:28 greenjustin: Cuts the binary size a little I suppose.
19:29 mareko: VAAPI is the main video API for AMD
19:29 airlied: vulkan video will solve it all :-P
19:30 mareko: ok, I'll hold your beer (and drink it)
19:31 greenjustin: I think we just need more video APIs in general. Two isn't enough to maintain, we gotta pump up those numbers :-P
19:32 mareko: 3
19:32 mareko: VDPAU and OpenMAX
19:32 mareko: and the latter is required by Android
19:32 mareko: and then Vulkan, so 4
19:33 greenjustin: Still too few. We need at least a dozen competing standards imho.
19:33 anarsoul: mareko: NVDEC/NVENC?
19:33 mareko: 4 non-vendor-specific ones
19:33 anarsoul: and for v4l2 there are stateful and stateless decoders
19:35 greenjustin: Yeah and I think you can make the case that stateful V4L2 isn't exactly a single API
19:35 Company: https://trac.ffmpeg.org/wiki/HWAccelIntro#PlatformAPIAvailability says you've seen nothing yet
19:36 mareko: I've seen AMF, that's enough for me
19:37 mareko: it should say Y for VAAPI on AMD
19:37 Company: mareko: while you're here and talking about video stuff
19:38 Company: mareko: I've been playing with imprting dmabufs into EGL/Vulkan and AMD has this annoying stride limit
19:38 mareko: indeed
19:38 Company: mareko: what's the recommended way to deal with that?
19:38 mareko: set it to 256
19:38 Company: assuming I can't do that
19:38 mareko: or rather aligne to that number
19:39 Company: because I get the dmabufs from pipewire or wherever
19:39 emersion: ideally there would be stride negotiation
19:39 airlied: tell them to set it to 256
19:39 Company: also, how would I know that requirement? Vulkan and EGL don't tell me - or I haven't found it
19:40 emersion: (1) travel to the future (2) use buffer allocation constraints
19:40 airlied: I think it's one of those just make everyone use 256, and hope hw manufacturers don't go 512
19:41 mareko: gfx6-9 can set any stride that's reasonable (not byte alignment by small enough that it shouldn't bother you), gfx10.1 (Navi1x) must use 256 alignment, gfx10.3-gfx11.x can set any N*256 alignment, in the future it will be dropped to N*128
19:42 mareko: *but small enough
19:43 mareko: you can also import the image as a buffer and do your own addressing in the shader
19:43 Company: in Vulkan I can probably also allocate a new image and doing a buffer copy
19:44 mareko: that too
19:44 Company: but I was mostly wondering what the recommended way to deal with it is from your side
19:44 Company: so I don't implement something that's considered a bad idea
19:45 mareko: the stride alignment is a hw constraint, nothing you can do about
19:45 Company: is 256 the highest one there is?
19:46 Company: or do some drivers require even more?
19:46 airlied: the recommended way is to realise we screwed up and go back and add stride negotiation
19:46 airlied: but now 256 seems to be where things are at
19:47 Company: I'm considering filing bugs against pipewire etc to make all its plugins use 256
19:47 mareko: the best workaround is to set the image width in bytes to N*256 in the source device
19:47 gfxstrand: We hard-code 256 lots of places
19:47 gfxstrand: Is that good? No. Does it work? Yes.
19:49 Company: so the best solution is (1) try and make everyone use 256, (2) write a generic fallback that handles the cases where that doesn't work
19:49 mareko: yes
19:51 mareko: (3) get a time machine and tell hw folks what to do 7 years ago
19:52 gfxstrand: And hope they listen. (-:
19:52 Company: ndufresne: ^^^ backlog of last 15 minutes might be interesting for you
19:55 ndufresne: oh
19:59 ndufresne: Yeah, you can try and do system wide 256, happy patching though ;-P
19:59 ndufresne: V4L2 have stride negotiation, but some highly used driver don't implement it for no good reason (UVC)
20:00 ndufresne: I'm not really aware of HW that can't deal with that kind of alignment, but CODEC and blitter engineers can be creatives
20:01 ndufresne: and you basically depends on driver maintainer to fix it here ;-P
20:01 Company: ndufresne: it's mostly about "if given the choice, make sure that choice is taken"
20:02 Company: once it's common enough, people will remember to do it automatically
20:02 ndufresne: yeah, "if given the choice"
20:02 ndufresne: you might hit a wall with ARM devs, that consider RAM precious
20:02 ndufresne: (even though the RAM delta here is marginal I think)
20:03 Company: my camera does 640x480 - that'd be 20% extra
20:03 ndufresne: anyway, this "idea" will require tones of patching, its possible, but not as easy as when everything is concealed into mesa
20:03 gfxstrand: 256B, not 256 pixels
20:04 ndufresne: if you camera do I420 ?
20:04 Company: gfxstrand: everything uses NV12
20:04 gfxstrand: Right...
20:04 gfxstrand:is thinking RGBA8
20:04 ndufresne: kind of, cameras more naturally do packed, like YUY2
20:04 gfxstrand: but noooo those fancy video people and their YUV formats...
20:04 gfxstrand: hehe
20:04 Company: I think most drivers handle RGBA8 fine
20:04 Company: with any stride
20:05 ndufresne: in CODEC, sometimes reference frames format is stiff, but most of the time you endup using post processed buffer, and these are usually very flexible
20:05 jenatali: gfxstrand: Windows has va-api support now, including a VaOn12 video mapping layer :)
20:06 ndufresne: indeed, saw couple of gst patches recently
20:06 Company: though all the RGBA8 I got so far was from inside Mesa - with a few exceptions where I manually created something with /dev/dma_heap
20:08 ndufresne: which make sense no ?
20:09 ndufresne: cameras and codec all works mostly in YUV, and VA postproc are most of the time implemented by Mesa (on AMD I think these are just shaders)
20:10 daniels: jenatali: woah, vaon12 shipped?
20:10 Company: still, it's a bit meh that stride 1 works for R8 buffers, but not for NV12
20:10 jenatali: Yep
20:11 jenatali: daniels: https://devblogs.microsoft.com/directx/video-acceleration-api-va-api-now-available-on-windows/
20:23 kisak: jenatali: it's probably nothing but ... devblog has LIBVA_DRIVER_NAME=vaon12 [...] vaon12_drv_video.dll and looking at my mesa build log, I see /usr/lib/x86_64-linux-gnu/dri/d3d12_drv_video.so in mesa-va-drivers https://launchpadlibrarian.net/689693254/buildlog_ubuntu-lunar-amd64.mesa_23.2.1~kisak1~l_BUILDING.txt.gz
20:25 jenatali: kisak: I believe the Windows target is different than the Linux target, yeah
20:25 gfxstrand: jenatali: Vulkan video in dozen when?
20:25 jenatali: I haven't looked at it... might be easy, might be nigh impossible
20:26 kisak: oh, that's where my undercaffinated brain misfired, win32/windows versus WSL2/windows. Oops.
20:26 jenatali: gfxstrand: As for when, once someone important needs Vulkan video
20:27 jenatali: kisak: Right, this blog is primarily about native Win32 support. Pretty sure we had a different one a while back for WSL video hardware acceleration
20:28 jenatali: Oh, "a while back" being 2 days earlier lol
21:00 daniels: jenatali: nice!
21:24 kchibisov: Is it valid for glGetString to return a NULL?
21:25 karolherbst: yes
21:25 karolherbst: "If an error is generated, glGetString returns 0. "
21:26 kchibisov: huh, I was searching for NULL or something, but it just says 0 for pointer.
21:26 kchibisov: ¯\_(ツ)_/¯
21:39 mattst88: FWIW, it looks like the number of tests executed in vulkan-cts-1.3.6.0 is 1077400 and the number in 1.3.7.1 is 3974726 /o\
21:52 jenatali: That's a big oof
21:53 airlied: yeah cts itself spend a lot of time just generating test names now
21:53 airlied: make sure to build release cts, otherwise you hit this horrible string compare of every test name at start
21:56 robclark: mattst88: related, https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26015 .. hopefully in the slightly longer term deqp prunes some tests
21:59 mattst88: interesting, thanks
22:40 robclark: alyssa: ../src/asahi/clc/meson.build:11:18: ERROR: Unknown variable "idep_mesaclc".
22:41 jenatali: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/51124087 :(
22:44 robclark: alyssa: fwiw, might be related to having -Dtools=all but not something else (tools=all was what was pulling asahi into the build)
22:52 kode54: who gave intel tests only 30 seconds
22:53 alyssa: robclark: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26017
22:53 alyssa: if that fixes please merge
22:55 robclark: looks plausible.. lets see
22:59 robclark: yeah, that does the trick..
23:00 robclark: I guess -Dtools=all could be a bit more clever about not building tools for drivers that are not built, but that is probably more than a couple line fix (and pre-existing bug/misfeature)