00:05 dcbaker: zmike: (because I'm not sure who else to ping) I've got "zink: fix compute shader leaks" marked as a Fixes for 23.0, but it's causing regressions: https://gitlab.freedesktop.org/mesa/mesa/-/commit/378071778702ccc0f752e9b2a77ec94e760763c1/pipelines?ref=staging%2F23.0
00:07 zmike: huh
00:07 zmike: I guess denominate
00:07 dcbaker: done
00:07 zmike: I thought it was backportable
00:07 zmike: my b
00:07 dcbaker: no worries
00:08 dcbaker: It compiles, which fits the old maxim: It compiles,ship it!
00:09 zmike: haha
00:09 zmike: amen
00:09 dcbaker: I believe you can thank Kayden for that one :)
02:19 mareko: Kayden: it missing Rbs
02:24 mareko: Kayden: fixing glthread is NOT a block for stable because glthread was disabled by default there
02:24 mareko: *blocker
02:26 Kayden: oh right
02:27 Kayden: we can just drop it from the milestone
02:27 Kayden: er, no
02:27 Kayden: this is for the -new- release
02:27 Kayden: it's still disabled by default on the 23.x branch?
02:27 Kayden: (back in a few hours)
02:36 zmike: it's still enabled for zink in 23.x I think
02:37 zmike: I gave you an rb though so as soon as the debian runners are back it should be good to go
03:42 liyi__: hi
03:42 psykose: hi
03:43 liyi__: hi All, I send Linux kernel patches to dri-devel@lists.freedesktop.org using liyi@loongson.cn, but all the emails is refused by the server, the Bounce reason is Can not connect to recipient's server because of unstable network or firewall filter. rcpt handle timeout,last handle info: Can not connect to lists.freedesktop.org:2610:10:20:722:a800:ff:fe36:1795:25, the Bounce Code is can not connect to , but my other emils is OK. I don't know Who I
03:43 liyi__: Shoud Contact, anyone can help me? Thank you.
03:46 liyi__: or anywhere I can get help, thank you
03:54 agd5f: liyi__ try on #freedesktop
05:00 mareko: a680 CI flake: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/36482427
05:57 liyi__: agdf5f thanks for your help
09:05 tzimmermann: airlied, danvet, last week's PR for drm-misc-next-fixes has not been merged yet https://lore.kernel.org/dri-devel/Y+S6HBmaRJNPYiBG@linux-uq9g/
09:11 danvet: tzimmermann, working on it, should build while I push the next pile of laundry :-)
09:12 tzimmermann: ok, thank you
09:42 danvet: tzimmermann, it is done
09:42 tzimmermann: danvet, thanks. i'll send out the new PR in a bit
09:43 mripard: danvet: could you also review https://lore.kernel.org/all/20230127154052.452524-1-maxime@cerno.tech/ and https://lore.kernel.org/all/20230127-rpi-cursor-corruption-v2-1-1f97bd00df01@cerno.tech/
09:45 danvet: airlied, fyi I pulled drm-misc-next-fixes, looks like nothing else was pending for drm-next
09:45 danvet: mripard, on the first one, is there not a mod_delayed_work or something which does the combo?
09:47 danvet: mripard, with that bikeshed a-b me
09:47 danvet: the 2nd one looks like I need more coffee
09:47 danvet:cries in cursor
09:49 tzimmermann: what's the current mood towards crtc_helper_funcs.mode_set_nofb ? the docs say that it's a blessed atomic helper, but the interface does not use atomic states. it's also rarely used. https://elixir.bootlin.com/linux/latest/source/include/drm/drm_modeset_helper_vtables.h#L231
09:50 danvet: tzimmermann, it was largely motivated by the crtc helper->atomic helper transitional helpers
09:51 danvet: since we ditched those there's not much point keeping the hooks that made the transitional helpers possible around
09:52 tzimmermann: danvet. i see. using modeset_nofb to program the display mode would be nice to get symmetry between atomic_enable/_disable. but it doesn't appear like it's supposed to be used :)
09:53 tzimmermann: should we mark it as deprecated?
09:55 danvet: mripard, https://lore.kernel.org/dri-devel/20220331152021.2671937-1-daniel.vetter@ffwll.ch/ <- I think this is what you want
09:56 danvet: the problem is I never got to the thinking things through part
09:56 mripard: that's what you suggested when I posted v1 and we carried it downstream for a while
09:57 danvet: did it work?
09:57 mripard: but we still have some similar bugs (without using the cursor though, but the situation is likely to be similar)
09:57 mripard: https://github.com/raspberrypi/linux/pull/5327 for example
10:03 mripard: those instances are incredibly hard to track and reproduce, so it's not really easy to figure out what's wrong and provide more details unfortunately :/
10:05 danvet: mripard, yeah ... there's kinda two things
10:05 danvet: one is that this shouldn't be possible, if you're still using hw resources at the point of state destroy something is very busted
10:05 danvet: (minus the legacy cursor hack this should hold)
10:06 mripard: yeah, the source of the corruption seems to be the same: we overwrite the hardware descriptors while they are in use
10:06 danvet: the other thing is that your atomic_check is kinda going out into a bit of silliness
10:06 mripard: but we indeed seem to trigger this from multiple paths
10:06 danvet: atomic_check is supposed to be against the sw state of things, not against some arbitrarily delayed hw state update
10:06 danvet: I guess in practice it doesn't matter much because people don't really use a lot of planes?
10:08 danvet: mripard, the way this is supposed to work is that you sufficiently delay the flip_done completion
10:08 danvet: i.e. the crtc event
10:08 danvet: if you signal that too early then the state gets shot down too early
10:08 danvet: so any delaying you might need should be in there, not later on
10:09 danvet: assuming the legacy cursor bypass is closed off
10:10 danvet: so in a way if flip_done fires too early, then in theory also your app could start rendering too early
10:10 danvet: since the flip_done is tied to the drm_event (it's the same thing)
10:10 mripard: because, if we leave the legacy cursor stuff aside, all commits are supposed to wait for flip_done before freeing the state, so if we free the state too soon then it must be that flip_done is signalled too soon?
10:10 danvet: yup
10:10 mripard: yeah, that makes sense
10:11 danvet: so either the flip_done is too early (would be driver bug) or we don't wait for flip_done (legacy cursor plus maybe a helper bug we haven't found yet?)
10:12 danvet: mripard, maybe add a check to crtc destry to warn if flip_done isn't done
10:12 danvet: check that not having the legacy cursor removal patch hits that
10:12 danvet: and then go hunting?
10:12 mripard: yeah, that's a good idea
10:12 mripard: thanks
10:14 mripard: for the first patch, it looks like mod_delayed_work is what we need indeed, are you ok with me fixing it up while applying?
10:23 danvet: mripard, sure
10:48 MrCooper: zink-freedreno-a630-traces flake: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/36493421
11:40 danvet: mripard, sent out new patch of the legacy cursor wrangling
11:40 danvet: I'll be out next week, pls poke me so I don't drop this on the floor again
12:24 danvet: robclark, [PATCH v1] drm/shmem-helper: Remove another errant put in error path <- for you I think
12:29 danvet: ogabbay, wrt counting a device in use when dma-buf exports exist, iirc amd folks where looking into this as part of the hotunplug work
12:30 danvet: agd5f, ^^ maybe you can connect? not sure who's working on this now
12:56 Lynne: could someone help me check my descriptor buffer code?
12:56 zmike: link
12:56 Lynne: I'm using it in a compute shader context, which I've never seen anyone do
12:56 Lynne: https://github.com/cyanreg/FFmpeg/blob/vulkan_test/libavutil/vulkan.c
12:56 Lynne: one buffer per descriptor set
12:56 Lynne: one descriptor set
12:57 Lynne: simplified shader as much as possible so it only writes 1.0 into the output
12:57 zmike: sounds like the same as zink 🤔
12:57 Lynne: pretty much all offsets are zero, so no chance for me to get the offset wrong
12:58 Lynne: on nvidia, I get nothing on the output, on radv, I crash the gpu
12:59 zmike: yea the amd hang means your descriptors didn't get updated in the right place
13:02 Lynne: I map the descriptor buffer and directly give the pointer to vkGetDescriptorEXT
13:03 Lynne: the offset I get from vkGetDescriptorSetLayoutBindingOffsetEXT is zero, since it's the first binding in the set
13:11 Lynne: oh, I forgot to retest properly, seems like it's working now
13:12 Lynne: doesn't work on nvidia, but /care
13:13 zmike: so...it works?
13:14 Lynne: sort of, when I try running it on more than 1 frame, "radv/amdgpu: The CS has been rejected, see dmesg for more information (-14)."
13:15 zmike: make sure to use RADV_DEBUG=zerovram when using descriptor buffers
13:15 zmike: otherwise you may not catch errors
13:15 zmike: I assume you've tried vvl?
13:15 Lynne: vvl?
13:15 zmike: validation
13:16 Lynne: yup, it's all green
13:16 Lynne: not that there's much it can validate, really, it's all unmanaged driver-given addresses
13:16 zmike: yea but if you had other issues
13:17 zmike: more than 1 frame failing implies to me that you aren't updating correctly on the second frame
13:32 zmike: the descriptor code there looks plausible at least, so I'd guess it's down to the updating
13:39 Lynne: weird, the CS stream gets rejected during the source upload
13:39 Lynne: and it only happens on multiplane formats
13:40 Lynne: so it's not descriptor related, unless the descriptors somehow mess up the program state
13:50 Lynne: yup, it's unrelated
13:53 Lynne: happens due to host mapping the input RAM frames to avoid a buffer copy
13:53 agd5f: danvet, ogabbay we were tracking down an issue with ref counts for the fbdev buffer: https://lists.freedesktop.org/archives/dri-devel/2023-January/389012.html
13:59 agd5f: danvet, ogabbay: see these patches: https://lists.freedesktop.org/archives/dri-devel/2023-January/389446.html
14:06 danvet: agd5f, force-unbinding the driver in sysfs doesn't sort out the refcount leak?
14:10 ogabbay: agd5f: thx. we did wonder how to keep track of the exported dma-buf
14:11 ogabbay: TomerTayar[m]: can you please look at https://lists.freedesktop.org/archives/dri-devel/2023-January/389012.html and https://lists.freedesktop.org/archives/dri-devel/2023-January/389446.html regarding tracking exported dma-buf
14:13 agd5f: danvet, I don't think so? Don't remember off hand.
14:28 danvet: agd5f, ah I caught up on that entire story, looks like it was just a classic refcount loop which könig already sorted out
14:29 danvet: the gem_bo holding a ref on the dma_buf and the dma_buf holding a ref on the gem_bo for the fbdev bo
14:29 danvet: so yeah that won't ever get freed :-)
14:35 danvet: agd5f, the patches you linked are kinda different problem, I was thinking of exported dma-buf having to hold a reference to the drm_device
14:35 danvet: because holding a module reference alone does not actually keep the drm_device alive against hotunplug
14:35 danvet: or manual unbinding through sysfs
14:35 danvet: they are separate refcounts
14:36 agd5f: danvet, yeah, that was the only one I could think of off hand that amd was working on
14:38 danvet: agd5f, the hotunplug stuff is laid on ice for now?
14:38 danvet: iirc we discussed properly refcounting dma-buf and dma-fence as part of the big threads there ...
14:41 agd5f: danvet, I don't recall that issue off hand. The big issues we've run into with hotplug were a locking bug in the PCI core around hotplugs at suspend/resume time and just general issues around trying to prevent access to hardware when the device is no longer present
14:41 agd5f: within the driver
14:42 danvet: agd5f, I think what you need is someone holding a dma-buf
14:42 danvet: but no one holding a drm fd open
14:42 danvet: then the drm_device goes away, and you'll oops on the dma-buf
14:42 danvet: same with syncobj/sync_file fd
14:42 danvet: and well any dma_fence that another driver might be holding somewhere
14:43 danvet: agd5f, so it's more an exploit situation than a real world usage situation
14:43 agd5f: ah, ok
14:44 danvet: but if we still go boom in pci code in real world usage ... oh well :-/
14:44 danvet: ogabbay, ^^
14:44 danvet: it would still be nice to fix the refcount in drm_prime.c I think instead of each driver rolling their own
14:46 ogabbay: danvet: yeah, I'm pretty sure that will happen in our case as well. Although I would imagine that doing any hotplug on our device will break the device, or the driver, or both
14:48 danvet: whynotboth.meme
14:50 ogabbay: TomerTayar[m]: let's try this, hot unplug the device while we export dma buf and then close dma buf and see what happens
15:27 karolherbst: can we burn LLVM to the ground?
15:27 karolherbst: honestly..
15:27 jenatali: What now?
15:27 karolherbst: jenatali: remember my resource path fix?
15:27 jenatali: Vaguely
15:27 karolherbst: turns out.. it doesn't fix it on _all_ systems
15:27 karolherbst: and "clang -print-resource-dir " is indeed the only reliable option
15:28 jenatali: Just embed the header. It's tiny
15:28 karolherbst: (ノಠ益ಠ)ノ彡┻━┻
15:28 karolherbst: uhh
15:28 karolherbst: but what if the header gets fixed?
15:28 jenatali: Then rebuild with the newer LLVM
15:28 karolherbst: or changed or _something_ and then compilation fails, because the updated one isn't included
15:28 karolherbst: yeah well...
15:29 karolherbst: that's what I wanted to prevent from happening (any update to llvm requiring to rebuild mesa)
15:29 karolherbst: maybe I have to bring this up to LLVM folks so they give us a proper API to fetch that resource directory....
15:30 karolherbst: apparently I could pass CLANG_RESOURCE_DIR as the second arg to GetResourcesPath, but CLANG_RESOURCE_DIR might hardcode the version as well :'(
15:30 karolherbst: I just want libclang to find that silly opencl-c-base.h file
15:31 karolherbst: why is that so annoying
15:31 karolherbst: and stupid
15:33 jenatali: Yeah that's kind of ridiculous
15:33 jenatali: I guess there's one upside to statically linking
15:33 jenatali: With the big downside being it requires actually building LLVM, which... oof
15:34 jenatali: Our build machines that we have to use for building the code we ship takes 2 hours to compile LLVM
15:34 karolherbst: yeah...
15:34 karolherbst: distributions will probably also kill us
15:34 karolherbst: I still hope there is some super magic clang option we can pass it so it magically finds, but...
15:36 karolherbst: I wonder if not setting `c->getHeaderSearchOpts().ResourceDir` at all would work?
15:37 karolherbst: is there actually a reason we are setting that?
15:44 robclark: danvet: sry that one fell off my radar.. it's sort of like somehow email inbox isn't a good way to manage patches ;-)
15:44 danvet: robclark, yeah who'd have guessed
15:44 danvet: tbh I've been disaster the past weeks on this too
15:44 robclark: also, some waitboost discussion on v2 (because, my bad, I replied to what wasn't the most recent version of patch)
15:45 danvet: so I figured I'll compensate by pinging a few people who also missed things :-)
15:45 karolherbst: can we just stop doing mailing lists?
15:45 danvet: how would we survive without that pain
15:45 danvet: robclark, oh I forgot to cc you on my ping on v3
15:45 karolherbst: just write to dri-devel: "sunsetting emails. We won't accept _any_ patch through emails anymore, starting tomorrow. No discussion. Deal with it :3"
15:46 robclark: danvet: yeah, I noticed that the way I notice most patches.. by blind luck :-P
15:48 robclark: karolherbst: I guess there would be some villagers with pitchforks.. and also I don't have a good plan for how to deal w/ s-o-b vs committer-email.. we've _kinda_ been using MRs for drm/msm (but only ff and mainly as a way to integrate CI so far)
15:49 karolherbst: not caring
15:50 karolherbst: (which in regards to bikesheding on mailing lists is the only sustainable option)
15:50 danvet: robclark, you can just not sob?
15:50 karolherbst: robclark: I have some magic for ya
15:50 danvet: I mean drm-misc with commit rights does just not have maintainer sobs on there
15:50 danvet: no one screamed about that
15:50 karolherbst: robclark: https://gitlab.freedesktop.org/karolherbst/maintainer-tools/-/commit/8331afdf9e9800219d1ca01c3cad1507b8cf5017
15:50 karolherbst: enjoy
15:51 danvet: they probably would scream if marge starts s-o-bing patches :-P
15:51 karolherbst: that's why I have my dim stuff
15:51 karolherbst: you do "dim tag nouveau 4235" and it adds the tags through your machine
15:51 danvet: needs an MR and then pinging demarchi to land it
15:51 karolherbst: yeah.. and clean ups
15:51 karolherbst: I want to make it possible to use SSH as well
15:51 karolherbst: and stuff
15:51 karolherbst: _but_
15:51 karolherbst: we can use the gitlab API for automating such nonesense
15:52 karolherbst: it also has the problem of requiring accounts to have public emails and stuff
15:52 danvet: yeah, I think some iterations on how to integrated gitlab api stuff best into dim will be needed
15:52 danvet: karolherbst, well you shouldn't ever forge a sob for someone else, so this shouldn't be a problem
15:53 karolherbst: it's more for review tags
15:53 karolherbst: or acks
15:53 danvet: ah yeah for those it's a bit more tricky
15:53 karolherbst: like you could add ack tags from anybody "aproving" the MR
15:53 danvet: otoh if the mail is private, just put the gitlab user https: link in there instead?
15:53 karolherbst: something
15:53 robclark: hmm, ideally some way that only one of the driver maintainers could assign to margebot and margebot setting the commit-author and SoB based on who assigned it to her?
15:53 danvet: it'll fuck up everyone's parser, but oh well :-)
15:53 karolherbst: but that needs more ML bikeshedding on lkml
15:54 danvet: robclark, uh that smells like going back to maintainer model from committer model
15:54 danvet: defo no
15:54 demarchi: karolherbst: let's not overload terms... s/tag/trailers/
15:54 karolherbst: heh, people are angry if you mess with their parsers
15:54 danvet: you really don't need maintainer sob
15:54 danvet: no one has screamed about that for the years we've been doing it by now
15:54 danvet: and people have screamed about everything else that the commit right stuff caused
15:54 danvet: so really, don't worry
15:54 karolherbst: :D
15:55 danvet: I mean we put sob onto merge requests instead, which no one else does
15:55 danvet: or at least didn't, maybe that's changing
15:55 karolherbst: ehhh...
15:56 robclark: danvet: when I say maintainer I'm thinking of (currently) myself, lumag, and abhinav for drm/msm.. and similar for other driver.. ie. more than a single person but someone who is familiar enough with that driver to approve changes
15:56 javierm: danvet: I wonder what are some of the complains / issues that the commit right stuff caused
15:56 robclark: we aren't yet to the point where we can just completely rely on CI
16:07 lumag: robclark, I might sound like and oldschooler here, but I prefer ML model. Bound with the patchwork and b4 it significantly simplifies my work as a co-maintainer, reviewer and patch author. It allows me to collect all the review and testing tags in a sensible way.
16:08 lumag: And the problem with merge requests is that CI is far from being perfect.
16:09 lumag: For example, CI was completely happy with the recent db410c breakage.
16:11 lumag: So I still do a lot of manual testing, and it's simpler with `b4 am`
16:12 lumag: The only benefit from MRs is that the developers will have to apply their patches on top of a sane revision rather than dumping the stuff that 'was tested on top of 5.15 fork'
16:32 cwabbott: dschuermann_: the more I think about it, the more I think we can't assume that undef is convergent
16:33 cwabbott: or rather, we can't assume that things computed from undef values are convergent
16:35 cwabbott: because our current model assumes that you can get a new value every time you use an undef value, sure, but then ALU operations can narrow down the possibilities so that it becomes constant
16:36 cwabbott: think like "foo = undef & 1; bar = foo & ~foo;"
16:37 cwabbott: optimizations that effectively insert readfirstlane somewhere (which is pretty common) can't assume "foo" is convergent and insert a readfirstlane because "bar" would go from being always 0 to being either 0 or 1 (assuming foo wound up being in some vector register)
16:38 cwabbott: that's less likely to happen with a "pure" undef but might happen if instead we have a phi node where one of the sources is undef
16:39 cwabbott: the case I found is slightly different but sort-of in the same vein, where an optimization assuming the result is the same in all lanes blows up because it's undef
16:51 robclark: lumag: what was the db410c breakage, and how can we make CI better catch it?
16:52 lumag: robclark, https://patchwork.freedesktop.org/series/113286/
16:52 lumag: https://patchwork.freedesktop.org/patch/520076/?series=113286&rev=1
16:53 lumag: So DSI ended up with empty mode table and then IGT was also happy because no modes were defined
16:53 lumag: At least that's how I can interpret the passing IGT
16:54 anholt_: well, we don't have any db410c with dsi panels in ci anyway.
16:55 lumag: anholt_, adv75xx is the DSI-HDMI bridge
16:55 anholt_: ok. but we also don't have the db410cs hooked up to a monitor.
16:56 lumag: But there is probably some dummy plug which reports a good EDID?
16:57 anholt_: might be a good idea to find and acquire. but we set up the db410cs for rendering testing, and they got reused for igt (which is great!)
16:58 lumag: anholt_, I have been using this kind of thing: https://www.amazon.de/Headless-Display-Emulator-Aluminium-Headless-1920/dp/B07ZC9DBGK/ref=sr_1_2_sspa?crid=2GJCIEU5V6RRA&keywords=schnullerstecker+hdmi&qid=1676566702&sprefix=dummy+plug%2Caps%2C168&sr=8-2-spons&sp_csd=d2lkZ2V0TmFtZT1zcF9hdGY&psc=1
16:59 lumag: God them from local market, so the label is different, but the overall appearance is the same
17:00 daniels: linaro used to make one, but iirc it only wired HPD, and didn’t have an EEPROM
17:00 robclark: in theory we are supposed to get some chamelium v3 boards at some point..
17:01 robclark: which should be useful for igt testing.. I guess maybe we need to ask for one for pdx farm db401c/db820c's.
17:01 daniels: Amazon have plenty which have EEPROM these days, apparently so you can run a real desktop on your cryptocurrency miners and RDP into them
17:02 robclark: heh
18:41 dcbaker: anholt_: I've got "5c246e21b7 Revert "freedreno/a5xx: Fix clip_mask" nominated for 23.0 since it's a revert, but it isn't immediately obvious to me as to whether this is something we really want to backport, do you have opinions?
18:42 anholt_: dcbaker: I think so -- it fixes GPU hangs on that board.
18:42 dcbaker: anholt_: I'll pull it then, thanks!
18:52 alyssa: anholt_: I meant to ask about that commit, if the clip mask gets lowered by mesa/st, why do other drivers (including fd/a6xx) handle it?
18:52 alyssa: or is this more PIPE_CAP voodoo?
18:52 anholt_: alyssa: a6xx doesn't lower it through st
18:52 anholt_: because something about its weird gs lowering.
18:52 alyssa: delight
18:53 alyssa: I ask because AGX supports clip distance, but 1. there is no way to disable (must use lower_clip_disable) and worse 2. they are sysval only outputs and cannot be interpolated (must duplicate the store_output and write to some non-sysval slot)
18:54 alyssa: currently I just use lower_clip_fs
18:54 alyssa: long term plan is to deal with #2 when we get to enabling clipDistance in AGXV, and then Zink should do #1 for us too :~p
18:56 DemiMarie: zmike: doesn’t the crash also mean there is a GPU kernel driver bug that needs to be fixed?
18:56 jenatali: Not necessarily
19:03 bl4ckb0ne: trading r-b for https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18847 and https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18011 against non-expert semi-sharp eyes r-b
19:07 anholt_: alyssa: good plan. you already get the disable bits handling in the frontend with zink.
19:10 zmike: bl4ckb0ne: GL_EXT_framebuffer_blit_layers is on my list since it came up in opengl working group call this week
19:11 bl4ckb0ne: <3
19:11 bl4ckb0ne: also for the EGL ext if anybody's feeling extra https://github.com/KhronosGroup/EGL-Registry/pull/165
19:19 anholt_: Hmm. We have no gen8/9 vulkan CI for !21370
19:21 Sachiel: I pushed it to ours
19:24 HdkR: zmike: A new GL extension in 2023? What happened?
19:26 ccr: a disruption in space-time continuum?
19:26 zmike: there have been new GL extensions publishing all along
19:26 zmike: it's not unusual
19:26 HdkR: Madness, we're supposed to be in the Vulkan and D3D12 utopia now
19:30 ccr: 999 merge requests on the gitlab wall .. 999 merge requests .. take one, pass it through .. 998 MRs on the gitlab wall
19:33 bl4ckb0ne: HdkR: im doing weird stuff and somehow ended up finding something missing from the spec
19:33 HdkR: Neat
19:34 bl4ckb0ne: spoilers: i have even more gl/egl exts coming
19:35 HdkR: That's a fun way of giving zmike more work indirectly
19:35 bl4ckb0ne: well he has to fuel his blog
19:37 gfxstrand: eric_engestrom: Ugh... the Vulkan XML update is making total hash of your extension requirements stuff. :cry:
19:39 eric_engestrom: oh well, it was good while it lasted 🤷
19:39 gfxstrand: I'm gonna try and fix it
19:40 eric_engestrom: it did reveal a number of bugs though ^^
19:40 gfxstrand: \o/
19:40 eric_engestrom: thx
19:40 eric_engestrom: let me know if you want my help
19:40 eric_engestrom: (but not today, /me is about to log off)
19:40 gfxstrand: kk
19:42 gfxstrand: eric_engestrom: Actually, I might revert and land the XML parser fixes and we can re-land it with the new stuff.
19:43 gfxstrand: Yeah, I think that's the thing to do. Sorry.
19:43 gfxstrand: If I'd had a chance to look at it in detail this week, I might have been able to give more of a heads-up
19:45 eric_engestrom: I saw a mail go by about the xml changes, but I'm not really paying close attention to these emails
19:45 gfxstrand: That's ok
19:45 gfxstrand: I dealt with most of it
19:45 eric_engestrom: my fault for not reading what these upcoming changes were
19:45 gfxstrand: No, it really isn't
19:46 eric_engestrom: thanks! and yeah feel free to revert what you can't fix, I'll re-do it later
19:46 gfxstrand: It's unlikely you would have been able to guess the impact unless you were watching REALLY closely
19:46 gfxstrand: No need to feel bad
19:54 eric_engestrom: :)
20:19 danvet: ogabbay, [PATCH 0/1] drm: Add a gpu page-table walker <- maybe of interest to you
20:27 ogabbay: danvet: yes, thx, I'll read it
20:34 gfxstrand: Does OpenGL ES still not have HTML specs?!? *sigh*
20:36 bl4ckb0ne: arent they on the repo?
20:36 bl4ckb0ne: https://github.com/KhronosGroup/OpenGL-Registry/blob/main/specs/es/3.2/GLSL_ES_Specification_3.20.html
20:38 gfxstrand: That's the GLSL spec
20:41 gfxstrand: Why did I agree to review a super-subtle VK_EXT_multisampled_render_to_texture patch regarding visuals....
20:41 gfxstrand:is questioning life choices
20:42 bl4ckb0ne: oh right es spec is below and all in pdf
21:05 karolherbst: gfxstrand: I think the nir patch is ready and apparently it just works like that for CL and radeonsi: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20161/diffs?commit_id=a5ed82dd4f57816574be886de47bead402f3bfa7
21:05 karolherbst: so just need a quick review and I can land another batch of patches to enable radeonsi :)
21:05 karolherbst: or maybe even already enable it, because images should just work with that..
21:13 gfxstrand: karolherbst: cool!
21:56 bnieuwenhuizen: uhh, that sounds like a weird VK extension
21:59 gfxstrand: lol. I'm looking at GLES, actually. I've got finger-memory, aparently.
22:16 gfxstrand: italove: The good(?) news is that I think your patch is correct. The bad news is that now we have to figure out what's going on with glReadPixels().
22:16 gfxstrand: I'll leave that to you. :)
22:17 gfxstrand: I've got a big enough headache already. :P
22:17 italove: gfxstrand: thanks for the help with that + the review :)
22:21 gfxstrand: yw
22:21 gfxstrand: I forgot how much I hate GL...
22:21 gfxstrand: So thanks for that little reminder. :P
22:21 alyssa: gfxstrand: ...Is Vulkan better?
22:21 alyssa: You're always telling me how much you hate stuff in Vulkan :~P
22:21 gfxstrand: In this regard, yes.
22:22 gfxstrand: GL is full of "As for thing X, driver will choose thing Y which is at least as good as X, then you can call glGetParameter* with GL_Y to get Y. Also, when you do Z, we'll check that Y is ... and fail otherwise"
22:23 gfxstrand: *ask for
22:23 alyssa: ah, yes, well, yes
22:23 gfxstrand: In Vulkan, there's none of this "Ask for X, get Y nonsense". The app queries for what's possible and then does that and the driver gives it what it asked for.
22:24 gfxstrand: Makes the spec SO much easier to read.
22:24 alyssa: Makes apps harder to write though
22:24 alyssa: I assume
22:24 gfxstrand: Also, means you don't have 3 different parameters and a calculated thing to keep in sync and constantly be trying to remember which one you need to use in any given situation.
22:24 gfxstrand: Yes and no. Thing is... most apps don't want GL's fuzziness.
22:25 alyssa: Yeah, that's fair
22:25 alyssa: I'm mostly wondering about stuff like e.g. AGX doesn't support 24-bit depth
22:25 alyssa: GL will implicitly promote to 32-bit
22:25 gfxstrand: You don't need to ask for at least 8 bits. You just say "give me RGBA8888" and the driver does it because no one's upgrading you to 11 bits for no good reason.
22:25 alyssa: VK we just don't expose that format
22:25 gfxstrand: Yup
22:26 alyssa: which would* mean that games are just going to fall over and break if they have never seen a GPU without 24-bit depth support
22:26 alyssa: limiting title selection
22:26 alyssa: * if not for RADV also not advertising 24-bit depth
22:26 gfxstrand: And for most apps, they can write a tiny loop which looks at what formats are available and selects 32-bit if 24-bit isn't available.
22:26 gfxstrand: Vulkan apps are pretty used to that.
22:26 alyssa: I wonder if that sort of thing could be driconf'd too?
22:27 alyssa: if there's some old binary app that you're trying to coax to run on your platform?
22:27 alyssa: ("old" includes stuff written today but for hw in 10 years form now)
22:27 gfxstrand: In theory, the HW 10 years from now will support a superset of what today's hardware does.
22:27 alyssa:doubtful
22:28 gfxstrand: Well, for any given vendor
22:28 alyssa:doubtful
22:28 alyssa: Maybe I've been burned by Mali removing features over time? :p
22:28 gfxstrand: IDK, Intel has managed to evolve their hardware for 15 years without deleting interesting formats.
22:28 gfxstrand: Yeah, I think you might be. :)
22:28 alyssa: Arm removed a huge number of formats a few years ago
22:28 gfxstrand: woof
22:28 alyssa: and we're still sorting out the pain
22:29 alyssa: you're not going to miss them but if you have a 2007 title that uses them... I'm glad mesa/st can emulate
22:29 gfxstrand: Well, Vulkan has a required baseline format set that apps can alway rely on and it's enough to cover most cases.
22:29 alyssa: in the parallel universe where it was VK the whole time...
22:29 gfxstrand: If you're doing something truely esoteric, you may need to actually query for something.
23:28 HdkR: t/win 4
23:31 DavidHeidelberg[m]: Quiz: How often do you want to debug something which failing in CI with gdb?
23:32 DavidHeidelberg[m]: I'm currently more and more considering the costs of distributing unstripped mesa (NOT sending it to the runners, just uploading) and debug symbols (also aside, but uploaded with each mesa build)
23:35 DavidHeidelberg[m]: One of huge advantages I see is debugging flakes. On other hand, for that purpose would be better to have not debugoptimized we use now, but debug... which is overkill ofc.
23:40 zmike: tbh just printing a backtrace from gdb would be a huge improvement for crashes
23:43 DavidHeidelberg[m]: zmike: good. anyway have to warn again, it's `debugoptimized` so no luxury of seeing variables & stuff
23:44 zmike: eh just having a hint is enough sometimes
23:48 DavidHeidelberg[m]: good; now let's see if the extra 3G per run of data will make sense :D anyway if you need it time to time, it's not merged yet, but you can just apply the MR: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20435
23:50 zmike: 3G of data is a lot to be syncing around
23:51 DavidHeidelberg[m]: my calculation is around extra 250M of unstripped mesa + 250M debug.dwp, these files just stay uploaded until removed (or used for debugging)
23:52 DavidHeidelberg[m]: and that's for each build which gets distributed to the test jobs class
23:52 zmike: what kind of impact does that have on download times for the jobs
23:53 DavidHeidelberg[m]: none
23:53 DavidHeidelberg[m]: anyway, I've been too bulvar. Looking at mine unstripped zst archive and debug.dwp, it's 81M + 137M for arm64
23:54 DavidHeidelberg[m]: zmike: the distributed stuff is the same as before, just "few extra kbytes" for the split dwarf references
23:54 zmike: hm cool
23:54 DavidHeidelberg[m]: if you need debug, you download the full-sized unstripped binary compatible with the one running in CI (stripped)
23:56 DavidHeidelberg[m]: what could be spotted I guess is build job uploading these files to s3 (I would love if the job could postpone it after "finishing"
23:57 DavidHeidelberg[m]: thinking a loud. Mesa has reproducible builds I assume. Maybe we could re-generate the build and upload in different job
23:58 DavidHeidelberg[m]: so for CI we would build without uploading unstripped & debug.dwp and if we need to generate these files, we could run separate job
23:59 DavidHeidelberg[m]: ugly thing would be 7 duplicated job in pipeline
23:59 anholt: we don't strip armhf debugoptimized mesa already. is there something stopping us from just dropping stripping for arm64 and x86?
23:59 DavidHeidelberg[m]: anholt: upload times to the runners?