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