00:04airlied: does anyone know if valgrind and ralloc just dislike each other?
00:05airlied:is seeing a lot of leaks in nir shader generation
00:07airlied: either that of we have a program reference leak
00:09Sachiel: built with valgrind support? I recall ralloc being one of the many things there using the vg macros to tell valgrind what's going on and report things correctly
00:11anholt_: airlied: that should be an actual leak
00:11Sachiel: apparently I recall incorrectly
00:11anholt_: or maybe I've just never built without valgrind macros?
00:11airlied: vg macros aren't used in ralloc from what I can see
00:11airlied: it's used in the various bufmgrs
00:12airlied:will dig a bit more then
00:12imirkin: airlied: i've never seen issues with glsl, which uses ralloc a lot
00:13Sachiel: yeah, I wrongly assumed it did because I also don't remember seeing valgrind complain about it
00:16airlied:prepares to get lost in gl_program/st_program/gl_shader_program twisty maze
00:17bnieuwenhuizen: airlied: since ralloc is plain on top of malloc and IIRC doesn't use weird pointer magic it mostly should just work?
00:17airlied: bnieuwenhuizen: yeah I was just hoping I woudln't have to dig into this and it was simple :-P
00:18airlied: but my cts runner is at 42GB now :-P
00:19imirkin: nir_variable *nvar = ralloc(state->shader, nir_variable);
00:19imirkin: that's the thing that's leaked
00:19imirkin: shader is a nir_shader
00:19airlied: yeah which makes no sense unless the shader leaks
00:20airlied: since it's all ralloc
00:20bnieuwenhuizen: unless state->shader = NULL?
00:26imirkin: doesn't look possible
00:26imirkin: airlied: could be that something's still holding onto this stuff at the end
00:26imirkin: airlied: the shader itself is leaked... look at
00:26imirkin: ==373312== by 0x4F5E7DE: nir_shader_create (nir.c:45)
00:27airlied: oh it could be a driver leak
00:27airlied: st had that the first person owns the shader thing
00:27airlied: first variant
00:27airlied: thoug not sure that should leak
00:27airlied: the driver doesn't take owernship there either
00:28airlied: ah yeah it does seem like a driver leak, let me dig in and copy what other drivers do :-P
00:41airlied: opkay sorry for noise, llvmpipe was leakin :-P
02:57bl4ckb0ne: should I squash all of the commits into a single one in my merge request?
03:00imirkin: probably not
03:00imirkin: haven't looked tho
03:05bl4ckb0ne: someone suggested I should merge 1 and 3 together, so why not merge all 3
03:09bl4ckb0ne: well ill see that tomorrow
03:12imirkin: right, so...
03:12imirkin: each commit should compile
03:13imirkin: if you only apply the first commit, it won't compile
03:13imirkin: the version.c change is wrong - just remove it
03:13imirkin: and i'd only expose EXT_draw_instanced on ES2, so put 'x' instead of GLL/GLC
03:14imirkin: oh, i see, you undo it...
03:14imirkin: yeah, no point in adding and then removing code
03:15imirkin: i think in this instance, you can squash all 3 into one, and the end result will be better
03:15imirkin: and finally, don't add random newlines in the code
06:59j4ni: danvet: re the kconfig stuff, I should start a blog and write an entry about the issue, and reference that every time
06:59j4ni: or something. the thing hasn't fundamentally changed in literally years
07:01j4ni: the only thing that's changed is the increased abuse of IS_REACHABLE for working around the issues
07:02danvet: j4ni, I think blog post would be excellent
07:02danvet: so I can quote it with replies instead of pinging you every time it comes up
07:03danvet: "Everything broken with select" or something splashy like that
07:06j4ni: "select considered harmful" I think is the quintessential title
07:11tomba: I noticed that tidss is crashing on v5.7-rc1 when unloading the module. I think it's related to using devm_kzalloc. I'll start fixing those today. But I wonder if anyone has idea what has changed? I didn't see anything change in the DRM side. And I also wonder if other drivers have started breaking the same way, as I see devm_kzalloc used in some other drivers too.
07:12j4ni: tomba: hum, maybe you should switch to the drmm_* alternatives
07:13j4ni: shiny new, won't help with -rc1 I guess :(
07:13tomba: j4ni: yes, but they're not in 5.7
07:15j4ni: tomba: danvet here can explain in detail why devm is broken for drm devices...
07:15tomba: what's the best way to free e.g. encoder. is it ok to kfree it in the encoder's drm_encoder_funcs.destroy hook? or should there be a separate step in the teardown process to kfree all the objects
07:15tomba: j4ni: I think I understand why it won't work. It just worked fine before, so something changed between 5.6 and 5.7, outside DRM
07:16tomba: I mean, happened to work by luck earlier
07:16danvet: tomba, yeah if you allocate structures that contain drm_* structs with devm_kzalloc
07:16danvet: you'll have bugs on unload
07:16j4ni: for encoders kfree in destroy hook should be fine (so long as it was kmalloced)
07:17danvet: I'm working on the infrastructure so that you dont have to sprinkle endless amounts of kfree all over
07:17danvet: wrt -rc1 I'd say the work required to fix it if you're using devm_kzalloc everywhere is so much
07:17danvet: that it doesn't really qualify for -fixes
07:17danvet: you'll need to rewrite tons of load code and pretty much reinvent drmm_ if you dont want to do that
07:18danvet: the trouble is that drmm_ is also not yet fully ready
07:18j4ni: 12 devm_* instances in tidss/, not necessarily too much for fixes
07:18danvet: since I haven't gotten around to start with the stand-alone mode_objects like drm_encoder
07:18danvet: j4ni, it's the kfree you also need to sprinkle into all error cases that kill
07:19tomba: danvet: hmm well, I can't have this crashing, so I need to fix it somehow.
07:19danvet: tomba, s/devm_kzalloc/kzalloc/
07:20danvet: replace the crashes with leaks
07:20tomba: danvet: lets see how it ends up looking. but as I said above, there might be other drivers crashing now too.
07:20danvet: hm that'll break with probe defer I guess
07:20danvet: tomba, well if it's a regression maybe bisect?
07:20danvet: but yes in general you can assume that any devm_kzalloc in drm drivers is a bug
07:21danvet: I've starred at enormous piles of them for the drmm work, and thus far none that werent a bug
07:21danvet: $ git grep devm_kzalloc -- drivers/gpu/ | wc -l
07:21danvet: tomba, ^^ you're in good company at least
07:23tomba: danvet: I don't think it's a regression as such. It's broken. Something is just bringing the bug to surface now.
07:24danvet: tomba, well if it's something that changed in drm still worth undoing maybe
07:24danvet: since there's so many drivers which get this wrong
07:24tomba: danvet: I don't think so, I have a drm-next branch from a bit earlier, that was working fine. Only with 5.7-rc1 it started crashing. and DRM diff between those two branches was minimal.
07:25danvet: hm yeah then maybe it's just the allocator that now gives you a more unlucky pattern
07:25danvet: disabled all the debug options already?
07:26tomba: no. I'm sure there's a chance it'll work if I disable everything, but I don't want that =).
07:27tomba: but lets see what the fix looks like. at least fixing many of the drm objects should be trivial.
07:27tomba: maybe that's enough, as drm_device is not devm_alloc'ed in tidss
07:28danvet: so if you build this on top of drm-misc-next
07:28danvet: with drmm_mode_config_init
07:29danvet: then all you need is kfree added to your ->cleanup hooks everywhere
07:29danvet: and you should be able to avoid adding the kfree to all the error paths
07:29danvet: if done right
07:29danvet: still pretty enormous amounts of boilerplate you'll add
07:29danvet: and which I'll go and probably remove again rsn ...
07:29danvet: on top of 5.7 it's even more fun
07:30danvet: that's kinda the other reason I'm not super enthusiastic about fixing this in 5.7, it's going to rain conflicts
07:30tomba: danvet: yes. I think I won't even try a full fix. I'll probably have to accept a leak for error cases.
07:39MrCooper: mdnavare: VRR can work with both sync & async flips, it's orthogonal; async just means there's tearing if the flip is programmed outside of vertical blank
08:04dj-death: anybody would have a clue as to why a call to glCreateShader() ends up in noop_generic()
08:04dj-death: I'm fairly clueless when it comes to setup a GL context :)
08:05daniels: dj-death: called eglMakeCurrent? glBindAPI?
08:07dj-death: daniels: thanks, will check
08:07dj-death: (not my code)
08:07dj-death: marge failed a build with : /usr/bin/ld: final link failed: No space left on device
08:30hakzsam: daniels: https://gitlab.freedesktop.org/hakzsam/mesa/-/jobs/2285979#L973
08:33daniels: hakzsam: thanks, cleaned up manually. bentiss has been hard at work on something which will make sure this doesn't ever happen at all, which we hope to push out this weekend
08:35dj-death: daniels: thanks
09:05airlied: dj-death: usually a missing makecurrent
09:06danvet: tzimmermann, I guess the topic branch pull from mlankhorst is for you
09:07dj-death: airlied: thanks, that's what it looks like indeed
09:07tzimmermann: danvet, topic/phy-comlience? i see
09:08danvet: dim apply-pull for the tooling
09:09tzimmermann: danvet, thanks. i won't have time today, but i'll do this tomorrow
09:11danvet: tzimmermann, also -rc1 so time for first pull
09:11danvet: and summarizing this one is work since it's the biggest
09:15tzimmermann: danvet, i sent it out already: https://lists.freedesktop.org/archives/dri-devel/2020-April/262205.html
09:16danvet: oh cool, I guess I missed this somehow
09:17danvet: j4ni, ^^ direct apply would indeed have been faster :-/
09:18danvet: dolphin, do we have an drm-intel pull ready too so we could pile them up?
09:18danvet: hm no agd5f
09:20danvet: airlied, I rolled -next to -rc1, should I also apply the pull from tzimmermann?
09:21dolphin: drm-intel pull for what?
09:21danvet: dunno, is there nothing?
09:21dolphin: next one for me is drm-intel-next, have not looked at it yet
09:22danvet: yeah that's what I meant
09:22danvet: dim status says there's a pile there
09:25tomba: danvet: sent the fix. it doesn't look too bad. but will probably conflict with your series.
09:25danvet: tomba, I don't think so, I'm not yet wreaking havoc with drm_connector/encoder/plane/crtc
09:28tomba: danvet: oh, true. I thought "drm/tidss: Don't use drm_device->dev_private" would conflict, but it doesn't look like it's touching nearby code. maybe.
09:31danvet: tomba, anyway feel free to slap an a-b: me onto this
09:32tomba: danvet: ok, thanks
09:41sravn: danvet: I wonder what holds you back applying "drm: Add devm_drm_dev_alloc macro"?
09:42sravn: danvet: With that patch applied the need to synchronize the other clean-up in on big series goes away
09:42danvet: sravn, more consensus soaking
09:42danvet: plus I broke the selftests in intel-gfx-ci, I want to make sure this version passes everything
09:43jcristau: win 158
10:09airlied: danvet: if you like i sometimes wait for rc2
10:09airlied: just to have a bit more stable base
10:12danvet: yeah I guess we can wait, nothing major
11:14danvet: pinchartl, got time for the drmm_ discussion?
11:14danvet: I'd like to land devm_drm_dev_alloc so I can land all the conversions
11:14danvet: and new simple drivers dont have to hand-roll stuff anymore
11:15pinchartl: danvet: I'm very short on time today :-( could we try tomorrow ?
11:47tomba: danvet: what's the "devm_drm_dev_alloc, v2" series based on? I can't find one where it applies.
11:53emersion: where should nouveau kernel bugs be reported?
11:53cwabbott: jekstrand: thinking about it a bit more, maybe we want an address format where the index is multiplied by ALIGN_MUL and added to ALIGN_OFFSET to get the byte offset
11:53emersion: it seems like they've been migrated to xf86-viudeo-nouveau
11:53gitbot: driver issue 480 in xf86-video-nouveau "Moving gbm bo from GART to VRAM does not wait for rendering" [Opened]
11:54cwabbott: so instead of just an alignment, they become your multiplier/offset
11:54cwabbott: I think that would help with our existing SSBO pass too
12:02danvet: emersion, some also get stuffed into drm/misc I think
12:02danvet: it's a bit a mess
12:03danvet: maybe should start having labels and stuff
12:03danvet: but I suspect drm/misc will become the abandonware dumpster pile
12:20MrCooper: danvet: I moved nouveau issues to drm/misc because it already had a nouveau label
12:20MrCooper: or is that a drm group label?
12:22MrCooper: danvet: aren't the separate amdgpu flip paths you mentioned for non-DC?
12:28danvet: MrCooper, indeed
12:29danvet: I got totally lost in there, once more
12:29MrCooper: only DC supports VRR
12:29danvet: I guess no way we can ever delete the non-DC code?
12:30MrCooper: not before someone closes the feature gap in DC for CIK, and adds DC SI support
12:30danvet: yeah I dont think that'll happen
12:31danvet: forking drivers ftl
12:31danvet: (not against forking, just like ... fork the part you're actually changing, not everything just because)
12:34danvet: MrCooper, I guess the lack of page_flip_target support in DC is what throws me off on this one
13:29haasn: INTEL-MESA: error: ../src/intel/vulkan/anv_device.c:2760: GPU hung on one of our command buffers (VK_ERROR_DEVICE_LOST)
13:29haasn: always a fun one to debug
13:42zq: is it just me or does aco lack use-lists
13:43pendingchaos: zq: it lacks use-lists
13:43dschuermann: depends on how you define 'lack'
13:44zq: dschuermann: simple thing, i see that dce has to tally up use counts
13:45zq: it's interesting that fast codegens seem skip having this. cretonne for instance lacks use-lists too.
13:48dschuermann: it's just not needed in almost all cases for ssa-based backends
13:50zq: was aco intended to be a fast codegen, or an optimizer + codegen?
13:51zq: thought this was meant to replace the default llvm path entirely
13:55dschuermann: zq: it is meant as replacement for llvm as backend for NIR. what confuses you might be that llvm contains a complete middle-end
13:55dschuermann: so, it's more of the MIR part of llvm, and we leave all middle end optimizations to NIR
13:59zq: dschuermann: yes i'm aware that llvm has an optimizer and codegen. i've written code for both. (:
14:05dschuermann: zq: llvm does also late optimizations on MIR. I think you can better compare aco to that part. we only do hardware-dependent optimizations
14:06jekstrand: cwabbott: I'm not sure I'm fan of that because I don't want to limit the range of align_mul or weirdly tie it to things.
14:06jekstrand: You don't want it to be in units of align_mul, you want vec4
14:07zq: ah, i see it now
14:07zq: nir has use-lists
14:09zq: dschuermann: right, i got that
14:12zq: could do better than bitvector liveness
14:12zq: could definitely do a lot better than carrying around DF
14:33pq: How do you know if the kernel will be setting the crtc field of DRM flip_complete events?
14:34pq: me/you in userspace, that is
14:35pq: must be something to do with DRM_CAP_CRTC_IN_VBLANK_EVENT
14:42bnieuwenhuizen: zq: The core of the argument against it is that doing the full flow a few times for the passes that need it is faster than maintaining a more complicated datastrcture all the time
14:43bnieuwenhuizen: turns out a lot of passes don't really need it
14:44pq: What does DRM_CAP_PAGE_FLIP_TARGET tell to userspace? What UAPI is relevant to it? Is it drm_crtc_queue_sequence?
14:44daniels: pq: yep, for giving a target vbl seq to pageflips
14:45pq: daniels, how does that work?
14:45emersion: pq: yeah, DRM_CAP_CRTC_IN_VBLANK_EVENT means the kernel tells you which CRTC a vblank has happened on
14:46emersion: also see page_flip_handler2
14:46pq: emersion, I was looking at page_flip_handler2 and started wondering how do you know the crtc field is actually delivered :-)
14:49pq: daniels, I'm confused. To me it looks like drm_crtc_queue_sequence is only for getting a vblank event for a certain seq. I don't see how it connects to pageflips.
14:49pq: and it seems to be a separate ioctl, so I guess it's legacy KMS
14:50MrCooper: pq: it works with the legacy page flip ioctl; set the DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE/RELATIVE flag, and the target vblank sequence for the flip (can only be the current or next one) in the sequence field
14:50pq: aha, thanks
14:50MrCooper: it's only used to disambiguate in case the flip becomes ready during vertical blank, not for queuing the flip
14:51pq: how very... undocumented?
14:53alyssa: oh joy... if I don't apply the fix it faults, but if I do, it reads back random data
14:53MrCooper: pq: there's a comment in drm_mode.h
14:56pq: found it - google didn't
14:57pq: so... drm_crtc_queue_sequence is something else?
14:58emersion: yeah, drm_crtc_queue_sequence was originally for mesa's direct drm vulkan backend
14:59emersion: simple example usage https://github.com/emersion/drm_monitor/blob/master/main.c#L32
15:00vsyrjala: it's the 64bit wait vblank ioctl
15:00emersion: well, it doesn't block
15:00vsyrjala: neither does the old wait_vblank unless you ask it to
15:00emersion: old wait vblank returns immediately
15:01emersion: the 64-bit equivalent would be drmCrtcGetSequence
15:01vsyrjala: the wait vblank ioctl can be used many ways: block/event/query
15:01emersion: didn't know about the event part
15:01pq: thank you, now I know too much ;-)
15:25karolherbst: ehhh.. https://gitlab.freedesktop.org/karolherbst/mesa/-/jobs/2291037
15:25karolherbst: "error: RPC failed; curl 18 transfer closed with outstanding read data remaining" :/
15:48daniels: karolherbst: transient problem, should already be fixed
15:49karolherbst: cool, thanks
16:47sravn:was off for today but then I got "FAILURE: Could not merge drm-misc/drm-misc-next". :-(
16:52sravn: MAINTAINERS - as one could expect
17:04sravn: Blindly following drm-tip.rst solved it - pheeewww
17:07sravn: pinchartl: Did you see responde from Dimitry. Maybe we should be better explaining that DRM_BRIDGE_ATTACH_NO_CONNECTOR is the correct way - or do we wait for the majority of bridge drivers to be migrated?
17:14pinchartl: sravn: where do you think we should put that information to make sure it gets noticed ?
17:20sravn: pinchartl: documentation of drm_bridge_attach() - here we should be specific about what is current and what is deprecated. In other words encourage new users to pass DRM_BRIDGE_ATTACH_NO_CONNECTOR
17:21sravn: But we could wait a bit doing so - maybe we can suceed migrating a few more bridge drivers over so the entry is less steep.
17:25pinchartl: sravn: I'm not sure it will be read, but if we don't try, we won't know :-)
17:25pinchartl: so I think it's a good idea to mention it there already
17:35danvet: ime convert a few over, so that there's at least some varied set of examples you can point people at
17:36danvet: sravn, pinchartl btw also starting a bit a thing against direct calls to stuff like dw_hdmi_probe
17:36danvet: that one's even worse :-)
17:37sravn: danvet: saw your comment on dw_hdmi_probe, but dunno how to fix it. And the plate is anyway full of janitorial work already..
17:37danvet: sravn, I commented on at lesat the arc patch
17:37danvet: to make it at least not worse
17:38danvet: plus I'm going to move one misplace header out of include/drm/bridge/
17:38sravn: The arc comment was what I referred to. Any cleanup we can use in other places is welcome
17:39danvet: sravn, fixing the existing users is going to be a lot harder
17:39danvet: least because rmk
17:42sravn: No reason to start moving headers and such before we have a solution that we think works for all
17:42danvet: sravn, I thought we have that now?
17:42danvet: also the header is definitely misplaced
17:44sravn: Oh, so when we move the connector creation to the display driver we can get rid of the dw_hdmi platform drivers.
17:44danvet: sravn, the hold-up with dw-hdmi wasn't the connector stuff
17:44danvet: but some ordering stuff around driver load and suspend/resume
17:45danvet: which component.c fixed, but not the direct bridge stuff
17:45danvet: iirc we had a patch to add a device_link
17:45danvet: except it's still not merged, but whatever someone needs to get this moving
17:45sravn: I recall some device_link some time ago - I did not get it back then.
17:46sravn: Anyway - I will try to help Laurent with the bridge conversion first. One step at a time.
17:46danvet: the connector stuff is an entirely orthogonal thing
17:46sravn: And then I also need to find time to finish my little binding adventure
17:46danvet: also good to fix up
18:25mdnavare: danvet: Quick question, so for the page flip request from userspace or IGT after framebuffer is ready, do we just call igt_display_commit_atomic () which will call drmModeAtomicCommit or shd we explicitly call drmModePageFlip ?
18:25mdnavare: danvet: which will then call DRM_IOCTL_MODE_PAGE_FLIP
18:30danvet: well if we want to keep the async test, then needs a direct call
18:30danvet: but for the atomic go through the igt_display stuff
18:30danvet: so that we can flip VRR_ENABLED and fb together
18:30danvet: bit of duplication, but oh well
18:30danvet: or extend igt_display to handle async_flip mode
18:31mdnavare: danvet: so just call the igt_display_commit_atomic() with ALLOW_MODESET first and then call this again with DRM_MODE_PAGE_FLIP_EVENT, and that should dothe page flip atomically?
18:34mdnavare: danvet: and for VRR i can ust do this with sync flips like we discussed correct? so then ust the commit_atomic call will call the atomic ioctl and that will do the flip automatically?
18:35mdnavare: danvet: drmModePageFlip call will be for legacy right?
18:41mdnavare: danvet: so is my understanding correct here that if we use igt_display_commit_atomic() which goes through the drm_ioctl_mode_atomic, it will execute the flip atomically but for non atomic drivers we need to do this call explicitly for the page flip: drmModePageFlip ?
18:42danvet: there's 0 relevant non-atomic drivers, so this doesn't matter
18:42danvet: it's only really about the async page flip thing, which isn't exposed through atomic
18:49mdnavare: danvet: yes correct, so what you are saying is that for non async flips the direct drmModePageFlip is pretty much obsolete
18:55mdnavare: danvet: ?
19:14Lyude:has now learned about spinlock nesting rules the hard way :(
19:14ickle: at least you learnt
19:14Lyude: yeah :P
19:15ickle: I suppose PREEMPT_RT will make them debuggable
19:38karolherbst: do we save piglits version in the result files?
19:38karolherbst: from a quick look I didn't see anything
20:24jekstrand: dcbaker: What's going on here?
20:24jekstrand: ../meson.build:21:0: ERROR: Unable to determine dynamic linker
20:24dcbaker: what compiler are you using?
20:24dcbaker: what does cc -Wl,--version return
20:25jekstrand: collect2 version 9.2.1 20190827 (Red Hat 9.2.1-1)
20:25jekstrand: /usr/bin/ld -plugin /usr/libexec/gcc/x86_64-redhat-linux/9/liblto_plugin.so -plugin-opt=/usr/libexec/gcc/x86_64-redhat-linux/9/lto-wrapper -plugin-opt=-fresolution=/tmp/ccJo31Yh.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --build-id --no-add-needed --eh-frame-hdr --hash-style=gnu
20:25jekstrand: -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 /usr/lib/gcc/x86_64-redhat-linux/9/../../../../lib64/crt1.o /usr/lib/gcc/x86_64-redhat-linux/9/../../../../lib64/crti.o /usr/lib/gcc/x86_64-redhat-linux/9/crtbegin.o -L/usr/lib/gcc/x86_64-redhat-linux/9 -L/usr/lib/gcc/x86_64-redhat-linux/9/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/9/../../..
20:25jekstrand: --version -lgcc --push-state --as-needed -lgcc_s --pop-state -lc -lgcc --push-state --as-needed -lgcc_s --pop-state /usr/lib/gcc/x86_64-redhat-linux/9/crtend.o /usr/lib/gcc/x86_64-redhat-linux/9/../../../../lib64/crtn.o
20:26dcbaker: it's trying to figure out whether to pass gnu-like arguments, apple-like arguments, or sys-v-like arguments
20:26dcbaker: and it has no idea what collect2 is
20:26jekstrand: This just started happening and I've done no system config changes
20:27jekstrand: Hrm... Killed my shell and started a new tab and now it works
20:27jekstrand: No idea what I messed up
20:27dcbaker: There should be something like "GNU ld (Gentoo 2.33.1 p2) 2.33." in the version output as well
20:39jekstrand: dcbaker: In my new terminal that actually works `cc -Wl,--version return` returns
20:39jekstrand: cc: error: return: No such file or directory
20:39jekstrand: dcbaker: It still dumps out the collect stuff but now it has
20:39jekstrand: GNU ld version 2.32-31.fc31
20:39jekstrand: Copyright (C) 2019 Free Software Foundation, Inc.
20:39jekstrand: This program is free software; you may redistribute it under the terms of
20:39jekstrand: the GNU General Public License version 3 or (at your option) a later version.
20:39jekstrand: This program has absolutely no warranty.
20:40dcbaker: as long as it has "GNU ld" or "GNU gold" meson knows what to do
20:40jekstrand: No idea why it was dumping something else before
20:40dcbaker: updates maybe?
20:40jekstrand: Wasn't installing any AFAIK
20:41dcbaker: "I rebooted and it works now"
20:41jekstrand: "Hello. IT. Have you tried turning it off and back on again."
20:45zq: bnieuwenhuizen: was that for liveness of df?
20:52dschuermann: zq: df = dominator forest?
20:53bnieuwenhuizen: zq: use-lists?
20:56dschuermann: err, df=data flow (analysis) , I guess
21:00zq: dschuermann: dominance frontier, sorry
21:01zq: bnieuwenhuizen: wait, use-lists are re-computed on-demand?
21:01zq: in nir?
21:02zq: dschuermann: each nir block carries its dom frontier as well and i find that...inefficient
21:05zq: at first glance, anyway. it would be interesting to know what the empirical motivation for that was
21:09dschuermann: zq: def-use lists are updated, not recomputed in NIR
21:11dschuermann: zq: without df, we need in aco to iterate through the immediate dominators in our value_numbering pass. but as it's the only occasion it doesn't justify building the df
21:12dschuermann: for NIR, these things are different as it does way more passes with often very few changes, while the backend typically does few passes with lots of changes
21:53anholt_: should info->tess.primitive_mode be set for the TCS? freedreno wants it on both sides, but looks like maybe the api doesn't necessarily give that to you?
21:53anholt_: (due to separable shaders)
21:56imirkin: that's right ... you can set it when you have the full pipeline. the primitive mode is for the tessellator though, no?
21:57anholt_: it affects memory layouts for TCS inputs on freedreno, so we have shader variants for it.
21:58anholt_: TCS outputs I mean
21:58anholt_:is still bad at this pipeline
21:59imirkin: that sounds wrong
21:59imirkin: why would the primitive mode affect TCS <-> TES varying linkage?
22:00imirkin: should be driven by the output patch size
22:00imirkin: (which is also, annoyingly, specified by the TES)
22:01imirkin: you could feed the patch size in via a const though, and drive layout off that
22:19Lyude: yay, vblank workers w/ kthread_workers work :)
22:36mareko: anholt_: I think you meant that it affects the format of TCS tess factors, not TCS outputs
22:37imirkin: ah yes. it can do that.
23:12jvesely: dcbaker: hi, does pr 4457 look good enough to switch to marge to you?