00:01 Kayden: karolherbst: nir_lower_bit_size is wrecking ufind_msb: http://whitecape.org/paste/lower-bitsize.txt
00:02 Kayden: who even needs the top bits
00:16 Kayden:fixes and adds asserts
00:28 Kayden: karolherbst: testing https://gitlab.freedesktop.org/kwg/mesa/-/commits/nir-bitsize-fix in CI now, assuming it works I'll open an MR
00:28 Kayden: thanks a lot for catching that
01:00 jenatali: Oof
01:36 alyssa: Kayden: R-b, yiks
01:36 alyssa: yikes
02:06 DemiMarie: Will future versions of Wayland stop relying on DMA fences?
02:38 bl4ckb0ne: what do you mean
03:01 airlied: mlankhorst, mripard: who's on the fixes watch? I see some drm-misc-fixes I don't have yet
03:02 airlied: I'll hold sending Linus until tomorrow, hopefully someone can dequeue them
03:06 mupuf: daniels: the plan isn't to use netconsole (which is glorified syslog), the plan would be to make a TTY driver over TCP... Once the realtime guys finally land the printk rewrite to make consoles asynchronous
03:08 airlied: mupuf: that's tonights nightmare sorted :-P
03:08 mupuf: DemiMarie: you were proposing a usb-gadgets-based TTY? That's also an option, but I'm afraid some boards wouldn't support being the hosts
03:09 airlied: do arm boards even support usb debug port serial thingo?
03:09 airlied: the thing that needs the special dongle
03:09 mupuf: airlied: ROFL, are you talking about the printk rewrite or... Implementing a TCP version of that?
03:09 airlied: TCP version of tty :)
03:09 mupuf: USB on the go is quite common, but yeah
03:10 mupuf: Well, in the current state of TTY, no effing way this happens
03:10 airlied: https://www.codeproject.com/Articles/132313/How-to-Debug-the-Windows-OS-using-USB this thing
03:10 airlied:has one of those ajays devices, but used it once years ago
03:11 airlied: ah ehci debug port, that's the correct name
03:12 mupuf: Never heard of it!
03:12 mupuf: Will check it out
03:12 DemiMarie: airlied mupuf: XHCI also has a debug port
03:14 airlied: https://lwn.net/Articles/592921/
03:14 airlied: someone did try once :-P
03:17 mupuf: Ha ha, nice airlied :D
03:18 mupuf: I expected a loooot worse... but I'm sure the driver wouldn't work correctly right now for the reasons daniels listed
03:23 mupuf: xHCI debugging sounds interesting but seems read-only :s
03:24 mupuf: And it would once again require another cable... which is somewhat the point of having TTY over TCP: removing one third of the cables
03:24 mupuf: daniels, is your UART problem long term stability? If so, have you tried resetting the serial adapter between jobs?
03:25 airlied: I don't think it even makes it through a job sometimes
03:25 alyssa: ci is hard let's go shopping
03:26 mupuf: https://marc.info/?l=linux-usb&m=121459435621262&w=2
03:27 mupuf: Oh boy... I have some ultra cheap ones I have been using for the steam deck, they start crashing when their FIFO gets full
03:30 mupuf: But I don't ask nearly as much from them as LAVA does
03:33 mupuf: And my fallback plan if this failed would be for my initramfs (b2c) to replace stdin/out/err with a socket to the gateway... But that means no early debug messages
03:34 mupuf: Not that a USB console is much better: I had to add a hack in init.c to wait for /dev/console to appear because device enumeration is do damn slow
03:35 mupuf: So yeah, I have console=ttyUSB0 on some CI machines
03:35 mupuf: I have been dreading sending this patch... It's no different from the wait for root=... so there is at least a precedent
03:36 mupuf: https://gitlab.freedesktop.org/mupuf/boot2container/-/blob/master/patches/linux/0001-HACK-init-main-wait-up-to-10-second-for-a-console-to.patch
07:05 kode54: I would test VA-API
07:06 kode54: but nobody on the Xe KMD team wants to touch the <1000 LOC needed to upload firmware I need
07:06 kode54: there must be 3 methods of uploading HuC firmware then
07:06 kode54: because whatever the other cards are using, i915 calls "legacy"
07:15 dolphin: kode54: hardware has indeed changed over generations
07:22 kode54: I know
07:22 kode54: but like
07:22 kode54: the i915 driver refers to the GSC method as if it's the "new way" going forward
07:23 kode54: so apparently that idea was dropped on its ass by Intel?
07:25 HdkR: What's new becomes old
07:26 kode54: Thanks, Intel
07:26 kode54: guess I'll buy another Intel GPU and hope the story is better
07:27 kode54: the actual story looks like it's supposed to be "buy RDNA2 and nothing newer, or buy Nvidia"
07:28 HdkR: It's not a bad set of choices
07:31 kode54: noooo, I had to be one of the 3 people who bought an Intel Arc card
07:45 tursulin: mattst88: thanks, glad it is being found useful!
07:46 tursulin: Listing the clients would be like hello world level of complexity.
08:41 dolphin: <network connectivity level: Finnish train>
08:42 dolphin: kode54: Not sure I fully follow. Loading via GSC is for new hardware
08:43 kode54: then I guess the DG2 has a special way of doing it that's unique to the DG2
08:43 kode54: since the xe kmd devs opted to support tgl and similar but not dg2
08:43 dolphin: yeah, DG2 is in-between
08:45 dolphin: anyway, some parts of VA-API should work without HuC
08:48 kode54: oh
08:48 kode54: in that case, then I'm just waiting on someone at intel-media-driver to upstream something to support xe.ko
08:49 kode54: there was an attempt, but it was specific to tigerlake, and not really more than a proof of concept
08:49 kode54: maybe someone could poke the hornet's nest of an issue on the gitlab and tell all the people who ended up subscribing, that the HuC isn't really needed for most formats
08:50 kode54: at least not on DG2
08:51 dolphin: They should have a rather good table on the github page
08:52 dolphin: https://github.com/intel/media-driver/#components-and-features
08:52 hakzsam: anholt_: would you be able to reply here please ? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20024#note_1868955
08:57 dj-death: dolphin: yeah speaking of va-api & Xe
08:57 dj-death: dolphin: I guess there needs to be a plan for explicit synchronization
08:59 dj-death: dolphin: ChromeOS apparently ran into that issue with i915 : https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22937
08:59 dj-death: dolphin: but there is no way to do that workaround on Xe
09:43 dolphin: dj-death: I thought such a plan has been included from day one, at least it was extensively discussed
09:45 dolphin: ability to pass a list of BOs that would only be used for implicit sync, VM_BIND would still need to be used to bind those to the page tables
09:46 dj-death: ah right, flagging all imported BOs are external?
10:03 dolphin: dj-death: for the exact uAPI details you definitely want to check from thellstrom and mlankhorst
10:12 dolphin: I think my connectivity is bad enough that have to move to reading mail backlog. So talk to you later.
10:33 karolherbst: Kayden: well.. sadly that's not enough to pass the CTS 🙃 but it does fix a couple of failing tests
10:34 karolherbst: Kayden: ./build/test_conformance/integer_ops/test_integer_ops integer_ctz causes a similar issue where it asserts on bit_size == 32 in case you wanna fix that as well
10:55 Kayden: yeah looks like there's no lowering for that at all, adding some
10:56 LLM_puppy: exploring potential to use integrated GPU compute on arbitrarily large segments of system RAM https://0x0.st/HN7S.txt
10:59 LLM_puppy: hypothesis: Devices with inexpensive integrated GPUs (APUs) might be able to accelerate inference on models greater than 16-24GB in size, without expensive GPU hardware.
11:00 Kayden: karolherbst: added a patch which adds lowering for find_lsb to nir_lower_int64 and then updated the intel patch to use that too. test now passes
11:01 karolherbst: cool
11:02 karolherbst: the remaining fails are like 90% image related and it's clamping being wrong and now I remember why I wasn't bothering
11:03 LLM_puppy: I haven't seen this possibility addressed anywhere so i thought sharing the idea with people who know DRI might be productive. The key question is whether system memory beyond the fixed virtual VRAM defined in BIOS could be accessable to GPU. It seems the answer is 'yes' at least for some APUs.
11:03 Kayden: karolherbst: clamping being wrong?
11:04 karolherbst: border clamping
11:04 karolherbst: CL has insane modes there and requires 100% precision
11:07 Kayden: huh. thought we did all that right
11:08 karolherbst: unorm CL_ADDRESS_CLAMP is what's causing issues
11:08 karolherbst: which is `PIPE_TEX_WRAP_CLAMP_TO_BORDER`
11:08 Kayden: in core/memory.rs:1316 there's a TODO: what's a reasonable default? about translating sampler addressing modes to PIPE_TEX_WRAP... the spec says "The default is CL_ADDRESS_CLAMP." (PIPE_TEX_WRAP_CLAMP_TO_BORDER). you have clamp to edge...
11:09 Kayden: ah
11:09 karolherbst: ahh yeah.. guess I should change the default
11:10 Kayden: odd that we'd have precision issues with border
11:10 karolherbst: but the problem there is, it's a different default
11:10 Kayden: I wouldn't think there'd be any lossy conversions with unorm
11:11 karolherbst: by default I use CL_ADDRESS_CLAMP already, it's just what happens if the driver sees unknown values
11:11 Kayden: ah
11:11 karolherbst: that part should be unreachable anyway
11:11 Kayden: right, makes sense
11:12 karolherbst: I think the clamping is off by one pixel
11:12 karolherbst: intel has some weirdo workarounds in their driver
11:12 Kayden: oh, right, I think I heard about that
11:13 karolherbst: not sure if one of those landed or not
11:14 karolherbst: yeah.. don't think so
11:14 Kayden: have to sleep, unfortunately, let me know if you need any more help with stuff
11:14 karolherbst: gfxstrand has it on a branch somewhere
11:15 Kayden: oh right
11:16 karolherbst: can't find it :)
11:26 karolherbst: Kayden: https://gitlab.freedesktop.org/gfxstrand/mesa/-/commit/d6eb0b97d1f89915c7b36da51aaef8a633481f75
11:29 karolherbst: but I think this is another issue
11:30 karolherbst: anyway, doesn't make the issue go away
12:40 GreyXor: Hello, it's not about devel but i'm not sure where to ask. I have mesa 23.1.0 but rusticl don't work with my RDNA2 Rembrandt APU. Do I need to enable something ?
12:42 GreyXor: Switched to #rusticl
12:59 daniels: mupuf: yeah it's not a running-time thing, it's that there are about four buffers, and one of them periodically just stops draining, unless and until you powercycle the entire machine
13:01 mupuf: daniels: freaking amazing... and you can't replace that with a USB-based one? Too many of them are broken?
13:01 mupuf: doing the pivot seems tricky
13:03 daniels: mupuf: not really, no ...
13:03 daniels: the pivot is kinda tricky, but eh, it works, and it would've already been merged if we didn't hit timeouts on dozen
13:03 mupuf: sounds good :)
13:04 mupuf: and thanks for sharing the info
13:06 daniels: np at all - thanks to gallo for all the hard work really, I'm just the hype man
13:35 gallo[m]: daniels: this work would not advance without your review, so thanks
14:26 karolherbst: jenatali: there are some people arguing that calls like clFinish, clFlush and clWaitForEvents should flush all queues any event and all its dependencies belong to. I can kinda see this makes sense for clWaitForEvents, but not sure if that's also something we should do for clFinish/clFlush. How are you dealing with that stuff?
14:30 pq: melissawen, did anyone ever stop to think about what https://patchwork.freedesktop.org/patch/532706/?series=116189&rev=4 does to VKMS performance?
14:31 pq: the whole point of repeating the loops in the conversion functions was to avoid a function call overhead for each pixel
14:32 pq: mairacanal, did you ever do performance measurements on that ^ ?
14:52 jenatali: karolherbst: IIRC I do it for finish (since that implicitly waits for events) but not for flush
14:55 karolherbst: mhhh
14:56 karolherbst: but a flush without the deps also kinda doesn't make sense, because the events will just end up waiting on the deps anyway
14:56 karolherbst: but yeah...
14:56 karolherbst: dunno
14:56 karolherbst: it's kinda hard to tell if that's something which is actually mandated by the spec or not
14:59 karolherbst: I don't support out of order queues anway, so this is just a little change in the end, but still..
15:27 alyssa: gfxstrand: gentle ping on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23008
15:27 alyssa: If this is stupid I can close it but don't like stuff enstaleing
15:50 melissawen: pq, I don't know if anyone stopped to analyse performance there but you are bringing a good feedback that matches recent findings. mairacanal found a race condition issue on writeback job and it became more likely to happen after this patch you've pointed out. So, this change indeed affected the composition performance, I didn't stop to analyse how much.
15:52 melissawen: I'll take a time next week to check it with her. thanks for reporting
16:35 MrCooper: when hotplugging a USB-C dock to a machine, is fbcon supposed to show up on a monitor connected to the dock via DP alt mode?
17:04 mairacanal: pq, melissawen, I can perform some performance measurement next week and bring the results to you
18:01 mairacanal: I'll keep testing but some preliminary results with the IGT tests:
18:01 mairacanal: igt@kms_cursor_crc@pipe-a-cursor-512x512-onscreen - 11.4ms without the patch and 9.7ms with the patch
18:01 mairacanal: igt@kms_cursor_crc@cursor-rapid-movement-512x512 - 26.7ms without the patch and 24.5ms with the patch
18:02 mairacanal: igt@kms_cursor_crc@cursor-alpha-transparent - 20.5ms without the patch and 19.9ms with the patch
18:02 mairacanal: igt@kms_plane@plane-panning-top-left - 11ms without the patch and 11.3ms with the patch
18:03 mairacanal: pq, have you seem some downgrade in performance with the patch?
18:30 alyssa: Do we have any docs on the difference between pipe_image_view::access and pipe_image_view::shader_access
18:31 alyssa: Oh we do it's in the comment right above the struct
18:31 alyssa: I'm great at reading
18:38 rodrigovivi: lumag: are you sure about merging the patches through drm-intel-next? it might take a few weeks until that's on drm-next and backmerged to drm-misc.... but also we need some ack from airlied or sima .... another way is to have them all in drm-misc-next
18:39 rodrigovivi: airlied: sima: ack on get https://patchwork.freedesktop.org/series/114473/ through drm-intel-next?
18:39 sima:is on a very long w/e back on Monday :-)
18:39 rodrigovivi: jani: ^
18:41 alyssa: mesa/st doesn't set PIPE_BIND_IMAGE_VIEW anywhere does it
18:42 alyssa: *PIPE_BIND_SHADER_IMAGE
18:42 alyssa: how is this not broken on more drivers
18:46 lumag: rodrigovivi, Hmm. This way, it's up to you then
18:46 lumag: jani, rodrigovivi: I'm fine with whichever way works better for you
18:49 zmike: relying on bind flags is broken
18:50 zmike: everyone knows this
19:16 alyssa: zmike: surely zink is failing vvl over this
19:17 alyssa: create_bci only sets STORAGE_TEXEL_BUFFER_BIT if BIND_SHADER_IMAGE is set
19:20 alyssa: VUID-VkWriteDescriptorSet-descriptorType-00335
19:20 zmike: nah it's fine
19:21 zmike: see also the listed VVL exceptions in ci
19:21 alyssa: pardon?
19:21 zmike: CI uses VVL
19:22 alyssa: maybe VVL isn't checking this VU then
19:27 alyssa: oh, that VU is about buffers specifically, I guess
19:27 alyssa: still broken. not sure which VU then
19:27 zmike: I'll save you the time: zink passes the bind internally
19:28 zmike: but nice try finding bugs
19:28 alyssa: yeah I just found that
19:28 alyssa: thanks i hate it
19:28 zmike: 👍
19:29 alyssa: I don't think I can will myself to move that code to mesa/st.
19:29 zmike: I don't see how you could
19:30 zmike: nothing in GL knows how a buffer will be used on creation
19:32 jenatali: Woo 8 *_dxil intrinsics deleted so far
19:32 jenatali: Spring cleaning is great
19:33 alyssa: right, but the create new resource with the new bind + blit over the contents dance should be done in mesa/st rather than just passing broken flags
19:34 jenatali: Yeah but it really depends on which flags actually matter for the driver
19:34 alyssa: + possibly a "I don't care give me the pain" CAP that sets BIND_SHADR_IMAGE on everything at creation
19:37 alyssa: instead of just lying to drivers
20:18 airlied: rodrigovivi: ack
21:07 rodrigovivi: thanks
21:28 alyssa: anybody know if RGB32 buffers are supposed to be valid shader images (or just TBOs)?
21:30 alyssa: I don't see a format qualifier for them so presumably no
21:32 alyssa: yeah I don't think so, thankfully
21:42 zmike: they aren't
21:44 alyssa: :+1:
21:44 alyssa: zmike: so i have a mesa/st patch you're going to hate
21:46 zmike: can't wait
21:50 ccr: "I can feeeel your anger. it gives you focus, makes you stronger."
21:55 alyssa: zmike: ok, tell me why I'm a dum-dum https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23142
21:56 alyssa: prior art - 869e32593a9 ("gm107/ir: fix loading z offset for layered 3d image bindings"), which should probably be reverted and replaced with that MR + a 3 line driver patch
21:56 alyssa: karolherbst: ^
21:56 alyssa: oh wait you're on PTO
21:56 alyssa: forget I pinged
21:56 alyssa:unpings
22:37 karolherbst: alyssa: the issue is tiling
22:37 karolherbst: so if we do 2D operations on a 3D tiled image, we get random garbage
22:38 karolherbst: vulkan allows us to know this upfront as there is a flag for it indicating the application intents to use layers of a 3D image as 2D image views, so we can disable tiling on the z axis, but in GL that doesn't exist
22:41 karolherbst: The nvidia driver apparently detiles or something.. it's all very cursed
22:47 karolherbst: also.. 3D != 2Darray. Array textures kinda imply you don't want tiling on the z axis, where for 3D ones you kinda do
22:58 alyssa: oh, hm
22:58 alyssa: personally I would do detile in that case, but shrug
23:45 daniels: melissawen, mairacanal; thanks for bottoming out the race condition!