01:42 alyssa: mupuf: oh i'm on the list uh cool i guess? :P
01:42 alyssa: sounds like big responsibility ;p
01:45 HdkR: The list is filled with cool people, but not all cool people happen to be on the list :P
01:47 alyssa: HdkR: jealous? :p
01:49 HdkR: Oh I'm not cool, so it would be hard to get on it
01:50 HdkR: Would need to put a # comment above my alias for "Random JIT gremlin"
01:55 psykose: you are giga cool
01:57 HdkR: :O Right in the feels
02:54 alyssa:can't tell if anything will break if she drops support for all luminance/alpha/intensity formats
02:54 alyssa: mesa/st seems to be able to emulate them, at least the piglits seem to pass.
02:55 alyssa: really not in the mood to carry around known broken support for desktop GL only functionality
02:55 alyssa: if we could just
02:55 alyssa: not
02:56 alyssa: (Is there a performance implication?)
03:00 alyssa: zmike: ^ I see that you added emulation for this stuff to both mesa/st and Zink
03:00 alyssa: so i'm not really sure how this is supposed to work or not
03:00 alyssa: oh.. this was for Nine... mhh
03:01 psykose: drop nine and make it a paid subscription
03:01 alyssa: psykose: big brain
03:02 alyssa: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6907 makes me want to say "the next person who wants this for panfrost should fix nine" ...
03:03 alyssa: nominally we have native formats for this stuff, but removing all the advertisements is making my unexpectedpass piglit shoot up ;-)
03:03 zmike: what
03:03 zmike: zink emulates them and you can too
03:03 alyssa: zmike: what if i just didn't though
03:04 alyssa: have you considered that
03:04 alyssa: huh
03:04 zmike: nobody would care since nobody uses panfrost for desktop GL
03:04 zmike: delete away!
03:04 alyssa: unfortunately that's false
03:04 zmike: mood
03:04 alyssa: although nobody does seemt o use panfrost for nine (yet?)
03:05 alyssa: there's interest for it that i'm sympathetic to for the older hw that we won't do vk on
03:05 zmike: nine has a lot of work pending
03:05 zmike: but A8 support isn't part of it
03:05 alyssa: hmm I guess most of the heartburn is from luminance/alpha being renderable
03:06 alyssa: 03:05 < zmike> but A8 support isn't part of it
03:06 alyssa: is this *only* about A8?
03:06 alyssa: or other alpha formats too?
03:06 alyssa: what about intensity and luminance-alpha?
03:06 zmike: that ticket? yes
03:06 alyssa: nine support in general
03:06 alyssa:reads the code
03:06 zmike: A8 is the only one needed by nine afaik
03:07 alyssa: i forgot it's open source that's neat
03:07 DemiMarie: What is so bad about nine?
03:07 zmike: haha yeah weird who would do such a thing
03:07 alyssa: DemiMarie: what's that replying to
03:07 alyssa: my shitposts or mikes?
03:07 DemiMarie: both, I guess?
03:07 alyssa: i don't have anything against nine
03:08 alyssa: i just can't fathom a possible reason you would ever use it with panfrost
03:08 zmike: nine is bad because it's not a power of two
03:08 zmike: obviously
03:08 alyssa: very true
03:08 DemiMarie: didn’t ARM have some really buggy GPUs?
03:08 alyssa: yes
03:08 alyssa: and?
03:08 DemiMarie: whatever
03:08 psykose: is there a gpu without bugs
03:08 alyssa: not to my knowledge
03:08 zmike: you'd have to be insane to try and work on an ARM gpu haha lol XD
03:09 alyssa: wow mean
03:09 psykose: zink more like wine for mesa
03:09 zmike: it's okay the people working on apple hw are very sane
03:10 alyssa: 🥺👉👈
03:13 zmike: 🥳
03:29 alyssa: oh uh when did it become late o'clock
03:29 alyssa: time to stop piglitting
05:01 Lynne: the radv PS epilogue changes broke a proton game for me
05:03 ishitatsuyuki: Lynne, mind opening an issue? You can CC hakzsam
05:05 Lynne: I'm bisecting now
05:05 Lynne: it was 11469f7553dc69a6c4b779527e6738c3206aa21c
05:14 Lynne: hakzsam: https://0x0.st/o7vL.diff fixes it, I'm guessing graphics_pipeline->col_format_non_compacted has changed since binding
07:25 hakzsam: Lynne: thanks for the bug report, I will look into it
07:58 austriancoder:is looking for reviewers for https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20538
08:28 tzimmermann: mripard, morning. i did not r-b all of the patches in your recent vc4 patchset, because of questions. let me know if you want me to take another look
08:29 tzimmermann: if you have a bit, maybe take a look at the include cleanup v2 i sent recently. should be quick and easy https://patchwork.freedesktop.org/series/112542/#rev2
08:29 tzimmermann: thanks a lot
08:33 mripard: sure, I'm on it
10:18 jani: airlied: danvet: https://lore.kernel.org/all/877cxqg2na.fsf@intel.com/
10:19 danvet: jani, I've seen it, and assumed that this is not actually what's going to land ...
10:20 danvet: hm Lyude acked it
10:21 danvet: I mean living under a rock for half a year isn't the best of looks really
10:21 danvet: I guess I need to reply
10:22 dolphin: 6.1-rc1 timeframe would probably have been more reasonable to ask for revert
10:26 danvet: yeah I replied
10:26 danvet: tbf I deemed it silly enough that it'll die without me replying :-)
10:26 danvet: agd5f, airlied, Lyude ^^
11:06 tzimmermann: mripard, thanks
11:07 tzimmermann: mripard, but that's version 1. v2 is this here: https://lore.kernel.org/dri-devel/20230111130206.29974-1-tzimmermann@suse.de/ !
11:13 mripard: tzimmermann: ah, sorry
11:13 mripard: still a-b for the whole series
11:14 tzimmermann: mripard, ok thanks a lot
11:17 javierm: tzimmermann: I remember there was a kernel-wide effort to cleanup the header inclusion but don't know what happened to that
11:18 javierm: https://www.zdnet.com/article/cleaning-up-the-linux-kernels-dependency-hell-this-developer-is-proposing-2200-commit-changes/
11:18 tzimmermann: javierm, it was much applauded, but i never heard about it later
11:18 tzimmermann: has it been merged
11:20 tzimmermann: javerim, i'm still waiting for vfio devs to ack the one fbdev patch
11:20 tzimmermann: btw
11:21 javierm: tzimmermann: hmm, maybe just merge it then? I mean, you gave them a lot of time to answer :)
11:21 tzimmermann: yeah. i pinged them several times. no answer
11:22 tzimmermann: the change has no effect on the driver itself. should be find
11:22 tzimmermann: fine
11:22 javierm: tzimmermann: agreed
11:56 tzimmermann: i just found out that i can take patchwork's mbox file and pipe it into dim-apply-branch. it appears to do the right thing for each contained patch. amazing!
11:56 tzimmermann: thanks to whoever implemented this
12:07 javierm: tzimmermann: yes, that's what I do. Did you apply one by one before?
12:08 tzimmermann: i did.
12:08 tzimmermann: i didn't know that the mbox file would work
12:36 mripard: it also works from b4
12:37 mripard: I've been using it for a while, it's great
13:46 jani: so I can get the .c compiled to assembler using 'make path/to/file.s', but is there something similar to get the pre-processor output?
13:52 jani: 'make path/to/file.i' does something
14:28 agd5f: TMM, you sbios may have an option to pick which GPU the sbios uses for display if that is your concern
15:59 TMM: agd5f: it does not :(
16:58 alyssa: *squint*
16:58 alyssa: can't tell if driver bug or bad piglit
16:59 alyssa: using a signed `int` output with a _UINT framebuffer
17:00 alyssa: arb_shader_atomic_counters-semantics
17:02 jenatali: alyssa: What's the actual problem?
17:02 alyssa: jenatali: we tell the hardware "i32 input, but u32 output" and so the hw clamps negatives to zero
17:03 jenatali: Ah
17:04 alyssa: There's a workaround code path for TGSI (which sets untyped_colour_outputs)
17:04 alyssa: but I could have sworn this violates the GLSL spec
17:06 mareko: is passes here
17:06 alyssa: "If the values written by the fragment shader do not match the format(s) of the corresponding color buffer(s), the result is undefined."
17:06 alyssa: from the gl46 compat spec
17:07 mareko: I don't think our hw clamps that
17:07 alyssa: I can force untyped_color_outputs but that's really silly to do for a piglit that's relying on UB
17:36 zmike: probably just change the piglit
18:06 italove: What does it mean when _mesa_get_format_info() doesn't find a format? It doesn't seem to work for NV12 for me. Looking at `formats.csv` I only see two yuv formats, which are mapped to YUYV and UYVY in `formats.h`.
18:13 alyssa: italove: for historical reasons MESA formats are separate from PIPE formats
18:13 alyssa: even though we use the same enum values now
18:13 alyssa: NV12 textures shouldn't ever come from GL though, only from EGL
18:13 alyssa: so you probably don't need MESA formats for NV12
18:13 alyssa: I'm unusre why YUYV is there
18:14 alyssa: PIPE formats are defined by util/format/
18:14 alyssa: you'll notice that u_format.csv does have NV12
18:14 alyssa: as well as NV21, IYUV, etc
18:16 sravn: danvet: With all the old drivers gone it looks like we can gc all code that check for drm_core_check_feature(dev, DRIVER_LEGACY)
18:17 sravn: Or do I miss something obvious where we need it
18:17 italove: alyssa: maybe it's an issue with the piglit test I'm running then, because it does call _mesa_get_format_info() and leads to crashes
18:18 danvet: sravn, the plan is to gc in 1.5 years or so
18:18 danvet: assuming no one screams
18:18 danvet: essentially wait until this has all landed in lts
18:19 danvet: if we start deleting now and need to resurrect a driver, then resurrecting the legacy stuff might be pain
18:25 sravn: danvet: It sorta makes sense. But if reverting a driver removal is painfull, then maybe someone would be sufficiently motivated to update the driver (I am sometimes an optimist)
18:26 sravn: Anyway, I will bury my itch for now and leave the code in.
18:26 danvet: sravn, that sounds very optimistic
18:26 sravn: Lookign forward to see the comment thread on Phoronix when they pick up the removal
18:26 danvet: also note, that this are pure render drivers, display is userspace
18:27 danvet: which means this _only_ breaks opengl
18:27 danvet: and you're not going to get a gl1.x driver into mesa these days, that just aint happening
18:27 danvet: so "just update the driver" is not really a reasonable option
18:28 DavidHeidelberg[m]: gbm without dri, does it make sense as described in the MR? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20447
18:30 sravn: danvet: Ohh, that makes it difficult. I now remember that this was also a topic when I brought up openchrome some time ago - where I wondrered whay it was so much larger than the current kernel driver
18:51 ajax: danvet: which hardware is this about? the last userspace with any (strictly) ums 3d support was mesa 7.11, which was 2011
18:52 danvet: ajax, that kind of hw
18:52 danvet: unless something really funny happens we should be able to get away with this no problem
18:52 ajax: dude. if anyone wants to work on like g400 support and port it to kms, amber will happily take the driver
18:53 ajax: otherwise: go away
18:53 ajax: or just run the 11 year old kernel to go with your other >11 year old hardware
18:54 ajax: i did actually try to build mesa 7.11 with a modern fedora not long ago
18:54 ajax: it, uh
18:54 ajax: it didn't
18:58 ccr: unsurprising. even a lot newer versions can be a pain to build due to toolchain changes.
18:58 ccr: or dependency changes
19:02 ccr: heh. I remember one happy-fun-time regression bisect operation on a software (not mesa tho) that involved juggling autotools versions, some dep library versions, and also the configure parameters themselves had changed.
19:12 Lyude: danvet: yeah i'm very much not happy about it :\
19:13 Lyude: if we can figure out an alternative I'm really seriously all for it lol
19:17 Lyude: danvet: I can give another shot at trying to figure out a proper fix. for context: I spent like, over 2-3 weeks trying to figure this out and it got to a point I had to defer to amd because their driver is _really_ difficult to untangle and figure out ._
19:27 danvet: ajax, kernel is different about not regressing stuff, and we've had reports and shit even 5+ years after userspace stopped supporting something
19:27 danvet: or stopped using an old ioctl or whatever
19:27 danvet: so 10 years is the rule of thumb
19:27 danvet: and yes I know that mesa routinely gets away with much less
19:29 Lyude: danvet: btw responded on the list, I'll try again at figuring out a proper fix for this since I don't know how long it's going to take wayne to figure this out. maybe now that i'm a little burned out I'll figure it out
19:29 Lyude: *little less
19:30 ajax: are ci flakes tracked somewhat automatically these days?
19:44 alyssa: danvet: how does one get code review
19:44 alyssa: i remember why i learned to smash my code to marge
19:44 ajax: review for?
19:45 alyssa: anything
19:45 alyssa: Currently have 10 MRs to Mesa that are waiting for review
19:45 alyssa: mostly panfrost
19:46 alyssa: mostly from the last 24 hours I admit
19:46 alyssa: I guess patience is a virtue
19:47 jenatali: I feel that
19:47 HdkR: I feel that
19:47 alyssa: I feel-- wait that's weird nvm
19:47 eric_engestrom: ajax: grep for FLAKES_CHANNEL in src/**/ci/gitlab-ci.yml to find the IRC channel where the flakes get reported
19:48 ajax: eric_engestrom: oooh, tyvm
19:48 jenatali: Unless it's for Windows where we don't have a flakes channel set up...
19:49 ajax: alyssa: you should take the bait i left on that mipmap generation performance bug
19:49 ajax:looks to see what he can reasonably review
19:51 alyssa: ajax: oooh what bait I don't remember this
19:51 danvet: alyssa, enjoy w/e, assume wish fairies do the work while you relax, get mad on Monday because they didn't?
19:51 ajax: alyssa: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6868#note_1469614
19:51 alyssa: danvet: oh yeah ok
19:51 ajax: tl;dr: compute shader and subgroup ops to emit more than one miplayer at a time
19:51 alyssa: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests?scope=all&state=opened&author_username=alyssa&draft=no&not[assignee_username]=marge-bot (the set of stuff I want to see)
19:52 alyssa: ajax: that won't be efficient on Mali
19:53 ajax: i'd believe that for most tilers, tbh, if they only really have one write target per tile job
19:53 alyssa: "Using the OpenGL meanings of the terms, textures and framebuffers support
19:53 alyssa: Errr
19:53 alyssa: See the paragraph starting that
19:54 alyssa: TL;DR we need to do the write from frag shaders (not compute shaders) to get compression
19:54 alyssa: which matters more for mipmap sampling perf which is more important than mipmap gen perf
19:55 ajax: oof
19:55 ajax: okay hm
19:55 HdkR: Most hardware would want to do the write from fragment to get compression even
19:56 HdkR: Quite a new feature that compute image stores get compression
19:56 alyssa: I think new Apple hw can do it maybe
19:57 HdkR: ooo
19:57 HdkR: Nvidia and AMD it is only supported in the last two or three generations as well
19:58 HdkR: Matters less there because of big BW numbers though
19:58 alyssa: yeah
19:58 ajax: i assume there has to be a way to blit an uncompressed resource into an undefined one and get compression at the end, but that's probably a bunch of expensive flush and stall so maybe not worth it
19:58 alyssa: that sounds, more expensive?
19:59 ajax: is there not a way to write to multiple levels from fs?
20:00 ajax:spend embarassingly little time on the "writing things in opengl" side of opengl
20:03 HdkR: I wonder if you could bind a framebuffer that overlaps the full mipmap chain and generate it as a single RT
20:03 alyssa: please no
20:03 HdkR: Trying to think of something beyond *magic*
20:04 ajax: the trick is you want to write corresponding pixels in corresponding miplevels from the same shader invocation
20:05 ajax: because your fs is going to be invoked once per dest pixel
20:05 HdkR: MRT doesn't save you here sadly
20:06 ajax: if you bind a giant image over all the levels then when your coords put you in the smaller levels you have to do exponentially more sampling work
20:07 ajax: it'd be as if you built the smallest level directly from the largest
20:07 HdkR: Yea, it's not great
20:07 HdkR: But would it be faster than back to back FS invocations? :P
20:08 HdkR: And are the GPU's caches big enough to help out
20:08 eric_engestrom: DavidHeidelberg[m]: re: gbm without a builtin backend, yeah I think it's reasonable
20:19 alyssa: ERROR - Failure getting dEQP run results: parsing results: Reading from dEQP: timed out waiting for fd to be ready (See "output/c4.r1.caselist.txt")
20:19 alyssa: uh oh
20:25 CounterPillow: does this mean mesa is trying to maintain a list of every application that is not a video game? Doesn't seem scalable to me. https://gitlab.freedesktop.org/mesa/mesa/-/commit/a9c36dbf9c56b0d8b3810f7c95d44202bf79dac7
20:25 CounterPillow: That's beside the point that mpv would rather not be on this list, as 1. we present at a predictable framerate, 2. oddball video refresh rates make adaptive sync beneficial to us
20:36 alyssa: driconf? scalable?
20:41 HdkR: Application configs and scalability aren't ever a thing
20:42 HdkR: It's more likely the list was generated when initial adaptive sync support was added and there wasn't quite enough care to ensure every application handled it fine. A bit of an overreach
20:42 alyssa: this is so weird
20:42 alyssa: I can see the tests are running but deqp-runner isn't getting any input?
20:43 HdkR: stdin says nope today?
20:49 alyssa: seemingly
20:50 alyssa: I uprevved deqp-runner and it seems marginally better
20:50 jenatali: Urgh, somehow I force-pushed a wrong version of a patch into a MR and didn't notice at some point
20:50 alyssa: getting some inexplicable crashes, though
20:50 alyssa: Test case 'dEQP-GLES2.functional.lifetime.attach.deleted_input.texture_framebuffer'.. Pass (Pass)
20:50 alyssa: stderr: (empty)
20:51 jenatali: That's... a pass? Not a crash?
20:51 alyssa: jenatali: same
20:51 alyssa: deqp-runner was working this more..
20:53 alyssa: morning
20:53 alyssa: It's also 10x slower than it was..
20:53 alyssa: even though I'm seeing appropriately high CPU activity
20:54 alyssa: oh this is interesting
20:54 alyssa: sysprof says it's totally bound by disk_cache_evict_lru_item
20:54 alyssa: ugh. ok. I understand now.
20:54 alyssa:tosses out .cache/mesa_shader_cache
20:55 alyssa: and it works properly now. miracle ;-;
20:55 alyssa: getdents64 bound
20:57 alyssa: apparently that path isn't supposed to happen ;-;
20:57 alyssa: (the is_two_character_sub_directory path)
20:58 alyssa: possibly my "uprev mesa" script needs to torch the cache
21:11 HdkR: alyssa: Bounded by getdents sounds scary. How slow is that SSD? :O
21:16 jenatali: Anyone wanna ack a CI change? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20361
21:21 alyssa: HdkR: eMMC
21:22 HdkR: alyssa: I'm sorry for your loss
21:22 alyssa: appreciated
21:32 HdkR: alyssa: As a comparison point, my Snapdragon's eMMC peaks out at 20MB/s :|
21:33 HdkR: No wait, that's a USB 3.0 NVMe drive. wtf
21:41 kisak: looking at he adaptive sync blacklist from 4 years ago, it looks like it's from the initial implementation push of vrr in foss drivers. The blacklist handwavy needed to unblock the feature rollout without big regressions. There's a good chance other related parts have gotten healthier in 4 years.
21:45 alyssa: do I dare to try to set up Anbox or Waydroid
21:45 alyssa: or, god forbid, FEX
21:47 HdkR: alyssa: Trying to run closed source games? :P
21:47 alyssa: idk I can only play STK so many times
21:50 HdkR: whaaa, no way
21:51 Lynne: you haven't beaten q3dm17 yet, have you?
21:53 HdkR: I think more interesting is expanding the pool of games to test
21:53 alyssa: this reminds me I still need to get my hands on some Wii games