01:09 alyssa: what's the difference between glthread and tc?
01:09 alyssa: I guess glthread is for gl calls and tc is for gallium calls?
01:09 airlied: alyssa: glthread is between GL and mesa, tc is between mesa and gallium
01:09 alyssa: airlied: yeah okay makes sense
01:09 zmike: one has bugs
01:09 alyssa: zmike: mood
01:10 zmike: mood.
01:10 alyssa: Why is tc helpful if glthread is in use?
01:10 alyssa: (I assume it is, else mareko would've stopped working on tc :p)
01:10 zmike: command recording vs driver cmdbuf recording
01:11 airlied: more threads is always good :-P
01:11 zmike: yeah that
01:11 alyssa: I'm not following why you need both, why isn't recording the gl commands and then running synchronously good enough?
01:12 alyssa: or is the idea that the glthread gets to run in parallel with the driver thread?
01:12 alyssa: (so in the most synthetic drawoverhead cases you end up with 300% cpu usage?)
01:12 airlied: some drivers also have a kernel submission thread
01:12 zmike: sometimes gl command recording is slow
01:12 alyssa: (100% app, 100% gl, 100% driver all in parallel?)
01:14 zmike: drawoverhead and other synthetic benchmarks are worse with glthread
01:15 alyssa: ~~why would you want it then~~delet
01:17 zmike: stuff like source engine games do a ton of simple draws, so it's better there
04:03 airlied: zmike: ping
04:03 zmike: 💪
04:03 airlied: zmike: in lavapipe merge_layouts was you?
04:03 zmike: probably
04:03 airlied: it's causing the memory leaks
04:03 zmike: smh
04:04 airlied: which is why we have a bunch of asan fails
04:04 airlied: I think merge_layouts is missing a reference drop
04:04 zmike: possible
04:05 zmike: not something I can check from my phone too easily
04:05 zmike: can look tomorrow tho
04:06 airlied: you clearly need a better phone, maybe one shaped like a PC :-P
04:06 airlied: I think I have a fix in mind
04:06 zmike: I'm trying to couch mode before bed 🤷
04:07 zmike: I'll review if you put something up
04:07 zmike: ...tomorrow
04:07 airlied: yeah I think I have the simple hack, but it might need you to figure out the correct fix
04:30 siddh: <danvet> "if you find some, maybe submit a..." <- okk
04:30 siddh: ---
04:32 siddh: I've been getting dmarc error messages on posting to dri-devel. I don't think that should have been the case as there seems to be no change to message. Can the mail admin look at it?
04:33 siddh: LKML works fine
05:09 airlied: zmike: arrgh, my hate for pipeline libraries is now a lot larger :-P and also you need to ref count betterer :-P
08:11 daniels: eric_engestrom: dockerd is dead again :(
08:15 tanty: daniels: I saw eric_engestrom already took care. For any RPi CI related issue, he is your default contact at Igalia.
08:34 daniels: tanty: thanks - do you mean that dockerd was already fixed in the last 3h?
09:37 chema: daniels: Rpi CI should be working fine with only half of the runners, we have disabled the system having issues to run some test on the disk used in the system.
09:39 daniels: chema: right, was that this morning or yesterday though? this happened at around 5am UTC https://gitlab.freedesktop.org/mesa/mesa/-/jobs/34510512
09:44 chema: daniels: machine reported at 02:25 on dmesg | BUG: unable to handle page fault for address: 0000000000034900 | PF supervisor write access in kernel mode | PF: error_code(0x0002) - not-present page
09:45 chema: And since them a lot of stalls on CPU, but it is different from yesterday when it just died silently.
09:57 daniels: heh, oh well
10:04 javierm: tzimmermann: have you seen https://bugzilla.kernel.org/show_bug.cgi?id=216303#c28 ?
10:05 javierm: do you know if in systems with both an nvidia and intel gpus, the aperture is shared across both devices ?
10:09 javierm: danvet: are you familiar with these systems that have both an integrated intel gpu and discrete nvidia gpu ^ ?
10:09 danvet: hm that's more airlied I think
10:11 danvet: javierm, oh this one is easy I think
10:11 danvet: sysfb for pci devices on x86 needs to take the boot vga device into account
10:11 danvet: which vgaarb tracks
10:11 danvet: I'm not sure whether that's also needed on other devices
10:12 danvet: and yeah that patch is wrong, I have no idea what crossed my mind there thinking this will work in all cases :-/
10:12 javierm: danvet: but the aperture infrastructure should already take care of that, or do both GPU share the same PCI bar / aperture ?
10:13 danvet: javierm, the sysfb_disable is unconditional
10:14 danvet: https://paste.debian.net/hidden/ce4021e4/
10:14 danvet: except we probably shouldn't let driver compute primary
10:15 danvet: why is ast not using drm_aperture_remove_conflicting_pci_framebuffers?
10:16 danvet: hm primary computation looks a bit fishy in aperture_remove_conflicting_pci_devices, but I think should be good enough
10:17 danvet: I'm typing some patch for the ast one
10:17 javierm: danvet: I remember tzimmermann mentioned a reason why ast wasn't using the _pci variant, but don't remember the details now
10:18 danvet: it's just open-coded afaict
10:19 tzimmermann: javierm, danvet, when I replaced the ast code with the _pci helper, it didn't work. i never understood why, though
10:19 javierm: tzimmermann: right, that was what I rememered. And makes sense that didn't remember the details since were unknown :)
10:19 danvet: tzimmermann, what does "didn't work" mean?
10:20 javierm: danvet: but if the i915 driver creates an emulated fbdev, why the efifb should continue to exist?
10:20 javierm: danvet: it seems to me that this is a workaround for the nvidia driver not creating its own fbdev
10:20 danvet: javierm, because otherwise you get regression reports :-)
10:21 danvet: javierm, the nvidia driver doesn't even load in this case maybe
10:21 danvet: people have funny setups
10:21 javierm: danvet: it doesn't load sure, but the intel fbdev shouldn't bind to fbcon in this case ?
10:21 javierm: from the bugzilla comment "I'm looking at making the NVIDIA driver install its own framebuffer console in order to work around this problem"
10:21 danvet: vga_remove_vgacon() this one maybe also needs the same check, but I guess in practice no one cares
10:21 javierm: that's not a workaround, is the correct fix IMO
10:22 danvet: javierm, yeah, but I still think doing this is the right thing on x86
10:22 danvet: but I guess we can also just blame it on nvidia's blob or so :-)
10:24 danvet: hm I wonder whether the explicit vgacon remove is superseeded with 482b1c7d47887?
10:24 danvet: anyone tried that?
10:24 javierm: danvet: hmm, Ok. I guess it wouldn't hurt to check if (primary) to call sysfb_disable()
10:24 danvet: hm I guess vgacon isn't really binding to anything at all
10:24 javierm: wonder how that would work for !x86 though...
10:24 tzimmermann: that bug report has an interesting discussion
10:25 javierm: danvet: I guess we will need to add a #ifdef CONFIG_X86 guard
10:25 danvet: ah yeah :-)
10:26 javierm: danvet: https://paste.centos.org/view/raw/4cb47a83 which is pretty horrible tbh :)
10:27 danvet: javierm, glorious
10:27 danvet: I'm also wondering whether primary really shouldn't be something like
10:28 danvet: primary = pdev == vga_default_device();
10:28 danvet: at least per pci subsystem that is the canonical boot device
10:29 tzimmermann: i'm all for if (primary), but why the ifdef guard?
10:29 javierm: danvet: hmm, should we also check for !vga_default_device() ?
10:29 danvet: javierm, only really
10:29 danvet: I guess I should get going with some patches
10:30 javierm: tzimmermann: because this is only relevant for PCI devices and not integrated graphics? I think in those cases primary won't be set ?
10:30 javierm: like on aarch64 SoCs
10:32 javierm: danvet, tzimmermann: so many corner cases :( I thought we already covered all of them with the latest aperture infra unification
10:32 tzimmermann: javierm, hmm, yeah. primary comes from hacks like https://elixir.bootlin.com/linux/v6.2-rc3/source/drivers/video/aperture.c#L332
10:33 danvet: javierm, lol you're an optimist :-P
10:33 javierm: tzimmermann: exactly, so for !x86 it will always be 0 and sysfb_disable() won't ever be called if we check if (primary)
10:34 javierm: danvet: haha
10:34 javierm: I don't know... I think that my opinion is still that this should be done unconditionally
10:35 javierm: if a driver calls remove_conflicting_framebuffers(), is because it will set-up its own fbdev and so fbcon should bind to that instead of efifb/simplefb/simpledrm
10:35 danvet: yeah but if the igpd isn't actually connected to a screen the user looks at
10:35 danvet: but the boot-vga devices is
10:35 danvet: then this breaks something
10:36 danvet: and we get a bug report
10:36 javierm: danvet: I see. So when the igpu isn't connected to the screen? Is that a BIOS setup or ?
10:36 javierm: and shouldn't the igpu driver check that and not attempt to remove conflicting framebuffers and create an fbdev ?
10:37 danvet: uh that's what we have the pci version for
10:37 danvet: so it can internally check this
10:37 danvet: with the primary thing
10:37 javierm: danvet: ahh, I see...
10:40 javierm: why there is both a vga arbitrier and vga_switcheroo. I think that need to understand how all this works first
10:40 danvet: ah
10:40 danvet: do you want to be entertained?
10:40 danvet: they're entirely different things really
10:41 danvet: vga_switcheroo is more like gpu_switcheroo
10:41 danvet: also switcheroo only has a debugfs interfaces and some fundamental locking issue at the design level :-)
10:42 javierm: danvet: I see. So the vgaarb is the only thing that is used without user intervention then?
10:42 danvet: not really
10:42 danvet: it's more like was
10:42 danvet: back when userspace modesetting was all the rage
10:43 danvet: and userspace drivers needed legacy vga to be routed correctly
10:43 danvet: nowadays it's really just informational only, so userspace knows which pci device is the boot one
10:43 danvet: and can smash the login screen on the right display
10:43 javierm: everything in gfx is a rabbit hole and leads to a history lesson :)
10:46 danvet: argh
10:46 danvet: I think I overlooked something
10:59 javierm: danvet: right now the primary in aperture_remove_conflicting_pci_devices() is only used to remove the vga16 device, that hardcodes the base to VGA_FB_PHYS_BASE
11:00 danvet: yeah I think we need to shuffle things a bit more
11:04 danvet: javierm, I have an idea, but it's like an entire patch series
11:04 danvet: with a pile of cleanups
11:04 danvet: but since all we broke is the nv blob, I think that's ok :-)
11:04 danvet: lunch time here now, I'll simmer this while I'm cooking some stuff
11:05 javierm: danvet: Ok, enjoy!
11:07 danvet: it's always a good day when you end up patching fbdev drivers in staging
11:09 javierm: heh
11:28 mareko: alyssa: we split GL into 2 threads: GL frontend (glthread) and the driver (TC), radeonsi also has a kernel submission thread to hide kernel overhead, so in total we could get 400% CPU load
11:43 tzimmermann: javierm, look though the bug report again. i think we want something like https://elixir.bootlin.com/linux/v6.2-rc3/source/arch/x86/video/fbdev.c#L14 to detect the primary device
11:44 javierm: tzimmermann: yes, agreed but regardless I think this is a bug in the i915 driver
11:44 tzimmermann: how so?
11:45 tzimmermann: javierm, there's also https://elixir.bootlin.com/linux/v6.2-rc3/source/drivers/video/console/sticore.c#L1153 so the detection has to be arch-specific
11:46 javierm: tzimmermann, danvet: https://paste.centos.org/view/raw/f88923d5
11:47 javierm: IOW, the i915 shouldn't attempt to remove conflicting frambuffers (and disable sysfb) if is not connected to the display and doesn't setup an emulated fbdev
11:47 javierm: tzimmermann: having said that, I agree with you that checking for primary properly in x86 makes sense
11:48 tzimmermann: javierm, yeah
11:48 tzimmermann: in the bug report, there was an amd user as well
11:49 javierm: tzimmermann: maybe AMD does something similar?
11:49 javierm:checks
11:49 tzimmermann: comment 15
11:50 javierm: tzimmermann: https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/i915/display/intel_display.c#L8787 FYI
11:50 javierm: that's what lead me to type the patch above
11:50 danvet: javierm, yeah that might be another one
11:51 danvet: otoh if we wire through the boot vga stuff correctly, it shouldn't be needed
11:51 danvet: and it's imo better to not push this kind of stuff to drivers
11:51 tzimmermann: danvet, yeah with the vga-switcheroo. do we really need that?
11:51 danvet: iow the series I'm working on entirely removes primary from all aperture helpers, and tries to dtrt instead just be default
11:51 javierm: danvet: yeah, makes sense. But the good thing is that this could be backported to stable
11:51 danvet: javierm, tbh I'm not super enthusiastic about backporting fixes for the nv blob :-)
11:51 javierm: because the patch is trivial. But up to you really, I'm happy to just ignore the nvidia blog :)
11:52 javierm: *blob
11:52 danvet: I mean if aaron wants the upstream fix backported (assuming it work all) then he can ...
11:55 javierm: tzimmermann: the AMD driver is really complex :) and since danvet doesn't want to push these to drivers, I stopped looking
11:56 danvet: what's the switcheroo to do here again?
11:56 danvet: javierm, I'm lost on your comment
11:57 javierm: danvet: which one? I mean that you don't want drivers to check if display is enabled to decide whether to call to drm remove conflicting framebuffers
11:58 javierm: e.g: the i915 patch I shared above and prefer to handle properly in the aperture core
11:58 tzimmermann: aaron, the nvidia dev, wants to use its own emulated console. nice
11:58 javierm: tzimmermann: yup, he said that's a work around but it's really to correct thing to do :)
11:58 javierm: *the
11:58 tzimmermann: yeah, my thoughts
11:59 tzimmermann: the fbdev emulation is the solution to a nubmer of problems
12:00 javierm: danvet: because I was looking if a similar patch was needed for the amdgpu driver
12:01 danvet: javierm, oh there's an amdgpu bug report for this too?
12:01 javierm: danvet: yeah, in the same BZ, comment 15: https://bugzilla.kernel.org/show_bug.cgi?id=216303#c15
12:03 danvet: javierm, per the discussion linked in the other gpu that was a different bug
12:03 danvet: https://bugzilla.kernel.org/show_bug.cgi?id=216331
12:04 danvet: https://github.com/torvalds/linux/commit/a6250bdb6c4677ee77d699b338e077b900f94c0c
12:13 javierm: danvet: ah, I see. Couldn't follow that BZ in details, too many comments
12:13 shadeslayer: mareko: At least the iris commit hasn't been Rb'd on the util cleanup yet and I know one of the traces fails on freedreno
12:14 shadeslayer: so it needs one last round of fixes
12:15 javierm: danvet: so to recap, I shouldn't post that i915 patch then and you have an idea on how to properly check the primary VGA device in the aperture helpers?
12:16 javierm: which should be more like a refactoring / patch series but we are OK for this to not be backported because the nv blob should had created its own fbdev anyways
12:17 danvet: javierm, yeah I think I have an idea
12:17 danvet: whether it's a good one is a different question :-)
12:18 javierm: danvet: Ok :)
12:18 javierm: then I'll leave it in your capable hands and go out for lunch
12:18 danvet: enjoy!
12:18 danvet: mine is still simmering, but should be ready any minute
12:18 danvet:rather later than usual ...
12:25 APic: Phew
12:25 APic: Nobody kicked me out
12:26 APic:thanks to You all 😌
12:26 APic: s/to //
12:26 APic:really made a bad Mistake yesterday. So sorry.
12:32 Venemo: anyone planning to go to FOSDEM this year?
12:38 DavidHeidelberg[m]: Venemo: me and myself + also daniels what I'm aware of
12:39 Venemo: nice
12:39 Venemo: I wanted to go too, but I'm on the fence. they don't have a graphics devroom anymore and the technical talks this year don't seem to be too interesting
12:39 daniels: not that you can ever get into the talks anyway ...
12:39 Venemo: lol
12:41 shadeslayer: DavidHeidelberg[m]: hey, so I was trying out your branch, but looks like the coredump doesn't like my x86 system :(
12:41 shadeslayer: DavidHeidelberg[m]: https://gitlab.freedesktop.org/shadeslayer/mesa/-/jobs/34537619/artifacts/browse/results/ has the coredump, http://paste.debian.net/1266866/
12:49 DavidHeidelberg[m]: shadeslayer: follow the docs :D I spend some time in situation as yours :D
12:50 DavidHeidelberg[m]: https://mesa.pages.freedesktop.org/-/mesa/-/jobs/34393150/artifacts/public/debugging.html
12:52 DavidHeidelberg[m]: It always fails if you put the core dump file before loading the rootfs. Sadly all HOWTO are usually using core dump as a gdb argument
12:53 DavidHeidelberg[m]: Also Hi :)
13:06 shadeslayer: oh I didn't see the docs
13:07 shadeslayer: thanks!
13:18 siddh: Sorry for being offtopic, but why do sometimes people refer to them in third person? For eg. "* user <the message>". Is it auto replacement of "I", and if so, why?
13:18 DavidHeidelberg[m]: shadeslayer: after you finish debugging if you find time, please give me feedback (most interested in the doc part, if it's well comprehensible etc.)
13:18 DavidHeidelberg[m]: Siddh: it's use of command `/me`
13:19 siddh: oh
13:19 siddh: thanks for informing!
13:31 mripard: tzimmermann: hi, if you have a bit of time could you review: https://lore.kernel.org/dri-devel/20221207-rpi-hdmi-improvements-v1-0-6b15f774c13a@cerno.tech/
13:34 tzimmermann: mripard, ok
13:56 shadeslayer: DavidHeidelberg[m]: I'm looking at the "Root filesystem, link located at the beginning of the failed job." instruction and I don't see a link
13:56 shadeslayer: https://gitlab.freedesktop.org/shadeslayer/mesa/-/jobs/34537619 < has a registry image, but no rootfs link
13:57 DavidHeidelberg[m]: shadeslayer: on it, I'll update that
14:01 shadeslayer: DavidHeidelberg[m]: I'd have to build my own debug mesa libs in arm64 though to load the core file?
14:02 shadeslayer: would be useful to have a script that does that in the container ...
14:02 DavidHeidelberg[m]: shadeslayer: show me your branch (where you have core dump)
14:03 DavidHeidelberg[m]: nevermind, I see... you sent it
14:03 shadeslayer: https://gitlab.freedesktop.org/shadeslayer/mesa/-/commits/util_cleanups_with_split_dwarf
14:06 DavidHeidelberg[m]: I did recently changed it a bit
14:06 DavidHeidelberg[m]: for binaries, download mesa-arm64-unstripped.tar.zst (same path as the classic MINIO)
14:07 DavidHeidelberg[m]: s/classic s3/
14:07 DavidHeidelberg[m]: afk 30 minutes. and same path for debug symbols on s3, just name is default debug.dwp
14:20 macromorgan: so I hate to keep asking for help, but I'm struggling trying to solve some errors: https://lore.kernel.org/dri-devel/20230110200255.1218738-1-macroalpha82@gmail.com/T/#mee3e1b9596d971342074f1b19e89ab4369c4d2b4 and https://lore.kernel.org/dri-devel/20230110200255.1218738-1-macroalpha82@gmail.com/T/#m77f0be254cbaf4674ee5d925440de884045d56b0
14:20 macromorgan: seems no matter what I do to fix it I just create more problems
14:33 shadeslayer: DavidHeidelberg[m]: getting closer, though I see no apitrace dir in my container or the mesa tar I downloaded, for this instruction : gdb-multiarch ./apitrace/build/eglretrace
14:37 DavidHeidelberg[m]: shadeslayer: mesa tar doesn't have it; it's in the rootfs (container)
14:41 shadeslayer: ahh I see it now
14:42 shadeslayer: hm warning: Can't open file /builds/shadeslayer/mesa/install/lib/libgbm.so.1.0.0 during file-backed mapping note processing
14:44 shadeslayer: DavidHeidelberg[m]: http://paste.debian.net/1266881/
14:45 shadeslayer: I still don't have symbols in the bt
14:52 DavidHeidelberg[m]: shadeslayer: you did run the `find ./install/lib/ -name "*.so*" -print -exec ln debug.dwp '{}'.dwp ';'` ?
14:55 shadeslayer: yeah
14:56 DavidHeidelberg[m]: in general it look ok, if you run bt, what does it produces?
14:56 siddh: <macromorgan> "so I hate to keep asking for..." <- Since fxn signatures are same, If CONFIG_OF is not set, then it will result in redefinition (you have a definition in drm_of.h, then also in drm_of.c), which is what is happening. GCC tells to add static (like static inline int in cases above), and that I guess is so that the definition with ERR_PTR stays only in header file and that is included everywhere.
14:59 siddh: So in the else case in header file, it should be like static inline struct mipi_dsi_host, or static inline int mipi_dsi_host with return being _EINVAL.
14:59 siddh: s/_E/-E
15:02 siddh: Probably return type being int would be better in case static doesn't affect signature.
15:04 shadeslayer: DavidHeidelberg[m]: https://gist.github.com/shadeslayer/561fcb88a1187b34fbc4288c56588f8e
15:05 shadeslayer: I think it can't find the msm driver? warning: Can't open file /builds/shadeslayer/mesa/install/lib/dri/msm_dri.so during file-backed mapping note processing
15:10 DavidHeidelberg[m]: shadeslayer: https://s3.freedesktop.org/artifacts/shadeslayer/mesa/781424/mesa-arm64.tar.zst replace with https://s3.freedesktop.org/artifacts/shadeslayer/mesa/781424/mesa-arm64-unstripped.tar.zst
15:11 DavidHeidelberg[m]: https://mesa.pages.freedesktop.org/-/mesa/-/jobs/34548032/artifacts/public/debugging.html
15:14 shadeslayer: DavidHeidelberg[m]: ahh works now :)
15:14 DavidHeidelberg[m]: 🎊
15:14 shadeslayer: DavidHeidelberg[m]: though I think the url is wrong, it's uploaded to mesa-arm64.tar.zst-unstripped.tar.zst
15:15 DavidHeidelberg[m]: shadeslayer: let me fix that :)
15:17 shadeslayer: s,url,filename, but hey, it works :)
15:19 DavidHeidelberg[m]: shadeslayer: ugly bash variable got updated with .tar.zst prefix and re-used later. Fixed. Now the docs.
15:21 tzimmermann: mripard, done for now
15:22 shadeslayer: DavidHeidelberg[m]: I think the arguments are optimized out though :(
15:23 shadeslayer: warning: Could not find DWO CU src/gallium/drivers/freedreno/libfreedreno.a.p/a5xx_fd5_emit.c.dwo(0x2e19b5a9c0022477) [in DWP file msm_dri.so.dwp] referenced by CU at offset 0xc9ac [in module ./install/lib/dri/msm_dri.so]
15:23 shadeslayer: #5 0x0000ffffb4dd099c in u_upload_alloc () at ../src/gallium/auxiliary/util/u_inlines.h:89
15:26 DavidHeidelberg[m]: BUILDTYPE: "debugoptimized" :(
15:26 DavidHeidelberg[m]: but with full debug it would be too slow to execute test (I assume)
15:40 shadeslayer: yeah, I mean, it's good enough to narrow down things down for me for now, but just thought I'd point it out :)
15:46 DavidHeidelberg[m]: shadeslayer: .gitlab-ci/build/gitlab-ci.yml : 383 to debug should be enough, but won't be applicable for flakes :(
15:48 danvet: javierm, sent out my nice little tour through a few drivers :-)
16:04 mripard: tzimmermann: awesome, thanks
16:07 macromorgan: siddh: thank you, that appears to fix all the errors
16:07 siddh: np :)
16:09 macromorgan: v9 inbound once I test the change... I'll get it right eventually...
16:20 javierm: danvet: hmm, I don't think we can merge patch #11 without breaking one of the bug reported...
16:20 javierm: I'll comment on the ML
16:28 danvet: javierm, hm
16:29 javierm: danvet: ah, no I misread and thought you were moving the sysfb_disable() call but tzimmermann pointed out that you kept the other one too
16:30 danvet: javierm, yeah for everything !pci I think we can safely assume that either a) no other gpu involved (I should clarify that panels over spi and similar wont participate in this so wont cause a problem) or b) really old vga/mga stuff that goes direct to console driver and bypass all this
16:30 danvet: I need to clarify the commit message more I just realized, forgot a few thoughts I had while cooking
16:31 javierm: danvet: panels over spi et al won't be a problem because those drivers don't call drm_aperture_remove_conflicting_framebuffers()
16:31 javierm: same for render only GPU drivers
16:31 dj-death: do NIR expert know how to make uint computations?
16:33 dj-death: I have some operations with a 0xb0000000 that gets turned into another number, assuming that it's an int vs an unsigned int
16:33 danvet: javierm, yeah but I forgot to put that into the commit message
16:33 javierm: danvet: right
16:56 cwabbott: dj-death: you're going to need to give more context for someone to help you
16:58 jenatali: dj-death: What operations?
16:58 cwabbott: NIR doesn't have unsigned/signed integers in its type system, it's the operation (e.g. ilt vs ult) which determines the signedness
16:58 javierm: danvet: r-b patch #11. I disagree with tzimmermann that we should make aperture_detach_devices() aware of primary, it's much easier to understand and leads to simpler code by duplicating the call as you did IMO
16:59 cwabbott: values only have a bitsize and number of channels
17:00 javierm: danvet: besides what you mention, that will be called for each PCI BAR but only once will be a no-op
17:00 danvet: javierm, one thing I noticed ... nothing in aperture.c uses @name
17:00 danvet: not sure how that happened or whether that's a problem for debugging stuff
17:00 javierm: danvet: yup, I noticed that too and was going to suggest to add a cleanup
17:00 javierm: danvet: I think that was used for debugging at some point but that got removed at some point
17:00 danvet: javierm, you mean like drop it?
17:00 javierm: danvet: yeah
17:00 danvet: it feels like it's something we should have a debug printk for tbh
17:01 danvet: but not sure where we lost that
17:01 javierm: danvet: I think we lost because at some point had the previous driver name and said something like "switching from foo to bar"
17:02 javierm: danvet: but yeah, something like "name asks for conflicting drivers with aperture base + size to be removed" as debug printout makes sense
17:03 danvet: javierm, could even pretty print the device now that we have that
17:04 javierm: danvet: right, specially since that function will be only for pdev now, so we could pass that instead of base + size
17:05 javierm: in the past just shared between pdev and pci_dev but you decoupled that in patch #11
17:05 javierm: *was shared
17:08 javierm: danvet: which would be more consistent because drm_aperture_remove_conflicting_pci_framebuffers(struct pci_dev *pdev, const struct drm_driver *req_driver) but
17:08 javierm: drm_aperture_remove_conflicting_framebuffers(resource_size_t base, resource_size_t size, const struct drm_driver *req_driver)
17:09 javierm: that could be drm_aperture_remove_conflicting_framebuffers(struct platform_device *pdev, const struct drm_driver *req_driver)
17:12 danvet: javierm, I had a moment rn because I read pdev and thought what are you mixing up with pci and not using the pci functions
17:12 danvet: then spotted the platform_dev
17:12 danvet: maybe throwing a platform in there can't hurt, not sure
17:13 javierm: danvet: just for consistency and to allow the pretty name that you mentioned
17:15 javierm: danvet: in any case all can be done later, I think your series are the way to go (if ast and others work with the helper and don't need to open code it)
17:15 javierm: danvet: thanks for taking a look to that!
17:16 javierm: and sorry for sending you on a trip down the memory lane again :P
17:18 dj-death: cwabbott: thanks, I'm seeing a nir_isub(some_value, 0xb8000000) being turned into a nir_iadd(some_value, 0x38000000)
17:21 dj-death: cwabbott: maybe it's a backend thing :/
17:21 dj-death: no sorry, turned into nir_iadd(some_value, 0x48000000)
17:26 anholt: NIR_DEBUG=print and see where it shows up?
17:27 pendingchaos: I think those two instructions do the same thing
17:28 pendingchaos: opt_algebraic unconditionally does this to all subtractions
17:30 javierm: danvet: so I think aperture_detach_devices() should get the name and then print what device is detached due conflicting with what driver
17:31 danvet: yeah maybe
17:32 javierm: danvet: anyways, I can type a patch on top of your series once it lands
18:30 siddh: Hello everyone, I want to participate in XorgEVoC and contribute to DRM. Motivation for this is my liking and inclination towards kernel stuff (I started my kernel journey in June 2022 and am a long-time Linux enthusiast), and I have academic requirements to do some work for 3 months.
18:30 siddh: I am thinking of doing some TODO tasks. While I'm not sure what would be acceptable, I made an initial list to get started in making the proposal and get it through by Feb. You can view it at: https://gist.github.com/siddhpant/91c5e528083a68eefd0d01b971e2b48d
18:30 siddh: Please give your inputs, like whether some TODO tasks need more priority or attention according to you, or if there is any problems with list, or if I should punch more above my weight. It would be very helpful in polishing up and finalising things. Thanks!
21:19 airlied: zmike: okay I think I got em all on that leak MR, just letting it the pipeline run to confirm
22:12 zmike: 💪
22:14 HdkR: :strongbad:
22:15 mattst88: rodrigovivi: any clue what's holding up https://lists.freedesktop.org/archives/intel-gfx/2022-November/313535.html ?
22:16 mattst88: we're struggling to reproduce a hang on Google Meet, but users are seeming to trigger it easily, but the batch buffer isn't being captured :(
22:27 rodrigovivi: mattst88: I'm going to sync tomorrow morning with tursulin on this... I believe he was involved with the reviews already and have a much better context to review it quicky
22:27 mattst88: okay, thanks!