00:00jenatali: Er, largest alignment
00:04jenatali: airlied: You should add to your test a case where you throw extra args at the printf, that the format string doesn't reference
00:05airlied: the only problem with test cases in piglit framework is I can't verify the output of printf
00:06airlied: I'd have to add support to capture stdout I suppose
00:06jenatali: Alternatively you could implement https://www.khronos.org/registry/OpenCL/extensions/arm/cl_arm_printf.txt
00:07jenatali: Same thing but sends it to a callback
00:07airlied: that just seems like a trap :-P
00:07jenatali: :P
00:24jenatali: Ugh... restrict is awful
00:34airlied: jenatali: undef LLVM_ATTRIBUTE_RETURNS_NOALIAS :-P
00:35airlied: or something horrible where you don't define restrict if that is defined
00:35jenatali: I can work around it by re-ordering includes to put Allocator.h before the c99 compat header
00:35jenatali: That doesn't seem *too* horrible/hacky
00:36airlied: uggh we also explode on printf("\n"): :-P
00:36jenatali: :O
00:36jenatali: How?
00:39airlied: jenatali: vars to explicit chokes on the struct
00:39jenatali: Ohh, empty struct
00:39airlied: likely best to just not creat a struct
00:40jenatali: airlied: Maybe... maybe we don't do it in two steps? Maybe vtn just goes straight to global writes?
00:40jenatali: That seems... simpler
00:43jenatali: karolherbst: Clover's not C++14, is it?
00:44airlied: jenatali: yeah I was wondering about how why we have the second stage, it was likely so we could be flexible
00:44airlied: but I'm not sure I really care
00:45jenatali: Yeah, it made sense when we were first talking about it, vtn would produce something nice and generic
00:45jenatali: But let's just bake in the ABI and be done with the struct with all of its alignment problems and needing copy prop to remove it
00:46jenatali: Though your problem with vars_to_explicit is probably just because you haven't DCE'd and dead_variable removed that struct yet
00:49airlied: oh indeed maybe I'll try just doing some dead variable collection in there
00:59airlied: jenatali: okay I haven't ripped out two stage, I just added dead var collection on function temp
00:59jenatali: That works
01:01airlied: jekstrand: the branch is probably worth another look, and we should consider if we should just go vtn -> ssbo and be done
01:15jenatali: \o/ I built Clover on Windows
01:16jenatali: Well... compiled. Not linked yet
01:30airlied: okay now clover handles mismatched args/format string
01:32airlied: can I stop polishing it now :-P
01:33airlied: https://gitlab.freedesktop.org/mesa/piglit/-/merge_requests/418 has my piglit tests
01:33gitbot: Mesa issue (Merge request) 418 in piglit "cl: add some printf tests" [Opened]
08:48karolherbst: jenatali: dunno, but mesa is
09:14tfiga: danvet: cool, thanks
09:15tfiga: danvet: just to make sure, sorry for the stupid question, you used the userptr switch, right?
09:37danvet: tfiga, yup
09:41emersion: danvet: re drm_mode.h docs, it doesn't seem like the kernel-doc guide requires struct members to be documented inline
09:41emersion: see https://dri.freedesktop.org/docs/drm/doc-guide/kernel-doc.html#members
09:45emersion: actually, i'm lost -- only using in-line comments (and not @member comments in the struct doc-comment) results in warnings
09:47emersion: seems like multi-line in-line member comments confuses kerneldoc
09:47emersion: oh
09:47emersion: you need to add a newline after /**
09:47emersion: all right
10:01danvet: emersion, you can mix&match even
10:02danvet: for small struct (like argument containers or so) doing it at the top is tidier since less whitespace
10:02danvet: for anything bigger, or when you want to do multiline comments, imo best to put them all inline
10:03emersion: yeah
10:03emersion: i'm now looking at the legacy comments
10:04emersion: it sound like properly docuimenting those would be a lot more work
10:04emersion: documenting*
10:04emersion: (legacy comments: things like /**< … */ )
10:09emersion: honestly i'd rather not spend time documenting legacy APIs (like drm_mode_fb_dirty_cmd)
10:11mslusarz: is there any reason why LIBGL_DRIVERS_PATH still exists? meson seems to set DEFAULT_DRIVER_DIR correctly, so I wonder if we could just kill LIBGL_DRIVERS_PATH...
10:12emersion: it's still useful to change it at runtime
10:14mslusarz: why?
10:16emersion: point the loader to my locally-compiled gl libs
10:17mslusarz: using 2 interdependent libs coming from one project but built from different versions is just asking for trouble
10:18MrCooper: the DRI driver ABI is explicitly backwards compatible
10:20mslusarz: but what's the point of that? you can use LD_LIBRARY_PATH to use your locally-compiled mesa, so why would anyone want to just change the driver path?
10:33MrCooper: e.g. to run straight out of the build tree, without installing anywhere
10:52tzimmermann: mripard, i went through all the patchsets. i didn't look closer at the final 3 patches of the setup_commit stuff, because i wanted to discuss patch 1 first
10:54mslusarz: MrCooper: if the point of that is to have a quick build-test cycle, it's still achievable by building with a prefix, installing once and then symlinking the driver you are working on
10:55MrCooper: none of that is necessary now :)
10:55MrCooper: e.g. I use it to test new builds before installing them, this wouldn't work for that case
11:25glennk: if the local build had the same relative paths linking the loader with rpath $ORIGIN would be a nice alternative IMO
12:32danvet: mripard, is your bugfix going in through a -fixes tree?
12:32danvet: if so probably easier to just wait for the next -rc and backmerge that
12:32danvet: than topic branch for a -fixes patch
12:58mripard: tzimmermann: thanks a lot
12:58tzimmermann: you're welcome
12:58mripard: danvet: it's what I suggested to arnd, but he suggested to do that instead
15:26danvet: airlied, planning to reply to this xilinx driver?
15:31karolherbst: danvet: apparently they are planning to use ROCm for the userspace ...
15:32danvet: yeah I mean if it's rocm maybe should be in drm too?
15:32danvet: like amdkfd
15:32danvet: agd5f_, do we have an amd official take on this already?
15:33danvet: thus far the only reasons why AI accelerators ended up outside of drm in misc is because they don't have open userspace
15:33danvet: beyond a libdrm clone
15:34danvet: the g in gpu stands for general, not graphics :-)
15:35karolherbst: hehe
15:36mattst88: dcbaker[m]: if we could get 'glcpp: Handle bison-3.6 error message changes (!7659)' into the next 20.2.x and 20.3-rc I'd be pleased
15:37dcbaker[m]: mattst88: I'll pull it, is annoying me too :)
15:37mattst88: heh. it's waiting on Marge now I believe
15:38dcbaker[m]: I've got a few things to get done first, so I'm sure It'll be done when I'm ready
15:43MrCooper: if somebody could kindly replace python with python3 (or python2) in scripts as well, ninja test should pass again for me :)
15:46ZeZu: Does anyone know if amd binary drivers uses pm4 IT_NOP [where type3.size > 1] to embed event type data to send to kernel driver? On custom hardware so might be properietary but i'm getting 32[]{ IT_NOP , 0x6875 | eventID , ... } 0x0781==eventID is 'Label' writeback on EOP for instance
15:47dcbaker[m]: MrCooper: what distro doesn't have a python symlink? Last time I checked the guidance from the python foundation was python should point to some version of python, and scripts compatible with both should just that as their shbang
15:49MrCooper: dcbaker[m]: Debian sid didn't for some time; now there are python-is-python2/3 packages, but I don't know which one I should choose, nor why I should have to
16:08dcbaker[m]: MrCooper: I think because of scons most of our scripts still need to be both compatible
16:08dcbaker[m]: Just imagine python is cc, it doesn't matter if it's clang or gcc, it just should be something
16:10pepp: I think the problem is /usr/bin/python is missing on debian if only python3 is installed
16:11pepp: MrCooper: though I didn't know about the python-is-python3 package... that's useful
16:14MrCooper: dcbaker[m]: until one tries to run a script which uses python but is only compatible with the other one :)
16:19dcbaker[m]: Should fix those then. But i think for scons we need to keep a bunch of stuff python2 compatible
16:19dcbaker[m]: Maybe we can get rid of scons :)
16:20MrCooper: I thought scons worked with 3 now
16:34jekstrand: cmarcelo: I think I just about have my nir_jump_halt patches revived. Running Jenkins now.
16:34jekstrand: cmarcelo: I've done it "right" this time and made it actual control-flow in the back-end.
16:34jekstrand: curro: You may be interested ^^
17:00jenatali: Hm... anyone ever try to make the pipe_loader work on Windows? :)
17:00karolherbst: jenatali: why... :D
17:00jenatali: I'd like to be able to verify changes to Clover
17:00jenatali: Beyond just a build test
17:00karolherbst: mhh, but you wouldn't get driver loaded
17:00karolherbst: maybe besides swrast
17:01jenatali: Yeah, software'd be fine - though I guess swrast probably doesn't support Clover does it?
17:01karolherbst: llvmpipe does
17:01jenatali: Ah, right
17:02jenatali: I could probably make it work if I force it to use the static pipe loader for Windows...
17:03karolherbst: probably
17:03karolherbst: I have an MR somehwere for clover for it :D
17:03karolherbst: jenatali: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/833
17:03gitbot: Mesa issue (Merge request) 833 in mesa "WIP: Nuke dynamic pipeloader" [Clover, Gallium, Opened]
17:03karolherbst: probably needs some adjustments
17:05jenatali: Probably... Seems useful to have the dynamic path available though, at least from my external POV
17:05jenatali:shrugs
17:46jenatali: karolherbst: Compute Device Name = llvmpipe (LLVM 10.0.0, 256 bits), Compute Device Vendor = Mesa/X.org :D
17:48cmarcelo: jekstrand: ok
18:35neobrain[m]: Hey, how do people go about requesting Developer roles for Mesa? I joined the ACO folks a few months back and they've kindly been labeling and merging my MRs so far, but being able to do that stuff on my own would be very helpful 😇
18:36dcbaker[m]: You ask here, or send a message to mesa-dev :)
18:38neobrain[m]: Should I poke anyone in particular or do I cross fingers the right people will eventually see the message? :p
18:39karolherbst: jenatali: nice :D
18:40dcbaker[m]: neobrain: I'm not sure who all has permissions for that actually, It has to be one of the admins
18:41neobrain[m]: gotcha. I'll wait and see then, can take it to mesa-dev later if need be :)
18:41dcbaker[m]: looks like airlied can
18:42dcbaker[m]: just the first person I saw in the list with Owner permissions :)
18:43anholt: generally I'd recommend having someone from the part of the project you've been working on send a mail to mesa-dev proposing you.
18:44dcbaker[m]: mattst88: I got your patch in 20.3.0-rc2, and got that out the door. Now to slog through the backlog off 20.2 😒
18:44mattst88: dcbaker[m]: thanks!
18:44dcbaker[m]: no, thank you
18:45dcbaker[m]: now my ninja test works :)
18:45neobrain[m]: anholt: ah thanks, noted!
18:51hakzsam: dschuermann: time to write a small email for neobrain[m]? :)
19:24airlied: jenatali, jekstrand : hate to spoil your day, printf could likely do with one more how bad is this pass
19:24airlied: jenatali: nice work on clover
19:25jenatali: airlied: Sure, will take a look soon. I'd been following along yesterday and it didn't seem too bad?
19:27airlied: yeah I think it's at the we can stomach it stage :-P
19:32danvet: I'm still blown by the idea of printf in a gpu kernel
19:34jenatali: It's apparently in Vulkan now too, though implemented by layers instead of drivers
19:37jekstrand: Where it always should have been.....
19:46jenatali: airlied: FYI you overwrote my changes to that last commit - not a huge deal, since I'll likely need to rework things anyway if you changed the buffer layout
19:48airlied: jenatali: oops sorry
19:54jenatali: airlied: Looks more or less good to me, let me patch up that last commit again
19:56jenatali: Well, for however "good" printf can be anyway...
19:57airlied: jenatali: yeah I'm not sure about adding passes to passes
19:57jenatali: Yeah, wasn't sure it was a good idea
19:57airlied: jekstrand: do we have a nir guideance around that? like adding remove dead vars to the printf lowering pass rather than relying on the caller
20:00jekstrand: airlied: We do it sometimes
20:00jekstrand: Though, generally, I'd avoid it unless absolutely necessary.
20:13airlied: danvet: I thini might use rocm is a long way from is using rocm
20:32jenatali: airlied: Ran some of your piglit printfs, caught a bug in my printf handling, otherwise looking good :)
20:32jenatali: I re-pushed my clon12 patch
21:38robclark: it would be nice if it was more obvious that it is a good idea to run pass B if pass A made progress..
21:45anholt: robclark: weird, looking at skia it seems it only uses PACK_REVERSE_ROW_ORDER in one spot, where it sets it to false (the default)
21:46robclark: no, it uses it in the readpix path.. or at least the android version does
21:46robclark: if flipY, it toggles it on, then readpix, then toggles it back off
21:46anholt: ah, git grep not good enough
21:47anholt: ... nope, even with grep -r . I'm not finding that in my build on desktop.
21:48robclark: use remote https://android.googlesource.com/platform/external/skqp, branch android-cts-9.0_r12
21:48robclark: maybe this is something where android diverges from upstream?
21:49agd5f_: airlied, danvet: yeah at this point we are still separate companies and I don't know their products well enough to know whether this driver is even for the same hw as the stuff they are working on with ROCm
21:50agd5f_: will try and look over the patches though
22:01robclark: anholt: one thing I wonder about, this test is essentially doing TexSubImage2D and then inverted readpix.. which seems like a thing that is not going to work (although the test uses a solid color pattern so it might not notice)
22:03robclark: annoyingly, I can't easily recompile the test for android.. I have a suspicion that if it used PoT dimensions things would start working (modulo the TexSubImage2D vs inverted readpix)
22:08emersion: daniels: i don't know what to think about usage flags anymore. some people say "no no no", some say "yes yes yes"
22:09daniels: emersion: heh
22:09daniels: emersion: I guess knowing whether or not things are shared or scanout are indeed very useful
22:10daniels: the former lets you do various optimisations and potentially elide buffer accesses, the latter lets you actually allocate correctly
22:11emersion: i know
22:11emersion: but last time i tried adding usage flags
22:12emersion: krh and a few others nacked it
22:17emersion: i'd sure like to replace usage with something else, but lots of work (which i try to get done) and not happening anytime soon
22:19emersion: eric_engestrom and anholt also agreed with krh
22:19emersion: (apparently krh also upvoted his own comment :D )
22:24daniels: hahaha
22:24daniels: well, let’s pick that back up again now we’re working on hints
22:33emersion: daniels: hm, so should i try to get !3197 merged again?
22:35daniels: emersion: I think let's try to roll it into the hints interface, rather than bumping DRIimage twice
22:36ajax: "hinterface" surely
22:37emersion: i mean, !7603 will bump DRIImage anyways, right? so !3197 will just be a matter of making it public
22:37emersion: ok, i'll update the proto