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