08:27 ayaka_: emersion, where I could send my concern and wish about Allocation Constraints? the dri devel mail list?
08:29 emersion: yeah, probably...
08:33 MrCooper: daniels zmike: FWIW, the container job spuriously passing despite the image push failing should be fixed with current ci-templates upstream
08:46 dolphin: airlied, sima: drm-intel-gt-next sent, one week later than usual due to the vacations erasing my memory of responsibilities, will still send one next week, hoping to backmerge drm-next early next week to bring in drm-intel-next patches to -gt-next
08:46 dolphin: as a dependency to series on -gt-next by Andi
08:59 sima: I guess I'll do some drm-next pr wrangling, there's 4 pending
09:10 sima: hm annoying conflicts in amdgpu
09:24 sima: agd5f_, some amdgpu conflict in your -next pr, please check that I didn't screw up before I add more
11:04 sima: oops only now noticed the drm-tip conflict, fixing it up
11:06 airlied: oops was that me? sordy
11:06 sima: airlied, nah I think it was me merging the amdgpu-next into drm-next
11:06 sima: that merge also had some conflicts, but now it's -fixes vs -next in amdgpu
11:07 sima: airlied, agd5f_ maybe we want a backmerge if drm-tip looks alright?
11:17 sima: ok should be fixed now
12:06 glehmann: how hard would it be for opt_algebraic to support conditions based on multiple source operands? something like (('op1', '#a', ('op2', '#b', 'c')), (replacement pattern), (a & b == 0))
12:36 alyssa: gfxstrand: i've got a nir patch for you to nak https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24397
12:36 alyssa: i mean, ack
12:36 alyssa:sweats
12:36 alyssa: :P
12:38 alyssa:should probably check radz
12:42 hakzsam: gfxstrand: any other comments on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24416 ?
12:42 pendingchaos: glehmann: probably not too difficult? it could be something like nir_search_helpers, except the function is given variables instead of alu instr
12:44 alyssa: note that nir_search_helpers is a potential shader compile-time problem
13:51 gfxstrand: hakzsam: Nope. VK patch looks good now
13:59 alyssa: gfxstrand: related -- https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24392#note_2028409
13:59 alyssa: you wrote that code, I don't know what I'm talking about O:)
14:06 MrCooper: alyssa: radz being the gen z fork of radv?
14:09 javierm: sima, pq, emersion: it would be great if you can chime in about https://lists.freedesktop.org/archives/dri-devel/2023-August/417590.html
14:10 alyssa: MrCooper: sure
14:10 alyssa: it's what i callzink-radv
14:10 alyssa: i've got aliases for all of them
14:10 alyssa: anz, radv, zurnip, azahi
14:10 zmike: pretty sure we agreed on zgxv
14:10 MrCooper: hehe, Freudian slip of radv though
14:11 alyssa: oops
14:11 alyssa: zmike: i thought it was going to be zvzz
14:11 zmike: znv, tz, rzdv, zgxv
14:11 zmike: vowels get out.
14:18 sima: javierm, I think if DRM_FORMAT_FOO is massively preferred by the hw for reasons, then adding support for DRM_FORMAT_XRGB8888->FOO conversion is ok
14:19 sima: I think all we need to make sure is that in that case XRGB8888 is the very last one in the format list or something like that
14:20 sima: javierm, what I'm really strongly against is if we add funny conversion tricks for anything else than XRGB8888 as input
14:20 sima: since that's just combinatorial explosion madness
14:20 sima: also for these tiny vram gpus we essentially treat the vram as the output hw framebuffer that we manually upload, so *shrug*
14:21 mripard: sima: it's not even that, there's already support for both RGB888 and XRG8888, but because DMA is so slow it does a memcpy
14:21 sima: javierm, I think when the gem bo was still in vram that would have been a solid case against doing copy tricks for XRGB8888 or so
14:21 mripard: jfalempe patches just makes that memcpy ignores the X component that's going to be ignored anyway
14:22 sima: mripard, I thought the memcpy was because the vram is so limited that we can't really support the full kms api with it's "all the buffers userspace wants" approach?
14:22 mripard: jfalempe was saying that a DMA transfer is slower than a memcpy on most platforms
14:23 javierm: sima: I think so, yeah. Otherwise the driver could use TTM as far as I understand
14:23 mripard: so there might also be due to a size limitation, but it also impacts the performances a lot
14:24 javierm: sima: we all agree that no other "virtual" format should be exposed but XRGB8888 (and only for compat reasons) but the question here is if is OK for drivers to drop the alpha channel
14:25 javierm: sima: what I suggested jfalempe is to post a patch documented that "only XRGB8888 rule" and also could mention that dropping the alpha channel in the driver for perf reasons could be acceptable
14:25 jfalempe: sima, DMA is 3x to 10x slower on most mgag200 hardware.
14:26 sima: javierm, imo the "only XRGB8888" rule is the important thing
14:27 MrCooper: "drop the alpha channel" doesn't make much sense, since XRGB8888 doesn't have an alpha channel in the first place; the question is whether or not the driver is allowed to use a different format internally
14:27 sima: the "drop the alpha" is imo irrelevant, since whether we upload over spi/i2c or pci bus to the framebuffer memory kinda doesn't matter
14:27 sima: MrCooper, yeah plus that
14:28 sima: mgag200 is essentially like one of these manual upload panel drivers we have plenty of, except the bus is a notch faster than i2c/spi :-)
14:28 javierm: MrCooper: right, I meant drop the X channel (how is that called? opaque channel?) but agree with you that if driver is allowed to convert for perf reasons or not
14:29 javierm: because AFAIU the only XRGB8888 rule was because user-space has no way if the format exposed is native or not, and so wouldn't have to get a perf hit due format conversions
14:29 javierm: *no way to know
14:29 MrCooper: to me it seems like a no-brainer, the "no implicit format conversion" rule was well-intended but backfires in this case for no benefit I can see
14:29 sima: javierm, jfalempe imo just document that for hw/drivers where XRGB8888 is not support or has a very bad cost in terms of upload/scanout bw it's ok to emulate it in the kernel driver, but _only_ for that format
14:30 sima: MrCooper, I think given how the driver works it still fits without exceptions
14:30 javierm: sima: that's my opinion too. The HW really supports RGB8888 and so the XRGB8888 is "emulated"
14:30 sima: since the driver doesn't expose the actual vram as buffers at all, from a kms pov that's a pure internal implementation detail of the display hw
14:30 sima: javierm, yeah agreed
14:31 sima: like from the overall hw+kms pov the buffer is in system memory and gets scanned out (well manual uploaded) over the pci bus to the display
14:31 sima: aint really any different than uploading with the cpu through some other bus than pci
14:31 sima: the fact that 20 years ago such hw would have been exposed as fbdev video memory directly is kinda irrelevant in todays kms world
14:32 sima: because 20 years ago also a lot more userspace bothered to support RBG888 or at least RGB565, because that was required so much more often
14:33 cedicactus: Maybe, there's no big work needed, maybe you are smarter dunno, but scip has event handler and display connector to controller docs, it has cnf reader and lp translator so tritons bitwuzla is fine for it, not in for working today, but will be dealing with it soon enough.
14:35 sima: javierm, I think the only clarification we really need is that it's ok to emulate XRGB8888 also in cases where it kinda supported, but just always a terrible choice compared to RGB888
14:35 sima: and so really aside from userspace compat, we really don't want it
14:35 sima:shrugs
14:36 javierm: sima: agreed. Thanks a lot for your comments on this!
14:38 sima: in a way by starting to emulate xrgb8888 we've tied our hands a bit, since now even fewer reasons for userspace to support more formats natively for these more oddball display drivers
14:38 sima: but I also think that's still the right pragmatic choice
14:40 javierm: sima: yeah. A prime example is the ssd130x driver whose native format is DRM_FORMAT_R1
14:40 javierm: I don't think that user-space would be interested in supporting monochrome :)
14:42 javierm: but jokes apart I don't know how much user-space nowadays support RGB888
15:13 MrCooper: I suspect 0 is a good approximation
15:22 macromorgan: is there any good way to identify a panel that has no otherwise discernable markings?
15:23 macromorgan: I need a compatible flag for a panel that's basically identical to panel-newvision-nv3051d, but it has different mode flags
15:34 dviola: I wonder if this implies bugs with the host opengl driver rather than virgl: https://gitlab.freedesktop.org/mesa/mesa/-/issues/9321#note_2024534
15:34 dviola: gerddie: thanks for looking into it btw
15:49 gfxstrand: hakzsam: Wanna trade reviews?
15:49 gfxstrand: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24497
15:49 hakzsam: sure
17:24 kallisti5[m]: anyone know if the XOrg Foundation membership gets us PCI-SIG docs?
17:25 kallisti5[m]: I want to look at OCuLink stuff to see how to model our PCI Thunderbolt detection. (aka, IsRemoteDevice or something instead of IsThunderbolt)
18:40 zmike: alyssa: is there a pass to lower 64bit new-style regs to 32bit?
18:41 pendingchaos: if those regs come from phis, I think there was a pass somewhere for lowering 64-bit phis to 32-bit
18:42 zmike: I've got a pass for it that works fine I was just wondering if there was anything in common
18:42 zmike: I don't think they're exclusive to phis tho
18:43 pendingchaos: (nir_lower_64bit_phis)
18:43 zmike: 👍
19:10 alyssa: yeah nir_lower_64bit_phis
19:10 alyssa: zink should only get regs from phis
19:28 zmike: that sounds like an adventure for next week's me
19:35 alyssa: gfxstrand: congrats ^_^
22:59 gfxstrand: https://www.collabora.com/news-and-blog/news-and-events/nvk-has-landed.html
23:00 zmike: 💪
23:00 psykose: congrats!
23:00 psykose: perhaps i won't regret not selling my 1070 during the crypto boom meme, eventually :D
23:01 gfxstrand: Oh, don't worry about selling your 1070. We'll never be able to re-clock those and get anywhere close to decent perf.
23:01 psykose: :D