00:21 bl4ckb0ne: id like to port waffle on xdg shell and i see there's already a 4 month old WIP, should I start from there or start over?
00:23 airlied: probably start from it, I doubt waffle has moved that far
00:28 bl4ckb0ne: i think ill start from scratch, a few deleted things need to be brought back
00:28 bl4ckb0ne: but ill keep the wip as a reference
00:34 bl4ckb0ne: is there a prefered build system for waffle, or should both cmake and meson produce the same binaries
00:38 dcbaker[m]: bl4ckb0ne: they should both work until we drop cmake
00:40 bl4ckb0ne: thanks dcbaker[m]
00:40 dcbaker[m]: It's been long enough we might be able to talk about dropping cmake
00:42 bl4ckb0ne: i can start with meson and add cmake after
02:25 Lightkey: https://twitter.com/icculus/status/1288296438456356866 Eh.
02:44 robclark: jekstrand: you can add my a-b for the single-list MR.. I didn't really try to review *all* of it since it is a lot of churn, kinda relying on CI to do that for me.. but happy w/ the nir iterators and the ir3 parts
02:45 robclark: if you are feeling paranoid, then land it after the next stable branchpoint.. but tbh I think we have enough coverage of nir in CI that we can be more confident than that..
04:24 jekstrand: robclark: Cool. I'll likely give it another good CI run both in GitLab and the Intel CI tomorrow and land it.
04:25 jekstrand: robclark: As much as I like the "wait until after the branchpoint" argument for big features, for reworks like this doing it before will save us a lot of pain with backports.
04:44 airlied: robclark: have you sent msm-next?
06:15 bbrezillon: karolherbst: actually I didn't get access to intel CI
06:15 bbrezillon: I just push to kusma's repo :)
08:19 flier: hi, is there a way to enable more logging for i915 driver? i am trying to figure out where it selects llvmpipe renderer (i know why, i have a intel comet lake graphics so probably some pci ids do not match)
08:20 danvet: airlied, not all of könig's patches are in -misc-next yet
08:20 danvet: there's an oversight in the system defaults one, vmwgfx is special
08:20 danvet: I think we're waiting for an ack from roland or so
09:08 MrCooper: iris devs, any ideas why GPU clocks seem to stay lower compared to i965 (see https://gitlab.freedesktop.org/mesa/mesa/-/issues/3205#note_573993)?
09:09 MrCooper: Daniel closed it in favour of https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1383 , but that just seems like a workaround for the GPU not clocking up even after tens of ms, missing up to two display refresh cycles
09:10 ickle: because the GPU is idle
09:10 MrCooper: when two refresh cycles are missed, it's not idle for tens of ms
09:11 MrCooper: and that doesn't explain the difference between iris & i965?
09:11 ickle: if you miss the deadline (the only one we know is vblank after the flip request), you get pushed to max
09:12 ickle: you don't get upclocked if you are idle, and it has a tendency to be conservative
09:13 MrCooper: sounds impossible to get good latency for the first frame after an idle period then
09:13 ickle: correct
09:17 ickle: we do return to the previous frequency after idling, but there's no guarantee that the workload is equivalent, and waking up incurs a few hundred microseconds of delay
09:26 karolherbst: ickle: wouldn't it make sense to scale up to max and lower quickly instead?
09:26 ickle: we try to
09:27 tomeu: what happened to scaling up on input events?
09:28 karolherbst: tomeu: that would produce tons of false postiives, no?
09:28 ickle: until you tie an input event to the GPU, we have no idea which is the right sign of interactivity
09:28 tomeu: would it?
09:28 karolherbst: tomeu: scaling up to max whenever you move your cursor?
09:28 karolherbst: sounds like a bad idea to me
09:28 tomeu: I thought we were doing something similar nowadays to come out of PSR
09:29 tomeu: karolherbst: maybe not to max
09:29 ickle: the wishlist is basically SCHED_DEADLINE
09:29 ickle: and then compute the capacity required to meet the deadline
09:30 karolherbst: ickle: mhhh
09:31 karolherbst: that sounds like something where you can miss things as it depends on when things are happening
09:31 karolherbst: ickle: are you monitoring engine loads?
09:31 ickle: and all the other classes of work that are simply sustained/bursty loads
09:32 ickle: yes
09:32 karolherbst: I played around with implementing something like that for nouveau and schecking each 10ms usually gave quite good results igoring everything except engine loads
09:32 karolherbst: even played around with 1ms
09:32 ickle: yup
09:33 danvet: MrCooper, there's been epic discussions at khr for an extensions to communicate deadlines down the stack
09:33 danvet: so that we could stop guessing
09:33 karolherbst: 1ms was nice.. but that lead to tons of reclocks and I started to hit bugs :D
09:33 danvet: and avoid the nagative feedback loop
09:33 danvet: but it's still stuck in bikeshedding
09:33 danvet: negative feedback loop of client starts dropping frames because it misses, which makes the kernel lower the frequency because utilization drops
09:34 ickle: which is the loop the issue is stuck in
09:34 karolherbst: danvet: I hate clients dropping frames :p they shoulod just keep it coming imho :p
09:34 karolherbst: (but that's more related to games which do their "magic")
09:35 karolherbst: inserting fake frames copying the result of the last one, etc...
09:35 danvet: ickle, yeah that's why I brought this up
09:35 danvet: you still can't fix the first frame, since predicting the future is still hard
09:35 danvet: but at least the broken feedback loops should be fixable
09:35 karolherbst: yeah.. from an user perspective the first frame hardly matters, I think that's fine
09:35 danvet: karolherbst, you do absolutely _do_ want to drop frames if you're above the ceiling
09:35 danvet: and there's no more upclocking headroom
09:36 danvet: because if you don't, latency goes down the toilet
09:36 danvet: and that sucks
09:36 danvet: the problem is that that you 2 controllers (kernel controlling frequency, client controlling render framerate) who don't coordinate
09:36 danvet: and then hilarity ensues
09:37 karolherbst: right...
09:37 ccr:plays "yakety sax" Benny Hill theme
09:37 karolherbst: I still don't like what some games are doing as this causes other weird issues
09:37 danvet: yeah it's either yakety sax or nothing at all happening
09:37 karolherbst: but yeah.. for compositors I think I see the benefit
09:37 danvet: karolherbst, not adjusting framerate in vr leads to vomiting
09:37 danvet: for many people at least
09:37 karolherbst: ohhh. right
09:37 karolherbst: I forgot about VR
09:38 danvet: outside of vr it just leads to annoyed users, jerky experience and missed headshots in competitive fps
09:38 karolherbst: well... they won't use intel anyway :p
09:38 karolherbst: but yeah
09:38 danvet: it's s khr extension for everyone
09:39 karolherbst: right
09:39 danvet: I think the way nvidia solves this is just clamp frequency to max if it's a game
09:39 danvet: so that one of the controllers stops controlling
09:39 karolherbst: nope
09:39 karolherbst: they lower the freqs
09:39 karolherbst: they start at max
09:39 karolherbst: so if you create a new context they ramp it up to max
09:39 karolherbst: and then lower after a few seconds to cover the load
09:40 danvet: hm I thought they have that controller death spiral a lot less
09:40 karolherbst: ohh, it _can_ take a long time until it lowers
09:40 danvet: at least they claimed that
09:40 karolherbst: sometimes I saw 60 seconds until they dropped
09:40 ickle: I'd get screamed at if I start each new stream at max
09:40 danvet: ah, so yeah if the freq controller is controlling much slower than the client dropping frames it's less of a problem
09:40 karolherbst: ickle: well.. nvidia can ignore laptop use cases :p
09:41 danvet: the mess starts if both control at roughly the same rate (which ideally would be for each frame)
09:41 karolherbst: yeah
09:41 karolherbst: they mitigate very variable loads this way
09:41 danvet: yeah you can't do that on really mobile machines
09:42 danvet: people ready their pitchforks if you do
09:42 karolherbst: right, that's why I was playing around with 1ms interval to adjust clocks checking engine idle counters
09:42 karolherbst: was fun to play with that
09:44 karolherbst: if displays could just display at 1Hz up to 120Hz and we could simply race to idle :p
09:45 danvet: I think big reason why state of the art sucks so much is that on windows there's no combined benchmark for power consumption and interactive latency
09:45 danvet: yeah except race to idle isn't efficient
09:45 danvet: overshooting is a serious problem at least for our gpu when you hit thermal limits
09:46 karolherbst: yeah.. I guess for a GPU that's not as simple as for a CPU
09:46 danvet: yeah cpu seems more ok with overshooting
09:46 karolherbst: you also have a bigger benefit putting the core to sleep than running at lower freqs as well
09:46 danvet: for gpu it's often better to aim for max perf/power peak
09:46 danvet: yeah
09:52 MrCooper: ickle danvet: I hit a similar issue with the APU in this Thinkpad, but after a BIOS update it's working great: https://gitlab.freedesktop.org/drm/amd/-/issues/1146
09:53 MrCooper: the Intel behaviour seems possibly appropriate for battery only, but maybe not so much for AC?
09:53 ickle: shared TDP
09:54 ickle: awake and idle at max frequencies is 1W
09:55 MrCooper: how is that relevant for missing the first refresh cycle, when it's able to sustain full frame-rate with triple buffering?
09:56 ickle: I was thinking your intention was never to let the GPU sleep so it was instantly available
09:56 ickle: but if you rather mean start at max if on ac
09:56 MrCooper: not necessarily, just don't leave it at 350 MHz until it misses the first refresh cycle
09:56 ickle: we don't
09:58 MrCooper: the numbers on https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1383 certainly suggest it stays too low too long
10:11 ickle: if you want to move the fdo issue to drm/intel, ask Daniel to update his kernel
10:33 MrCooper: to which version at least?
10:35 ickle: the change I'm thinking of was in April... which means that it's scheduled for 5.8 /o\
14:08 jekstrand: Woah, lots of new files in src/freedreno!
14:13 dj-death: yeah, crazy
14:33 robclark: airlied: I'll send it in couple minutes, after I get some caffeine in me..
14:59 jenatali: jekstrand: Whatever came of the changes you were looking at to just allow array indexing on vectors for all memory types?
15:00 jekstrand: jenatali: lots of CI failures. :-P
15:00 jekstrand: jenatali: I did make progress but there are a lot more NIR passes which need updating than I thought. :-/
15:02 jenatali: Got it
15:03 jenatali: Trying to figure out if we should take a short-term fix for CL stores on single vector components of shared/global memory
15:03 jenatali: (Something like https://gitlab.freedesktop.org/kusma/mesa/-/merge_requests/240 or which has the same effect)
15:05 jekstrand: jenatali: I think there is a short-ish term fix we can do.
15:07 jekstrand: jenatali: We have a nir_lower_array_deref_of_vec pass
15:08 jekstrand: jenatali: We could drop the vector handling from spirv_to_nir and simply call that for a bunch of variable modes in every driver that calls spirv_to_nir.c
15:08 jekstrand: jenatali: As long as the lowering happens before significant optimization, we should be fine.
15:08 jekstrand: jenatali: The way we're doing it in spirv_to_nir right now is kind-of rubbish.
15:09 jenatali: jekstrand: The thing is, lower_explicit_io array derefs of vecs just fine as well
15:09 jekstrand: Yeah, but there are a bunch of passes that only run on nir_var_shader_temp or nir_var_function_temp which very much don't support it.
15:09 jekstrand: Also, system values and inputs/outputs.
15:10 jenatali: Hm, yeah okay
15:10 jekstrand: I was hoping I could fix all the passes and I made some real progress but there's more work to do.
15:10 jenatali: Understood, thanks for the explanation
15:11 jekstrand: yw
15:12 zmike: jekstrand: I made you a present https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6116
15:12 jekstrand: In any case, I think the right medium-term thing to do is likely to call nir_lower_array_deref_of_vec for the stuff that can't handle it.
15:14 jenatali: Alright, thanks, let me play around with that
15:46 pendingchaos: cmarcelo: one of the commits in this MR is yours: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5980
15:46 pendingchaos: ok if I merge it?
16:03 MrCooper: alatiera: out of curiosity, what are the issues with your Raven Ridge laptop? This Thinkpad E595 with Picasso (newer Raven Ridge variant) has been working really well
16:04 alatiera: MrCooper its a lenovo ideapad and up till 5.4 or so kenrel it needed extra care in the kernel cli to fix its acpi table
16:05 alatiera: plus the amd touchpad driver seems to be included in ubuntu but not upstreamed
16:05 alatiera: battery life is about an hour
16:06 cmarcelo: pendingchaos: sure
16:08 alatiera: MrCooper the laptop had issues in windows as well, it looks like a generally bad QAed machine
16:08 MrCooper: alatiera: wow, hard to believe that's from the same vendor as mine
16:08 alatiera: ideapads are a whole other world I learned
16:08 alatiera: they don't really seem to care about them cause they are 'cheap'
16:09 alatiera: oh the usb controller also would randomly stop working after couple of hour
16:09 alatiera: hours*
16:09 alatiera: and it would need to be rebooted
16:09 MrCooper: the reviews I read about newer IdeaPads didn't sound too bad either, but maybe the reviewers just glossed over such issues
16:11 alatiera: most reviews probably didn't tried linux or tried ubuntu lts at best
16:11 alatiera: which is fair tbh
16:12 jekstrand: airlied: One more patch that needs a review if you want. :)
16:19 karolherbst: jekstrand: do you think it's "fine" if a gallium frontend copies the drivers nir_options and changes a few things around?
16:20 karolherbst: right now that's basically the only way I see the offset thing working with clover if we keep the lowering flags in nir_options
16:20 karolherbst: as this is really not driver, nor shader stage defined
16:20 jekstrand: karolherbst: That's probably ok if the front-end knows what it's doing.
16:20 jekstrand: karolherbst: Be warned that it might be per-stage or something
16:21 karolherbst: nope, not all kernels have offsets
16:21 karolherbst: in CL yes, but not in other compute APIs
16:21 karolherbst: level0 also has neither offsets nor big grid lowering
16:21 karolherbst: cuda doesn't have it either
16:21 jekstrand: VK has offsets
16:21 jekstrand: but not big grid lowering
16:22 karolherbst: right, but it's launching compute shaders, not kernels :)
16:22 karolherbst: GL compute doesn't have offsets
16:22 jekstrand: Sure
16:22 karolherbst: so.. it's really API defined
16:22 karolherbst: not shader stage or driver
16:22 jekstrand: Yeah, I guess so.
16:22 jekstrand: With Vulkan, that distinction is theoretical.
16:22 karolherbst: that's kind of the biggest issue I have with the current way of enabling the proper lowering :/
16:23 karolherbst: just doesn't feel right to have nir_options for that
16:23 karolherbst: or well.. runtimes just set the value regardless of what drivers did
16:23 karolherbst: that would work, but it's also not the cleanest solution
16:24 jekstrand: I don't think the state tracker overriding certain nir_options is bad.
16:24 karolherbst: yeah.. my current plan was to always enabling lowering in clover, but have a clover pass lowering them to kernel args.. but that requires the driver to set those options even though the driver wouldn't care at all :) but yeah...
16:24 karolherbst: if the runtime overwriting stuff is fine I guess we could go with that
16:25 karolherbst: I think this case is just special enough so we could accept this exception
16:25 jekstrand: karolherbst: The other option is that we can do what clover is doing for LLVM and just 100% hide it from drivers.
16:25 karolherbst: right, but right now it would require setting the nir_option still
16:25 jekstrand: Yeah, I think you should just copy the struct and whack the field.
16:26 jekstrand: It should be safe to do that
16:26 karolherbst: I already call nir_lower_system_values inside clover anyway
16:26 karolherbst: or... wait
16:26 jekstrand: We may regret it later when debugging some weird fail.
16:26 karolherbst: maybe we want to have nir_lower_system_values taking options?
16:26 karolherbst: that would be kind of more clean
16:26 jekstrand: Yeah, that might be a better idea TBH
16:26 jekstrand: We've stuffed a LOT of stuff in nir_options
16:27 jekstrand: too much stuff, IMO.
16:27 karolherbst: yeah.. I kind of like the idea :D
16:27 karolherbst: will leave a note on the MR
16:27 jekstrand: If we want to do that, though, it'll mean some amount of duplication.
16:27 jekstrand: Not that that's strictly speaking a bad thing.
16:28 karolherbst: I mean.. it could be a simple boolean parameter for now
16:28 karolherbst: or what duplications are you refering to?
16:28 jekstrand: If we're going to go that way, I'd rather move all of the options that nir_lower_system_values currently respects.
16:28 karolherbst: I see
16:28 jekstrand: Let's not do half-and-half between parameters and nir_options.
16:29 karolherbst: right
16:29 jekstrand: It's not called that many places.
16:29 jekstrand: And I think for gallium, they're probably all caps anyway
16:29 karolherbst: although I'd argue some thinks should stay in nir_options? like the vertex_id stuff? I thought that's quite driver specific
16:30 jekstrand: I think trying to split things driver vs. API is foolish.
16:31 karolherbst: but then gallium needs to ask drivers of what they need.. not a problem, just.. would also mean adding more CAPS etc...
16:31 jekstrand: I suspect all the caps already exist
16:31 jekstrand: Because we had then for GLSL
16:31 karolherbst: yeah.. could be
16:31 karolherbst: in which case it's more of a cleanup
16:31 jekstrand: And, if they don't, the driver can call nir_lower_system_values again with more bits set.
16:31 karolherbst: true
16:32 karolherbst: yeah.. okay
16:32 karolherbst: I think that sounds good
16:32 karolherbst: I guess I start with it and see how that goes
16:34 jekstrand: karolherbst: For instance, PIPE_CAP_VERTEXID_NOBASE
16:34 karolherbst: yep
16:35 jekstrand: I'm not seeing one for whether your HW natively has gl_LocalInvocationID or gl_LocalInvocationIndex
16:35 karolherbst: maybe all drivers set the same anyway
16:35 karolherbst: in which case...
16:36 karolherbst: well, I'll check them one by one anyway
16:36 jekstrand: Yeah
16:36 jekstrand: I don't think drivers having to call nir_lower_system_values again in their back-end is a bad thing.
16:36 jekstrand: We already do
16:36 karolherbst: I see
16:36 karolherbst: why though?
16:37 jekstrand: History, mostly.
16:37 jekstrand: We were using NIR long before gallium so our stack is built to require very little outside of brw_nir.c to go from GLSL -> bits.
16:37 jekstrand: And we never bothered to remove any of it.
16:38 karolherbst: ahh, I see
16:38 jekstrand: Which is advantageous because we'd have to duplicate it all in i965 and anv. It's easier to just have some redundancy in iris.
16:39 jekstrand: I don't know if robclark, anholt, or any of the other gallium users have a contrary opinion.
16:44 robclark: jekstrand: one advantage of everything in the nir options struct is it has saved us from adding a lot of new gallium pipe caps ;-)
16:44 jekstrand: robclark: Yeah.....
16:44 jekstrand: robclark: Or you can just call nir_lower_system_values again. :-P
16:45 robclark: yeah, I suppose we could just call it in ir3 (and drop the call in tu)
16:46 jekstrand: robclark: Yeah, that's the other thing. If you have a vk driver, it's not really adding a call, just moving it.
16:46 karolherbst: what gallium directory is accessible from st/mesa and gallium/auxillary?
16:46 karolherbst: and has st_context stuff?
16:47 zmike: gallium/include?
16:47 karolherbst: I kind of don't want to duplicate the code creating the option struct :)
16:48 karolherbst: mhh..I guess being it a static inline is good enough actually
16:48 karolherbst: zmike: yeah, good idea actually. Thanks
16:48 zmike: 👍
16:49 karolherbst: ohh wait
16:49 karolherbst: it also needs to include nir/nir.h :)
16:49 karolherbst: which we don't in gallium/include
16:50 jekstrand: karolherbst: What are you doing?
16:50 jekstrand: What struct are you creating?
16:50 karolherbst: jekstrand: options for system_values lowering?
16:51 jekstrand: Why does that need to go in a header?
16:52 karolherbst: well.. we call the lowering pass like 4 times in gallium and I thought I want to have a common place generating the struct
16:52 jekstrand: I suspect you're making this far more complicated than it needs to be.
16:52 karolherbst: instead of.. having places checking the CAPS and stuff
16:52 karolherbst: *multiple
16:52 jekstrand: uh... What?
16:52 jekstrand: Why is it called 3 places?
16:52 jekstrand: *sigh*
16:52 karolherbst: :)
16:53 jekstrand: I suppose 4 if you count clover
16:53 karolherbst: 5 if you count ttn
16:53 jekstrand:grumbles
16:56 karolherbst: yeah...
16:56 karolherbst: so I kind of like to have a function somewhere doing it once :)
16:56 jekstrand: Yeah
16:56 karolherbst: st_nir_lower_system_values maybe?
16:57 karolherbst: and then call that instead or something
16:57 jekstrand: That's kind-of what I'm thinking
16:57 kisak: pendingchaos: maybe the InvalidAccessKeyId snafu in https://gitlab.freedesktop.org/pendingchaos/mesa/-/jobs/3858336 is an unexpected side effect from https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5903 ? seems like something for the CI folks to ponder.
16:57 jekstrand: Wouldn't necessarily solve your clover problems but I'm inclined to not care.
16:58 karolherbst: yeah.. clover wants it's own bits set anyway I guess
16:58 karolherbst: but yeah.. mhh
16:58 jekstrand: Yeah
16:58 jekstrand: It doesn't care about vertex id
16:58 karolherbst: right
16:58 karolherbst: yeah.. I think that would be fine
16:58 jekstrand: And I'm happy for us to leave invocation_id/index alone and let the back-end call it again if it wants.
17:00 kisak: tomeu / anholt: can you take a peek at the linked CI job?
17:08 karolherbst: mhhh.. ttn can't call into st/mesa :/
17:08 jekstrand: 😭
17:11 karolherbst: I have an idea.. but it's not as nice as I hoped it to be
17:26 jenatali: karolherbst: Sounds like you're doing my work for me? :D
17:29 karolherbst: I am also not quite sure what mess I talked me into.. :https://gitlab.freedesktop.org/karolherbst/mesa/-/commit/da1d3c6840951cffb48570afa0304862b4b41988
17:29 karolherbst: and I didn't even start moving options around
17:30 jenatali: Yeah... that's what I was afraid of when I saw your suggestion
17:30 karolherbst: :p
17:30 jenatali: It still sounds like the right approach though
17:30 karolherbst: yeah
17:33 jekstrand: pipe_nir!
17:33 karolherbst: yeah.. okay :p
17:34 zmike: enum pipe_nir_caps
17:34 karolherbst: ....
17:34 karolherbst: I don't like where this is going :D
17:35 karolherbst: I hoped this rework to be under 1k of line changes not more :p
17:37 jekstrand: karolherbst: I think it's going towards "gallium will lower it to NIR intrinsics. Drivers are on their own from there on."
17:37 jekstrand: Except for maybe vertex ID but only because there's already a gallium CAP for it
17:38 jekstrand:assigns his giant MR to marge. You all have until CI finishes to tell me to stop. :-)
17:39 jekstrand: With my rate of success lately, that may not be until next week. :-(
17:55 towo`: hi, anyone here knows, if mesa git master should compile with clang (version 10) instead of gcc? i tryed it often and the build allways fail
17:56 jekstrand: It should
17:56 jekstrand: What error are you getting?
17:57 towo`: https://paste.debian.net/1158210/
17:57 towo`: i can paste the complete buildlog too, if it would help, where i maybe do anything wrong
17:59 robclark: android and CrOS builds of mesa use clang.. and we even have a meson-clang CI job
18:00 jekstrand: That seems very odd. Is it a clean build?
18:01 towo`: https://pb.5id.eu/Rxpd that's the whole buildlog
18:03 karolherbst: towo`: looks like fs corruption
18:03 karolherbst: mind just removing src/gallium/winsys/amdgpu/drm/libamdgpuwinsys.a and recompile?
18:04 towo`: it's not that easy, it's a pbuilder chroot
18:05 karolherbst: towo`: well.. the .a file seems to be corrupt or something, so really nothing else I can suggest here
18:05 karolherbst: ahh, you also use ccache
18:05 karolherbst: I blame ccache :p
18:06 karolherbst:also suggest to never use ccache for compiling distribtuion binaries, but hey...
18:07 karolherbst: towo`: don't use ccache then? or clear the ccache cache?
18:07 karolherbst: (or spend enough time to reproduce with ccache and file a bug against ccache)
18:08 towo`: i will try again, without ccache
18:38 Kayden: on a hard system lockup, ext4 will sometimes truncate files in your ccache to 0 bytes, at which point nothing works, because it's sucessfully giving you back a corrupt thing out of the cache
18:38 Kayden: ccache -C to clear it generally fixes it, as does going and just removing the 0 byte files in ~/.ccache
18:40 airlied: CCACHE_RECACHE=true for one run
18:42 airlied: jekstrand: looks like you landed it, nice
18:42 airlied:goes to rebase land
18:42 zmike:also goes to rebase land
18:42 jekstrand: airlied: Yeah, It's in.
18:43 jekstrand: airlied: I'm also in rebase land
18:43 Sachiel:stuck in fuckthisshit land
18:43 zmike: Sachiel: https://i.imgur.com/EUhql7P.gifv
19:02 towo`: karolherbst, even without ccache i get /usr/bin/ld: src/gallium/winsys/amdgpu/drm/libamdgpuwinsys.a: error adding symbols: file format not recognized
19:03 bnieuwenhuizen: Kayden: one reason I have a 'sync' at the end of my build scripts. Make sure your data is on disk before you run the app that is going to crash your system
19:04 towo`: and btw, the build runs fine with gcc-10
19:10 Kayden: bnieuwenhuizen: yeah :)
19:10 karolherbst: towo`: very strange
19:11 karolherbst: towo`: so either the static linker is broken or something else is odd
19:13 karolherbst: in any case, I don't see any reason why any of that is mesas fault, so we can't really help except give general advise
19:14 dcbaker[m]: towo`: does it work without lto?
19:28 towo`: dcbaker[m], how do i disable lto?
19:39 towo`: hm, now i have tryed to use lld as linker, then i get an earlyer error: ld.lld: error: TLS attribute mismatch: _glapi_tls_Dispatch
19:41 towo`: maybe i should test, if llvm/clang version 9 is doing right
19:46 dcbaker[m]: Meson has a -Db_lto=false argument, unless it's being injected from env variables
19:46 dcbaker[m]: towo`: ^
19:46 karolherbst: towo`: ahh, so it could be indeed a mesa bug...
19:46 karolherbst: well and binutils
19:46 karolherbst: but yeah..
19:46 karolherbst: at least this is a proper lead
19:52 karolherbst: jenatali, jekstrand: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6119
19:53 karolherbst: it wasn't that much surprisingly
19:54 karolherbst: robclark: with that you could merge your nir_option structs I think
19:55 karolherbst: only unroll_iterations and lower_to_scalar are fields only set in a6xx I think
19:55 karolherbst: might be worth a look
19:55 jekstrand: karolherbst: Yeah, doesn't look terrible.
19:56 karolherbst: ohhh.. I should fix tu_shader.c :)
19:56 karolherbst: totally forgot about that
20:19 towo`: dcbaker[m], without lto the build has worked
20:20 karolherbst: let's see what CI says :)
20:20 dcbaker[m]: That doesn't surprise me, in fact I seem to remember the TLS thing is specifically related to lto going wrong
20:20 towo`: used ld instead of lld, since lld seems not to work, see above
20:21 dcbaker[m]: ld.bfd has a tendency to work when it shouldn't, and ld.lld tends to be better about throwing an error, in my experience
20:22 dcbaker[m]: gcc + ld.bfd compiles fine, but you may get some odd errors running it
20:25 towo`: dcbaker[m], do you think i shouöd try to build with lld again and now without lto?
20:25 towo`: s/ö/l
20:25 dcbaker[m]: I think it will work with lld and no lto
20:27 karolherbst: ehhh...
20:27 karolherbst: why do I never compile with tools?
20:27 Sachiel: because compiling manually seems like too much effort
20:28 karolherbst: ....
20:30 karolherbst: do you think somebody will dislike me for doing this: NIR_PASS_V(nir, nir_lower_system_values, &(nir_lower_system_values_options){}); ?
20:30 jenatali: karolherbst: Yes :)
20:30 karolherbst: because MSVC doesn't accept it or why? :p
20:31 jenatali: Heh no I think it does. Though I think it's non-standard code?
20:31 karolherbst: I honestly don't know :D
20:31 jenatali: Address of a temporary
20:31 karolherbst: yeah...
20:31 karolherbst: but I think we do it a few times inside mesa
20:33 karolherbst: ahh.. I broke a5xx and a6xx.. well
20:35 karolherbst: ohhhh.. crap
20:35 karolherbst: jekstrand: we can't call lower_system_values multiple times :/
20:36 karolherbst: or rather... the first call has to be correct, otherwise bad things will happen
20:36 jenatali: Like what?
20:36 jekstrand: karolherbst: Uh, wha?
20:36 karolherbst: eg check handling of nir_intrinsic_load_vertex_id
20:36 karolherbst: so either you are zero based or that thing just vanishes
20:37 jekstrand: ?
20:37 jekstrand: What do you mean "vanishes"?
20:37 karolherbst: so if you cal with zero_based = false the first time, it doesn't matter what you have set the second time the pass runs
20:37 jenatali: Yeah, first runs need to be more conservative than second runs
20:37 karolherbst: or.. maybe I missunderstand the code?
20:37 jenatali: Either not touch things, or lower them to stuff that can be lowered further later on
20:37 jekstrand: karolherbst: It's got lowering in there to turn vertex_id into vertex_id_zero_base + first_vertex
20:38 jenatali: I was thinking through the implications that'd have on the lower_cs_global_id_from_local flag we wanted to add as part of !5891
20:38 jekstrand: karolherbst: Once you've done that lowering, there's no going back though.
20:38 karolherbst: ohh wait.. returning NULL is safe, right?
20:39 karolherbst: yeah okay.. then it should be fine
20:39 jekstrand: karolherbst: Yup, that just means "leave it alone"
20:40 karolherbst: mhhh.. then I don't see why I broke with freedreno :/
20:41 karolherbst: ohhh.. I see it now
21:04 karolherbst: nice.. it passes :)
21:05 jenatali: :)
21:29 jekstrand: karolherbst: \o/
21:29 jekstrand: karolherbst: Did you run it through Intel CI?
21:31 karolherbst: jekstrand: yeah, still waiting for results though
21:31 jekstrand: cool
22:22 karolherbst: jenatali, jekstrand: checking out the ampere ISA disassembler doc and I found this goodie: "LDGSTS Asynchronous Global to Shared Memcopy"
22:22 karolherbst: I think you'll love it
22:22 jenatali: Sounds like CL's async copy functions
22:23 karolherbst: yep
22:24 jenatali: Which means we'll probably want some config passed to vtn to provide alternate lowering for functions that have libclc implementations
22:24 karolherbst: yep...
22:25 jenatali: Awesome :P
22:26 jekstrand: For all I know we have a memcpy message somewhere too.
22:26 jekstrand: It's not a thing I've ever thought to look for.
22:28 jenatali: My gut says it'd make sense to add those as optimizations after !6035 (or !4323, but I personally think !6035's mangler is cleaner) is merged
22:29 jenatali: As-is, they're just broken, where after that, at least they work :)
22:30 jekstrand: What's the behavior of those w.r.t waves? Can we at least vectorize internally or something?
22:31 jenatali: The async copy routines?
22:31 jekstrand: yeah
22:31 jenatali: https://github.com/llvm/llvm-project/blob/master/libclc/generic/lib/async/async_work_group_strided_copy.inc#L2
22:31 jenatali: Each thread reads/writes its own independent data
22:32 jekstrand: k
22:32 jekstrand: then I don't see much of a point
22:34 jenatali: A point in the function being in the language, or a point trying to optimize it?
22:34 jekstrand: both?
22:34 jenatali: :)
22:36 bl4ckb0ne: dcbaker[m]: do I need to keep wl_shell for waffle?
23:11 dcbaker[m]: I'm not the right person for that question. Probably pq or daniels would know?
23:16 bl4ckb0ne: iirc wl_shell is in the process of being deprecated but still some compositor still support it and others dont
23:16 bl4ckb0ne: main reason I'm doing this is because sway doesnt
23:16 jekstrand: Does waffle support the new thing?
23:16 bl4ckb0ne: working on it ;)
23:16 bl4ckb0ne: i saw a todo in the current MR saying something about keeping wl_shell but i want to be sure
23:17 jekstrand: I see no reason why we need to keep wl_shell
23:17 jekstrand: chadv may have a different opinion
23:17 bl4ckb0ne: im fine with both and removing wl_shell later if that's the best for everybody
23:29 daniels: bl4ckb0ne: which compositors don't support it? I don't know of any, I would remove it
23:32 bl4ckb0ne: i was talking about wl_shell
23:32 bl4ckb0ne: so its a go to remove it?
23:32 jekstrand: If daniels says it is, I'd believe him. :)
23:33 bl4ckb0ne: neat
23:35 HdkR: karolherbst: If you look at the Ampere whitepaper, that is how the "Asynchronous Copy" section of that whitepaper works