01:24 rhyskidd: karolherbst: some ARM devices do support PXE boot via u-boot or their binary bootloader (e.g. tegra-based Jetson and later rpi's)
01:25 rhyskidd: rock64 / pine64's as well
01:27 rhyskidd: i doubt those platforms, except for the tegra's, would be off your ci priority list
01:27 rhyskidd: s/off/on/g
05:06 mixfix41: MJNN
07:22 pmoreau: karolherbst: Re “doesn't tesla support scaling the grid on the z axis?” , what kind of scaling are we talking about? IIRC Tesla supports 3-D grids.
10:31 karolherbst: pmoreau: 3d grids yes, but you can't scale them 3d
10:31 karolherbst: only 2d
10:31 karolherbst: at least that's what nv50 exposes via caps
10:31 karolherbst: pmoreau: PIPE_COMPUTE_CAP_GRID_DIMENSION is 2, not 3
10:32 karolherbst: ohh wait
10:32 karolherbst: in gallium it's block vs grid
10:32 karolherbst: so 3d blocks, but only 2d grids
10:48 pmoreau: 👀 This seems weird
10:48 karolherbst: pmoreau: yeah.. could be :p
10:49 pmoreau: Oh, it looks like it actually is like that. 😲
10:49 karolherbst: pmoreau: right.. so we kind of need this enqueue lowering already :/
10:49 pmoreau: Yeah… :-/
10:49 karolherbst: grid: {512, 1, 2} would fail, no?
10:50 pmoreau: Let’s see…
10:51 karolherbst: {32, 16, 2} might be a more "reasonable" request, which should also fail
10:54 pmoreau: So I tried modifying a simple example that was using {1, 1, 1} to instead start a {32, 16, 2} grid, and nothing is complaining about it.
10:57 pmoreau: So, `PIPE_COMPUTE_CAP_GRID_DIMENSION` is actually never used.
10:57 karolherbst: pmoreau: the question is rather if the runtime works
10:57 karolherbst: I expect it to just silently fail
10:57 karolherbst: pmoreau: see that grid[2] is never accessed in vn50?
10:58 karolherbst: so... I see two things which need to be done
10:58 pmoreau: Indeed
10:59 karolherbst: 1. make clover fail and check the requested grid is invalid for the device
10:59 karolherbst: 2. make use of the offset lowering :D
10:59 karolherbst: pmoreau: https://gitlab.freedesktop.org/karolherbst/mesa/-/commits/cl_wip/
10:59 robi: just sent a patch to the nouveau mailing list, can a developer please review it when they have time? :)
10:59 karolherbst: pmoreau: I didn't wire up lowering of too big grids though
11:00 karolherbst: but I expect that's easier to test on nv50 than on gp107 :D
11:01 karolherbst: pmoreau: I think I'd need to launch {32, 16, 131070} or something to even hit this...
11:01 pmoreau: Probably, yes 😄
11:01 karolherbst: pmoreau: might pulling that branch and run some CTS tests?
11:01 pmoreau: Sure
11:01 karolherbst: test_basic get_global_offset and global_work_offsets
11:01 karolherbst: if all pass, then.. well
11:01 karolherbst: you need to write your own test :p
11:02 pmoreau: :-D
11:02 karolherbst: but uhm...
11:02 karolherbst: they won't pass
11:02 karolherbst: you need https://gitlab.freedesktop.org/karolherbst/mesa/-/commit/1c28c2e7f9a91472f415c4b802bc27b28a27d3c1 for nv50
11:02 karolherbst: there are some nvc0 changes
11:03 karolherbst: but this is just to support the "offset" argument :/
11:03 pmoreau: Mmh
11:03 karolherbst: I don't know if there are test which really test executing bigger grids
11:04 karolherbst: but at least supporting offsets generally is required anyway
11:04 pmoreau: I don’t remember if Tesla supports offsets
11:09 karolherbst: pmoreau: how does any of this look like it's native support? :p
11:09 pmoreau: None
11:10 karolherbst: but apparently there is a feature to interrupt grids and resume them...
11:10 karolherbst: but didn't figure out what that was all about
11:11 karolherbst: anyway.. lowering of big grids needs the other lowering as well
11:11 karolherbst: has_cs_work_group_offsets = true
11:11 karolherbst: and we need to inject a grid id offset :/
11:11 karolherbst: it's super annoying
11:16 pmoreau: Going to look first into why recent 5.8.0 RCs are failing to load on my laptop, and then give a try to your barrier MR.
11:17 karolherbst: :D cool, thanks
11:17 karolherbst: but I think I will do some changes to that mr...
11:17 karolherbst: I am not happy about the loop handling
11:18 karolherbst: pmoreau: uhm.. more important right now: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6064
11:18 karolherbst: mind checking if this breaks for you?
11:18 karolherbst: my earlier attempt messed up as other args could be overwritten by the driver
11:18 karolherbst: well.. for clover :D
11:19 pmoreau: Ah the handlers one, okay.
11:20 karolherbst: yeah.. it's messy
11:20 karolherbst: I am open to better suggestions
11:29 pmoreau: Nice, rc7 is working fine again here!
11:32 karolherbst: :)
11:55 karolherbst: pmoreau: btw, I try to review your new spir-v MR.. at least I move it into the list of thinks I really plan to do over the next few days :p
12:02 pmoreau: This one, https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5038?
12:04 pmoreau: And thanks! Would be great to get it in, since it does not contain too much but has some nice improvements still.
12:08 karolherbst: yeah, that one
13:52 pmoreau: karolherbst: I do not see any changes with your 64-bits-handle series; I tried a mix of the CTS and my own local tests. Any particular kind of tests I should run?
13:53 karolherbst: pmoreau: alternating ptrs and int args
13:53 pmoreau: Okay
13:53 karolherbst: soo.. the issue was that with a trivial change of the type, drivers would get an int64_t ptr into the kernel input
13:54 karolherbst: and if the device only does 32 bit ptrs and clover allocates like that, drivers would end up overwriting other parts of the input
13:54 karolherbst: I merged a patch like this once, and noticed this a few seconds later that it will break like that :)
13:54 karolherbst: so I reverted it at that time
13:55 pmoreau: Oopsies!
13:55 karolherbst: yeah...
13:55 karolherbst: also explains why this MR is so.. complicated :p
14:30 imirkin: skeggsb: can you glance at https://bugzilla.kernel.org/show_bug.cgi?id=208661#c6 when you get a chance, and perhaps suggest a way forward?
14:30 imirkin: skeggsb: this is the issue we were debugging with robi, if you have the scrollback
15:08 robi: imirkin: about that bug. i made a patch
15:08 robi: i tested it with 5.7.6 and it seems to work great
15:08 robi: it's a config option that unconditionally executes a gpio reset
15:08 robi: i'll attach it to the bug
15:09 robi: i also sent it to the nouveau ML but it's held for moderation
15:10 robi: imirkin: https://bugzilla.kernel.org/attachment.cgi?id=290619
15:13 karolherbst: imirkin: I guess when nv_backlight works, then acpi_backlight works as well?
15:14 imirkin: karolherbst: not sure, but that's not important imo
15:14 karolherbst: right.. but I'd assume that the AML code just pokes into the same registers and has a backlight driver implementation :)
15:14 robi: karolherbst: nope
15:14 robi: nv_backlight works, acpi_video0 doesn't
15:15 karolherbst: interesting
15:15 robi: acpi_video0 also takes a lot longer to execute with nouveau than nvidia suggesting an acpi timeout of sorts
15:15 karolherbst: yeah...
15:15 karolherbst: I guess there is some additional stuff
15:15 robi: my acpi tables are probably super weird
15:15 karolherbst: probably not :p
15:16 karolherbst: it could be that it just sends a signal to the driver and waits for it to respond :p could be something stupid like that
15:16 karolherbst: would be interesting to know _where_ it loops and what it reads/writes in that area
15:16 robi: the only thing that sucks is that i can't control brightness via the keyboard but it seems to emit Xf86BrightnessUp/Down so i can just hook it to i3wm
15:16 karolherbst: mhhh
15:16 karolherbst: userspace usually selects a driver
15:17 karolherbst: and normally the correct one should be used by default..
15:17 karolherbst: but essentially all should work
15:17 karolherbst: so yeah.. if "out of the box" is broken it should be fixed :)
15:18 karolherbst: and should not require workarounds to be applied by the user
15:19 karolherbst: so yes, _if_ acpi_backlight is choosen and doesn't work it is a bug and needs to be fixed, either in userspace or in the kernel
15:19 karolherbst: but more likely in the kernel as they all should work or should not get exposed
15:20 imirkin: robi: if you boot with acpi_backlight=vendor i'm guessing it should work
15:21 robi: that just removes acpi_video0 though
15:21 robi: i'm pretty sure the backlight buttons on this computer are driven by acpi directly
15:21 imirkin: robi: the key press thing is the "new" (i.e. acpi) way of doing it
15:21 robi: at least that's what i could tell from the IASL decompilation
15:21 robi: idk what that means sorry ^^;
15:21 imirkin: the "old" way is that the buttons triggered logic which directly affected the brightness
15:22 imirkin: but now it's round-tripped via userspace
15:22 karolherbst: imirkin: and still, none of that matters
15:22 imirkin: not at all
15:22 karolherbst: it needs to be fixed
15:22 imirkin: i'm just explaining why it works like that.
15:22 imirkin: i.e. why the buttons don't directly control brightness
15:22 karolherbst: when did the buttons even tirgger kernel logic directly?
15:23 imirkin: if you boot with acpi_osi setting of WinXP (whatever it's actually called), the buttons will probably control the backlight directly
15:23 imirkin: kernel logic? never
15:23 karolherbst: ahh.. EC fun
15:23 karolherbst: I see
15:23 imirkin: but they might just directly control the backlight.
15:23 imirkin: as they did in the olden times
15:23 karolherbst: but then you get back to the AML code
15:23 imirkin: yes
15:23 karolherbst: probably
15:23 karolherbst: so it would be broken anyway :)
15:23 imirkin: i'm just explaining why you get a keypress now
15:23 imirkin: yes
15:23 karolherbst: k
15:23 imirkin: so now those buttons are like any other button
15:24 imirkin: and it's up to the system to determine what to do with it
15:24 karolherbst: right... so there are two bugs
15:24 imirkin: if acpi_video doesn't work, then acpi_backlight=vendor is definitely a good thing to use
15:24 karolherbst: 1. we don't init something 2. we don't meet ACPI/AML expectations
15:24 imirkin: since you don't want broken providers running around
15:25 karolherbst: imirkin: it is, but still an user applied workaround and we want stuff to work out of the box
15:25 karolherbst: so it's not a solution
15:25 imirkin: it's not ideal, no
15:25 imirkin: but i'm a whole lot less inclined to determine why some acpi method doesn't seem to work :)
15:26 karolherbst: we probably need to do some funky _DSM call or something :/
15:26 karolherbst: who knows...
15:26 karolherbst: maybe some of the ACPI devs know what to do
15:27 karolherbst: anyway.. I'd do it like that: fix nv_backlight first, then open a new bug against ACPI
15:27 karolherbst: and either we take a look and figure it out or some ACPI devs
15:27 robi: so my config option patch is a no go?
15:28 karolherbst: robi: well.. it's also more of a workaround
15:28 karolherbst: the nvidia driver doesn't need anything for the user to do :)
15:28 robi: indeed
15:28 karolherbst: with nouveau it should be the same
15:30 robi: how much of a performance hit would it be to unconditionally reset the GPIO tables?
15:30 robi: the problem is that it doesn't seem like anyone else has my exact problem
15:31 imirkin: zero
15:31 robi: hm
15:31 imirkin: the concern might be that it'll screw something up
15:31 imirkin: dunno
15:31 robi: yeah, that's why i'm for putting it under a config flag: too rare to be useful for most people
15:32 robi: then again the same argument could be made for me to keep patching my own kernel ;)
15:36 robi: i haven't gotten around to bisecting whatever broke drm-next
15:37 imirkin: well
15:37 imirkin: other people may just suck it up
15:37 imirkin: or use blob driver as a result
15:37 imirkin: not a lot of people are willing to do the level of investigation that you've done
15:38 imirkin: most give up if it doesn't work within 30 seconds
15:42 robi: fair enough
15:42 robi: i'm willing to make it an unconditional GPIO reset if that's what's needed
15:42 robi: i'm just worried about possible breakage :/ but if nvidia _always_ does it then it's ok?
15:46 imirkin: this is why i'd like skeggsb's feedback :)
15:48 karolherbst: robi: try to make nvidia not do it :p
15:49 karolherbst: potentially there can be some vbios table bits for it
15:49 karolherbst: who knows...
15:49 karolherbst: btw.. did you look into the docs?
15:49 karolherbst: maybe there is soemthing
15:51 robi: nope i'm not a nouveau dev :D
15:51 robi: the patch was mostly guesswork and looking at similar code
15:53 imirkin: i think karol meant the dcb docs that nvidia published
15:53 imirkin: https://nvidia.github.io/open-gpu-doc/DCB/DCB-4.x-Specification.html
15:53 imirkin: but that table just describes the data
15:54 imirkin: not what the driver is expected to do with it
16:01 robi: ah well, waiting for feedback from maintainers for now then
16:10 RSpliet: robi: RE "guesswork and looking at similar code" - that's how we all do it here. Congrats, you're a dev now ;-)
16:10 robi: ahahaha
16:10 robi: i'm honored
16:10 imirkin: it's a low bar.
16:12 imirkin: not a lot of applicants.
16:21 Zero_Dogg: Is there any way, with a 5.6 kernel, to get sound working (ie. working around https://bugzilla.kernel.org/show_bug.cgi?id=207223) ?
16:22 Zero_Dogg: I'm on a Debian stable system, there's a 5.6 backport which solves some other bugs with nouveau that I'm having with the default kernel (4.19), but using that kernel breaks sound-over-hdmi
16:25 imirkin: can you build your own kernels?
16:25 imirkin: and which GPU do you have?
16:26 imirkin: v5.6 got the hd audio notifier support, but it had some issues
16:27 imirkin: there are some fixes in v5.8 for it
16:31 Zero_Dogg: I'll try the kernel from testing
16:34 robi: yeah more info would probably be useful
16:35 Zero_Dogg: everything works with 5.7.6 from testing
16:38 imirkin: hm, that's a bit odd
16:38 imirkin: that stuff must have gotten backported
16:39 imirkin: oh
16:39 imirkin: it has this guy:
16:39 imirkin: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v5.7.10&id=ef8dcc48c6328217f327dbe03c24f06a73c63909
16:39 imirkin: which isn't a *complete* fix for the problem
16:40 imirkin: but does cover the vast majority of cases that worked before
16:40 imirkin: v5.8 includes a more complete fix which should fix audio in setups that weren't previously working i guess
16:41 imirkin: Zero_Dogg: so yeah. if you want v5.6 to work, include the above patch.
16:42 Zero_Dogg: compiling my own kernel is out of the question, it's my grandmothers laptop, I need it to be low maint :)
16:42 imirkin: looks like v5.6 stopped getting additional releases about a week before that patch was applied to the v5.7 stable series
16:43 Zero_Dogg: but with 5.7.6 and some pinning to testing, she's got sound on her tv when she plugs in HDMI, and sound on the laptop when she doesn't, so she's happy
16:45 imirkin: neat
16:46 Zero_Dogg: aye, I'm pretty happy with it. Thanks for your work and the help :)
21:02 karolherbst: RSpliet: btw.. I figured out why our sync/join stack pushing stuff is broken
21:02 karolherbst: prebreak and break push sync points as well
21:02 RSpliet: break too? I'd expect prebreak to do so...
21:02 karolherbst: ehh.. I mean break consumes those
21:02 karolherbst: or something
21:03 karolherbst: I am not 100% on how that really works, but something there is funky
21:03 RSpliet: yep
21:03 karolherbst: RSpliet: with volta everything is super simple
21:03 karolherbst: no stack, you do it yourself :p
21:03 karolherbst: but.. we insert joinats and joins only for ifs
21:03 karolherbst: and with volta we also have to for loops
21:04 karolherbst: so... I am wondering
21:04 karolherbst: maybe we forget something after loops if they implicitly end without breaking?
21:04 karolherbst: maybe we _always_ have to break?
21:05 karolherbst: we still have the bug to fix were we run out of stack
21:05 karolherbst: and we have this arbitrary limit of only going 6 deep into pushing joins and shit...
21:05 karolherbst: or something
21:06 karolherbst: but I kind of feel like understanding enough to take a deeper look and figure out what's wrong
21:27 RSpliet: yeah you will have to break out of a loop always. Or... that stack entry needs to be popped somehow
21:27 RSpliet: problem is: I understand this concept of a control stack well enough, but not necessarily NVIDIA's implementation details
21:29 karolherbst: RSpliet: latch closed loops though
21:29 karolherbst: and then you could do a predicated bra
21:29 karolherbst: and I assume this _could_ happen
21:29 karolherbst: but not quite sure
21:30 RSpliet: I don't know what a "latch closed loop" is
21:34 karolherbst: uhm.. I mean if the loop ends with an if cont else break, thing
21:40 RSpliet: Continue is just a jump right?
21:45 karolherbst: mhhh
21:45 karolherbst: well
21:45 karolherbst: there are special instructions
21:45 karolherbst: you also push the target via precont
21:45 karolherbst: it's all very annoying
21:49 RSpliet: Eh... that sounds like a faff indeed, because the order of stack entries starts to matter...
21:49 karolherbst: yeah...
23:27 AndrewR: hi all. I compiled https://gitlab.freedesktop.org/pmoreau/mesa/-/commits/nv50_compute_support/ and now vdpau output of mplayer all green :} (and old-ish luxcorerenderer fails with assertion too). On nv92 ...
23:29 AndrewR: just for laughs console log: https://pastebin.com/0ds2GjJn (/me reading channel log)
23:38 imirkin: wow, a glsl error?
23:38 imirkin: impressive.
23:39 imirkin: i guess the CL folk might be interested in that
23:39 imirkin: i'm surprised enabling compute causes vdpau output changes - that's behind a different cap now...
23:40 imirkin: AndrewR: i wonder if it's because NIR is now exposed
23:41 imirkin: AndrewR: https://gitlab.freedesktop.org/pmoreau/mesa/-/commit/0e5a70896c9c93b7c7df9813b7f0190ab026767b#58270466d6505350819adbd41626de2b31522f7e_455_455
23:41 imirkin: change that to only add the 1 << IR_NIR thing in the if (cl) case
23:41 imirkin: or i guess it won't matter, since PREFERRED_IR would still be tgsi
23:41 imirkin: nevermind
23:46 AndrewR: imirkin, may be I should also launch with nv50_nir debug env. variable set ....
23:48 AndrewR: imirkin, no, same error :} with NV50_PROG_USE_NIR=1
23:49 imirkin: well, pmoreau does make changes to common code
23:49 imirkin: so probably something there gets messed up