00:00 pepp: airlied: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7525 will remove a unused one
00:00 gitbot: Mesa issue (Merge request) 7525 in mesa "radeonsi: remove unused NO_RB_PLUS flag" [Radeonsi, Opened]
00:00 airlied: ah it's due to the new stages in mesa
00:00 airlied: if I add a kernel debug flag it bumps the baseline to 14 now
00:01 airlied: kina worked around it for now
00:03 airlied: mimi89999: rebased again
00:05 mimi89999: Building
00:05 pepp: I guess DBG_ZERO_VRAM could be removed as well since radeonsi_zero_vram=true does the same thing
00:09 jenatali: jekstrand, karolherbst: Remind me where we landed on f2f16_rtne/rtz after the new conversion intrinsic?
00:09 karolherbst: uhm... I think for CL you want to have the explicit variants and you can just lower the alu ones to them
00:10 jekstrand: jenatali: I'd probably be ok seeing them go but we'd have to plumb the intrinsic through to the Intel back-end and I'm lazy.
00:10 jekstrand: jenatali: I think spirv_to_nir only ever generates the intrinsic for kernels.
00:10 karolherbst: jenatali: https://gitlab.freedesktop.org/karolherbst/mesa/-/commit/e04d8c4ff47f060625f0a82255cb11301310ae2c
00:11 jekstrand: jenatali: Yeah, reading the code it looks like kernels only ever get the intrinsic.
00:11 jenatali: jekstrand: Ah ok, cool, I can delete a bunch of code then
00:11 karolherbst: jekstrand: I don't think it's true though? I think you still get the alu ones for some stuff
00:12 jekstrand: jenatali: I'd like to get rid of the ALU ops but that's a task for another day
00:12 karolherbst: :D
00:12 karolherbst: yeah
00:12 jenatali: jekstrand: That's a tall task, yeah
00:12 jekstrand: karolherbst: Only for trivial cases. But not for the f2f16_rtne/rtz case.
00:12 karolherbst: sure
00:12 jenatali: Wait for me to finish rebasing/upstreaming our CL stack? :)
00:12 karolherbst: but jenatali talked about removing code, so someting alike the commit I linked to will be required
00:12 jekstrand: karolherbst: I think we want to keep the trivial ones just because they're amazingly useful and the optimizer can reason about them.
00:13 jenatali: karolherbst: I have CPU implementations of the f2f16 with all rounding modes that I can delete, since I can just rely on constant folding
00:13 karolherbst: not really worth the effort maintaining both paths
00:13 karolherbst: jenatali: ohh, I see
00:13 karolherbst: jekstrand: yeah.. it's a tough call
00:13 jekstrand: jenatali: I think I'm done churning for a while. :)
00:14 jenatali: jekstrand: Great, it's going to painful enough after the existing churn :P
00:14 jekstrand: jenatali: I've got NIR to the point where I can compile my BVH building kernels so I'm happily off doing other things for a while.
00:14 jenatali: Nice :)
00:14 airlied: jekstrand: without eating all the RAM?
00:15 jenatali: Hopefully by EOW I'll have our CL frontend rebased and working again
00:15 jekstrand: jenatali: My point was that if you start rebasing now, NIR's liable to remain stable for a few weeks or even a month or two. It's a good time to rebase and try to land. :)
00:15 jenatali: Assuming I don't get distracted by other stuff along the way
00:15 jekstrand: airlied: Yup. And it only takes about 5 min to compile the shaders. 🙃
00:17 airlied: jekstrand: did you do function calls or just optimise before inline?
00:17 jekstrand: airlied: I optimize after inline
00:17 mimi89999: ../src/amd/llvm/ac_nir_to_llvm.c:3251:1: error: control reaches end of non-void function [-Werror=return-type]
00:17 jekstrand: airlied: These aren't those evil benchmark shaders. :P
00:17 mimi89999: Same error
00:17 mimi89999: I pulled latest changes
00:18 karolherbst: jekstrand: right.. still wanted to look into the generic pointer stuff, but it's just soo many patches :D
00:18 jenatali: It's not *that* many
00:18 jekstrand: karolherbst: Generic pointers landed. :P
00:18 karolherbst: you had a second MR
00:18 karolherbst: or does it simply require a rebase?
00:18 karolherbst: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7433
00:18 gitbot: Mesa issue (Merge request) 7433 in mesa "WIP: clover/nir: Generic pointer support" [Nir, Opencl, Clover, Opened]
00:19 airlied: mimi89999: doh fixed that now
00:19 jenatali: karolherbst: That's for global variables, to support the generic CTS tests
00:19 jenatali: jekstrand: That MR probably needs a better name :)
00:19 airlied: once the remaining CL3 MR lands generic shouldn't be testable
00:20 jekstrand: karolherbst: Oh, right. That one needs a rebase and probably a bit of love too. There are some hacks in there.
00:20 jenatali: airlied: The generic tests rely on other CL2.0 features, so those need to be implemented regardless of whether CL3.0 claims they're optional
00:20 airlied: sucky tests :-P
00:21 jekstrand: jenatali: With that branch, most of the CL2.0 generic tests pass.
00:21 jekstrand: I don't remember which ones still failed.
00:22 jekstrand: I should try to extract my ANV patches for building CL kernels and post them.
00:23 jekstrand: There are some interesting tidbits in there that'd be good to get someone else's opinion on.
00:25 jekstrand: In particular, if we want to actually optimize things, we really want to separate assigning explicit types from assigning variable locations.
00:25 airlied: jenatali: do you pass the clBuildProgam options directly to clang?
00:26 jenatali: airlied: I parse them first but otherwise yeah
00:27 airlied: a recent patch to llvm/clang seems to have broken -cl-denorms-are-zero in cc1 mode
00:28 airlied: at least clover broke, not sure what we are meant to do
00:28 jenatali: Broke how?
00:29 airlied: it no longer accepts that option as a cc1option
00:29 jenatali: Oh...
00:30 jenatali: airlied: Do you know which patch? Or how recent? We're still using LLVM10 for code we're going to ship, just wondering when we should expect to hit it
00:31 airlied: a4451d88ee456304c26d552749aea6a7f5154bde is wthat broke it, it's in llvm12 timeframe
00:31 airlied: I'm going to send a mail and see if anyone else cares
00:36 airlied: I just sent a mail to cfe-dev see if I get any bites
00:36 airlied: jenatali: just need llvm12 for cl3
00:37 jenatali: airlied: Ah, that makes sense
00:54 airlied: mimi89999: oh also it's AMD_CL_NIR=1 now
00:57 mareko: airlied: there are "options" which can replaces most of the debug flags
01:24 mimi89999: airlied: I noticed no difference whatsoever. Neither in correctness nor in speed.
01:28 mimi89999: I thing that it might be interesting to try to get a minimal OpenCL test case from that code.
01:41 karolherbst: dcbaker[m]: I think we will need support for external dependencies with rust... there is just so much good stuff out there which would be painful to reimplement just because :/
01:56 dcbaker[m]: karolherbst: I'm working on it. I did get color support wired up today
02:49 airlied: jekstrand: on intel how would a printf string arg address end up, just a 64-bit ptr to the constant address in gpu space/
02:50 jekstrand: airlied: Uh... It could be.
02:51 airlied: or is it one of those vec2 things
02:51 airlied:isn't sure we can meaningfully map that 64-bit value back to the string in clover
02:53 airlied: https://paste.centos.org/view/raw/b4ea2d71 is the pre printf lowering nir
02:54 airlied: I wonder if I could detect stores to the printf var and work out it's a string
02:54 airlied: seems messy as well
03:01 airlied: uggh that seems like it would needs two passes
03:02 airlied: one pass to find the printf str from the printf instr, then another to find all the stores to it
04:01 airlied: jenatali: where do you interface to clang?
04:02 airlied: apprantly we might interface to clang kinda wrong in clover
04:15 airlied: jenatali: https://lists.freedesktop.org/archives/mesa-dev/2020-November/224721.html for some more info
05:58 jenatali: airlied: I'm pretty sure we just copied from Clover so we probably do it wrong too: https://gitlab.freedesktop.org/kusma/mesa/-/blob/msclc-d3d12/src/microsoft/clc/clc_helpers.cpp#L604
09:50 lynxeye: panfrost CI runner seems to be broken, LAVA isn't able to control power
09:50 lynxeye: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/5530631
10:06 tomeu: lynxeye: thanks, it's being take care of
10:07 tomeu: will take around 30 minutes, if you are in a hurry to merge stuff we could disable lava jobs
10:08 lynxeye: tomeu: thanks! no need to disable jobs, I'll just retry in an hour or so.
10:08 tomeu: cool, sorry for the trouble
10:33 pq: How does one make sure that a C struct has no holes/padding? Like something to have the compiler error out if there is any padding added. Also for bitfields, error out if any unused bits. I'd assume this is very much on topic for the kernel and Mesa.
10:34 pq: or do you just rely on pahole and manual inspection/review?
10:37 pendingchaos: Mesa has a PACKED macro in macros.h which expands to __attribute__((__packed__)) and removes padding
10:37 pendingchaos: ACO inserts unused padding members and static_asserts that the struct size is what's expected
10:37 pq: That's not what I'm after though. I want to see that there is no padding to be removed in the first place, and AFAIK packed doesn't work on bitfields.
10:38 pq: as in, if you have unused bits in a word, packing does not magically make then used (defined)
10:41 MrCooper: pq: don't know of anything other than pahole
10:44 pq: static_assert on struct size may be good enough if reviewers are always alert
10:49 MrCooper: I'd expect reviewers to be aware of this when it comes to kernel UAPI structs, otherwise not so much
10:56 pq: yeah, I'd like to use a struct as a "binary key" in Weston... I presume Mesa does that a lot, too
10:56 pq: for internal stuff
10:57 pq: static_assert on struct size with a big comment sounds like the best there could be
11:04 MrCooper: sounds good
11:33 tzimmermann: is gem object's vmap expected to pin the BO memory? or is a separate pin call required? we have both semantics in our drivers
12:04 glennk: pq, you can static assert on struct member offsets
12:07 pq: glennk, I could for non-bitfield(?) members, but what would be the benefit compared to asserting on struct size?
12:08 glennk: depends on if you have types that differ in size, ie pointers on 32 vs 64
12:12 pq: wouldn't everything after a pointer be at different offset anyway?
12:12 pq: luckily I think I won't have any pointers in the struct at least
12:12 pq: bitfields OTOH would be applicable
12:13 glennk: you'd just be checking offsetof(n)+sizeof(n) == offsetof(n+1)
12:13 pq: ah, that way
12:17 pq: would that have any advantage over static_assert sizef(struct) == sizeof(struct.foo) + sizeof(struct.bar) + ... + bytes_for_bitfields)?
12:19 glennk: other than telling you which member if the assert fails, i don't think so?
12:20 pq: alright
13:38 Vanfanel: Hi. I am trying to add Vulkan support to SDL2 outside X, using the VK_KHR_Display extenstion. I have this extension active and I can retrieve the pointer to vkCreateDisplayPlaneSurfaceKHR(), as in here: https://github.com/vanfanel/SDL/blob/11e4911657edc495e196b9f262b0b523fe9ad8e0/src/video/kmsdrm/SDL_kmsdrmvulkan.c#L179. However, when I try to get the display count using
13:38 Vanfanel: vkGetPhysicalDeviceDisplayPropertiesKHR(), I get 0 displays, as in: https://github.com/vanfanel/SDL/blob/11e4911657edc495e196b9f262b0b523fe9ad8e0/src/video/kmsdrm/SDL_kmsdrmvulkan.c#L276. Any idea on what am I doing wrong, please? I am new to Vulkan
13:41 Vanfanel: I mean: in order to get a display count using vkGetPhysicalDeviceDisplayPropertiesKHR(), all I need is an vkInstance with VK_KHR_Display extension active, right?
14:02 xexaxo1: pq: newer version of pahole show bitfield holes, amongst all it's usual goodness.
14:04 xexaxo1: pq: as a bonus point - one can write a simple CI test (include the relevant struct, building binary, process via pahole, parse the output and return pass/fail)
14:10 pq: xexaxo1, by newer version, do you mean the pahole gdb command?
14:12 pq: or the stand-alone tool?
14:12 xexaxo1: pq: just a simple $pahole path/to/binary.o
14:14 pq: looks like I was confused by https://blog.mozilla.org/sfink/2018/08/17/type-examination-in-gdb/
14:15 xexaxo1: pq: pahole --version 1.18 produces - /* XXX 23 bits hole, try to pack */
14:18 xexaxo1: pq: don't forget to add -g to the compiler flags, otherwise pahole won't have enough data
14:18 pq: thanks
16:09 mimi89999: https://www.phoronix.com/scan.php?page=article&item=intel-server-igc&num=1
16:09 mimi89999: Do I understand correctly that OpenCL will be supported in Mesa on Intel? What about their Neo driver?
16:22 mdnavare: vsyrjala: still see the divide error in i915_gem_object_create_stolen_for_preallocated from the big joiner prep series
16:23 vsyrjala: that's not where it comes from
16:25 mdnavare: vsyrjala: hmm looking at the trace its somehere in intel_initial_commit() intel_atomic_check, but unable to find the whats causingg this
16:26 mdnavare: vsyrjala: like the only difference is this wrapper for get_pipe_config
16:26 vsyrjala: i suspect something is zero in pipe_mode, which blows up in the wm calculations
16:28 dcbaker[m]: mimi89999: I strongly suspect that neo is staying, but i don't have any inside information
16:33 mdnavare: vsyrjala: but i am explicitly setting pipe mode to be hw.adjusted_mode there
17:48 jaganteki: Hi, any reference driver for DSI device which is I2C slave? The DSI device has 4-lanes with I2C registers for configuring DSI path.
18:40 asdf28: is mesa supposed to install the opengl header files into /usr/lib? or do i have to install and download them myself?
18:41 asdf28: , /usr/include, i meant
18:41 imirkin: asdf28: i think the new thing is to use glvnd, which would handle those header files
18:41 Kayden: libglvnd installs the GL header files in /usr/include/{EGL,GL,GLES2,GLES3,KHR}
18:42 asdf28: i was just wondering if it's normal that these are missing after installing mesa
18:42 imirkin: asdf28: if it's made to work with glvnd, then yes, it's normal
18:43 asdf28: i have "glvnd=false" in my configure options
18:43 imirkin: then no, it's not normal
18:43 imirkin: :)
18:43 asdf28: hmm yes seems not right
18:59 asdf28: never mind, it was the build system that i was using
18:59 asdf28: it somehow redirected the install location
18:59 asdf28: but it's there now
19:03 jenatali: Woo I have some kernels working on top of master
19:04 airlied: jenatali: nice!
19:47 xaphir: airlied, what's your build system of choice?
19:53 airlied: xaphir: whatever someone else maintains for me :-P though if I was starting a project i'd probably use meson now
19:56 swivel: does meson integrate readily with recursive autotools? like if my meson project has a libfoo vendored in-tree and libfoo uses autotools, needs an autoreconf bootstrap etc
19:56 swivel: off-topic I know, just curious if you happen to know ;)
19:56 airlied: friends don't let friends vendor autotools projects :-P
19:57 swivel: hey it's how i've been doing my personal projects and it works pretty well
19:57 Kayden: what about vendoring projects with shite cmake...asking for a friend :P
19:57 swivel: at least when the whole stack is autotools
19:59 swivel: i think i saw a post on this subject recently on planet gnome come to think of it, i should prolly just go find that
20:01 dcbaker[m]: Meson has subproject support for other meson projects and cmake. There's a guy this been working on autotools support
20:01 dcbaker[m]:is also a meson developer
20:07 xaphir: dcbaker[m], I sorely need to spin up a container and get started on getting a build system working. Where do I start with documentation?
20:08 LiquidAcid: if an application create a buffer via DRM_IOCTL_MODE_CREATE_DUMB, can it happen that the buffer remains after the allocation exits?
20:09 xaphir: airlied, thank you sincerely for pointing me in the right direction
20:12 HdkR: I use cmake for my project. How soon until I'm reformed? :P
20:13 airlied: cmake's reason for use mostly seems to be it works on Windows which seems to mean people use it when it's truly horrible
20:15 linkmauve: HdkR, I still haven’t managed to cross-compile said project. :p
20:15 linkmauve: Nor to build it natively. ^^'
20:18 HdkR: linkmauve: Time investment is hard
20:20 dcbaker[m]: xaphir: mesonbuild.com has some documentation, the function references are better than the walkthrough
20:21 dcbaker[m]: There's also the meson init command line
20:21 dcbaker[m]: Which will create a really basic project
20:31 xaphir: dcbaker[m], much appreciated!
20:32 dcbaker[m]: The #freenode_#mesonbuild:matrix.org channel is also friendly and helpful
21:15 jenatali: Wow, only 2 failures out of 93 unit tests after a bit more hacking, almost there
21:40 karolherbst: why do we have 2020 and people still think that unsafe APIs are what we need more of? ....
21:40 karolherbst: 0 terminating lists are .... ufff, *sigh*
22:02 mdnavare: hwentlan: whats Nicholas's irc nick?
22:02 mdnavare: hwentlan: had a few question on VRR performance on fps lower than 40Hz
22:09 hwentlan: mdnavare: if i remember correctly it's kazlaus. i don't see him here right now, though
22:33 mdnavare: hwentlan: Okay will probably send out an email to dri-devel then and him
22:34 mdnavare: hwentlan: Btw do you know how AMD driver behaves for the frames requsted at <40Hz , if monitor range is 40-60Hz?
22:34 mdnavare: hwentlan: with vrr
22:37 hwentlan: i don't know exactly what we do there anymore. there have been some changes in that area. in some scenarios we might double up the frames.
22:38 mdnavare: Would Nicholas know it better? Because wanted to know in that case how kms_vrr is validating that case
22:42 dcbaker[m]: karolherbst: you mean people should stop using C? :D
22:44 karolherbst: dcbaker[m]: I meant, given how easy it is to mess up in C, we shouldn't create APIs making it even easier
22:44 robclark: speaking of C.. if you have a union with multiple sized elements (lets just call it, nir_const_value).. and initialize just smaller vals in the union (ie. nir_const_value foo = { .u16 = 3 }, is it guaranteed that the rest of the bits will be zero'd, or is accessing foo.u32 undefined behavior
22:45 karolherbst: robclark: uhm.... good question.. I bet on undefined
22:45 karolherbst: but maybe it's not?
22:45 karolherbst: dunno
22:45 robclark: trying to decide if https://gitlab.freedesktop.org/mesa/mesa/-/issues/3778 is a clang bug, or our bug ;-)
22:45 gitbot: Mesa issue 3778 in mesa "freedreno/nir: nir_validate failure after nir_lower_tex" [Freedreno, Ir3, Opened]
22:45 jenatali: Pretty sure it's undefined
22:46 hwentlan: mdanavare, nicholas would know more details
22:46 karolherbst: robclark: yeah.. we tend to 0 init that stuff in nir
22:46 karolherbst: explicitly I mean
22:46 robclark: nir_lower_tex does:
22:46 robclark: https://www.irccloud.com/pastebin/sNlMKxcE/
22:46 robclark: (not sure how wide-spread that sort of pattern is in nir)
22:46 karolherbst: robclark: that sounds wrong
22:47 karolherbst: robclark: check the const helpers
22:47 karolherbst: they all memset to 0
22:47 robclark: I guess one option is to just fix it in nir_build_imm()
22:47 karolherbst: robclark: that's already fixed in nir_build_imm
22:47 karolherbst: uses rzallo
22:47 karolherbst: *rzalloc
22:48 robclark: look closelier
22:48 robclark: at the memcpy ;-)
22:48 karolherbst: so?
22:48 karolherbst: the instruction is rzalloc
22:48 robclark: it's happily copying over garbage from the stack ;-)
22:49 karolherbst: you mean from the instruction input
22:49 karolherbst: uhm
22:49 karolherbst: function
22:49 karolherbst: so the input has to be 0init as well obviously
22:49 karolherbst: and all the helpers are doing it already
22:50 robclark: right, but things that call nir_build_imm() don't (or at least nir_lower_tex doesn't)
22:50 karolherbst: right, because the struct comes from the stack.. mhh
22:50 robclark: anyways, if that is UB then I know how to fix this.. was just trying to understand who was at fault
22:50 jenatali: robclark: https://en.cppreference.com/w/c/language/union - If the size of the new type is larger than the size of the last-written type, the contents of the excess bytes are unspecified (and may be a trap representation)
22:50 karolherbst: robclark: maybe use the nir_const_value_for_float helper?
22:50 karolherbst: like the vec builders do
22:51 robclark: ok, yeah, sounds like UB
22:51 karolherbst: anyway, it should use nir_const_value_for_float :)
22:56 robclark: just reviewing other callers of nir_build_imm(), looks like load_bordercolor() in dxil_nir_lower_int_samplers has the same issue
22:57 robclark: I think.. unless not specifying which member you initialize means you initialize the biggest one
22:57 karolherbst: hard to say. what about structs within unions?
22:57 karolherbst: maybe the biggest fitting one?
22:58 karolherbst: or maybe just the "standard" one, so int for ints and double for floats?
22:59 robclark: hmm, and ycbcr_model_to_rgb_matrix()..
23:12 jenatali: robclark: Not specifying initializes the first one
23:12 jenatali: https://en.cppreference.com/w/c/language/struct_initialization
23:12 jenatali: When initializing a union, the initializer list must have only one member, which initializes the first member of the union unless a designated initializer is used (since C99).
23:13 robclark: ok, and predictably the biggest field is the last one ;-)
23:13 jenatali: Heh, figures
23:32 jenatali: Finally, 93/93 passing tests for CL on master... almost ready for an MR
23:33 airlied: jenatali: \o/
23:41 mareko: can someone from Intel please bisect this failure? https://mesa-ci.01.org/mareko/builds/20/group/63a9f0ea7bb98050796b649e85481845