00:27 hopetech: jekstrand: Any input on https://gitlab.freedesktop.org/mesa/mesa/issues/2467 ? In Clover, the variable creation failed for array
00:27 gitbot: Mesa issue 2467 in mesa "spirv_to_nir: variable creation fail." [Opened]
00:29 hopetech: IIn the spirv, we have an `OpArray` then a `OpTypePointer UniformConstant` and a `OpVariable`
00:32 hopetech: As we are setting the constant_as_global flag to true, the mode is then set to CrossWorkgroup
00:32 jekstrand: hopetech: Ugh
00:40 jekstrand: hopetech: Storage classes in SPIR-V can be... loose... :(
00:41 jekstrand: In Vulkan, UniformConstant always means UBO
00:41 jekstrand: It sounds like the clang is trying to "help" by saying that it's UniformConstant even though it's just a constant local thing
00:42 hopetech: Yes, but spirv-to-nir make it worse by setting it to CrossWorkgroup. ;)
00:42 jekstrand: Yeah
00:42 jekstrand: Which is probably wrong
00:42 jekstrand: I think setting it to CrossWorkgroup is a bad hack
00:44 jekstrand: We just do that because, at the end of the day, we want nir_intrinsic_load_global
00:44 jekstrand: Which I don't think is actually 100% true.
00:44 jekstrand: I think, at the end of the day, we want a new nir_intrinsic_load_global_constant
00:44 jekstrand: Unless, of course, it's just a temporary constant in which case we want it to copy-prop
00:47 hopetech: Well, we have the same issue if the array is define outside of the function
00:47 jekstrand: Sure
00:47 jekstrand: The problem is that the array is being declared at all rather than coming in as a pointer
00:47 hopetech: So a load_global would make sense
00:48 jekstrand: load_global is kind-of orthogonal
00:48 jekstrand:hates OpenCL
00:49 jekstrand: The real fundamental problem here is that OpenCL doesn't make a distinction between external memory, scratch, and shared.
00:49 HdkR: Doesn't everyone hate OpenCL?
00:49 jekstrand: HdkR: Yeah, pretty much.
00:49 hopetech: +1
00:50 jekstrand: So the way an OpenCL compiler is *supposed* to work is that you should just assume everything is a generic pointer and be happy with that unless you can either prove that it is a particular type of pointer or you have some type decoration telling you it's a specific type of pointer.
00:51 jekstrand: NIR, unfortunately, doesn't like to work that way.
00:51 jekstrand: NIR lives in graphics land where we have separate water-tight boxes for different types of things
00:57 hopetech: Yeah I get that OpenCL part.
00:58 airlied: hopetech: I'd also poke around some of karol's trees, there are many outstanding cl hacks
01:00 airlied: though I don't see much in that area
01:01 hopetech: airlied: Yes I saw that you have few branches related to ocl. I cherry-pick some patches tbh.
01:01 hopetech: But yes nothing related to storage class
01:04 airlied: hopetech: he also has some spirv-llvm-translator branches
01:05 airlied: https://github.com/karolherbst/SPIRV-LLVM-Translator/commits/for_nouveau
01:06 hopetech: we spoke at fosdem few days ago and try to fix the issue without luck
01:10 Kayden: mareko: https://mesa-ci.01.org/mareko/builds/2/group/63a9f0ea7bb98050796b649e85481845 - your build succeeded it seems, no failures at all.
01:20 imirkin_: jekstrand: i think it's doubly-annoying in that a pointer might be to global *or* shared (or local) memory
01:21 imirkin_: (or is that triply annoying)
01:21 imirkin_: i think there was talk about making fat pointers, but i dunno if that went anywhere
01:22 HdkR: With OpenCL can the address space not be known at runtime as well? So you pass a global,shared,local pointer through an generic pointer type and it "just" works?
01:23 airlied: magically :-P
01:23 imirkin_: that was my understanding.
01:23 imirkin_: or doesn't work, depending on the driver :)
01:23 HdkR: Well that explains the Nvidia LD instruction to me then
01:23 airlied: opencl2.0 introduced generic address space
01:23 imirkin_: HdkR: yeah, with the windows
01:23 imirkin_: you can definitely qualify pointers with global or whatever
01:24 airlied: in opencl 1.2 you had to qualify all of them
01:24 imirkin_: ah
01:24 airlied: generics cover local, global and private, const remains separate
01:24 airlied: kinda need it for SVM I think
01:25 jekstrand: imirkin_: I think that's nearly infinitely annoying. :P
01:25 airlied: https://software.intel.com/en-us/articles/the-generic-address-space-in-opencl-20 if you want details
01:39 jekstrand: airlied: Sure but that doesn't help the "OpenCL and NIR think differently" problem nearly as much as it looks like it does. :-(
02:23 airlied: jekstrand: yeah need to make NIR think different :-P
02:24 jekstrand: airlied: :P
02:26 jekstrand: airlied: I think we can, it's just going to take a more holistic approach that whacking storage classes and hoping for the best.
03:33 airlied: yay the nop.shader_test tess shader passes
03:34 jekstrand: :)
03:34 jekstrand: airlied: llvmpipe tess?
03:40 airlied: jekstrand: yeah, seemed like it would be good to increase CI coverage a bit further :-P
03:41 airlied: and the swr folks imported a working tessellator :-P
03:42 jekstrand: That was nice of them. :)
12:39 imirkin: hakzsam: feq != !fne with NaNs either ... the opts just need to be marked imprecise, i think.
12:40 imirkin: (er actually is that true? hmmm)
12:41 imirkin: yeah, i lied, nevermind.
12:53 hopetech: jekstrand: airlied: Not sure if I like that conclusion. ;)
12:59 jekstrand: hopetech: oh?
13:00 jekstrand: imirkin_: != is the one exception
13:00 jekstrand: imirkin_: Throws me off too
13:00 jekstrand: imirkin_: If one wants to make an ordered !=, it's rather annoying
13:08 hopetech: jekstrand: Well, I was hoping that the spirv-to-nir would be easier. :-P
13:08 hopetech: I'm trying to get a better spirv from llvm
13:09 hopetech: without UniformConstant or CrossWorkgroup then
13:12 jekstrand: hopetech: What storage class do we get in SPIR-V for a random pointer that happens to be tagged const?
13:12 jekstrand: hopetech: I'm trying to understand why clang is giving us UniformConstant there
13:20 hopetech: Dunno. I have to check
13:21 jekstrand: I sort-of suspect that we want NIR to grow a new nir_var_mode called nir_var_mem_constant
13:25 hopetech: SPIRV-LLVM-Translator give us the UniformConstant. I'm scared than the LLVM IR is already f up.
14:54 Venemo: daniels: another build flake, this time a "script failure" with meson-ppc64el: https://gitlab.freedesktop.org/Venemo/mesa/-/jobs/1602310
15:16 MrCooper: Venemo: could actually be a bug in src/compiler/glsl/tests/cache_test , e.g. valgrind flags it using uninitialized stack memory
15:17 Venemo: MrCooper: it just starts to feel like a cruel joke
15:18 MrCooper: that software is full of bugs? ;)
15:19 MrCooper: what do you suggest, should we go back to not trying to catch issues like this, just close our eyes and ears and pray?
15:19 Venemo: no offence meant
15:19 Venemo: it's just that something that is totally unrelated to what I do fails
15:20 MrCooper: increased testing coverage can turn up long standing bugs
15:20 Venemo: it sure can
15:28 idr: dcbaker: Let me know when you're online, Dr. Python. :(
15:37 dcbaker: whats up?
15:37 ribeiro_snps: Hi guys, I have been working with the dw_mipi_dsi driver and I'm implementing non-burst video modes. However, I can't find a DSI device that doesn't have enough memory to receive a complete line, i.e. it needs data to be transmitted in chunks. Can someone point me to a device with these requirements? Thanks!! :]
16:14 idr: dcbaker: I'm looking for some suggestions about https://gitlab.freedesktop.org/mesa/piglit/issues/31
16:14 gitbot: Mesa issue 31 in piglit "intel_shader_integer_functions2 mingw-w64 i686 build errors" [Opened]
16:15 idr: As far as I understand it, np.int32() behave wildly differently on 32-bit and 64-bit platforms. :(
16:15 imirkin_: py2 vs py3, i think
16:15 imirkin_: with py3, integers get auto-upgraded
16:15 dcbaker: imirkin_: those are numpy types
16:15 imirkin_: oh, this is numpy
16:15 imirkin_: fun.
16:16 idr: Hm... there could still be something to that.
16:16 idr: These are casts from "a type" to a numpy type. I guess if "a type" is different... maybe?
16:16 idr: Wait...
16:17 idr: Do we do 32-bit runs at all in the Intel CI?
16:17 idr: Why haven't we hit this?
16:17 idr: Duh... we must because there's another 32-bit bug.
16:17 dcbaker: idr: I think the bug is actualy somewhere else, numpy documentation says that `np.int32` is a int32_t type
16:18 dcbaker: so it should be the same on 64bit and 32bit platforms, unless my memory about C types is wrong
16:18 idr: Right... it's just barfing based on the input, so if the input is a different type.
16:18 dcbaker: that's on windows
16:18 dcbaker: or, with mingw at least
16:19 dcbaker: hmmmm
16:19 idr: Another user reported the same problem on Raspbian.
16:20 idr: So I don't think it's specific to Windows or mingw.
16:22 dcbaker: okay
16:28 MrCooper: Venemo: I filed https://gitlab.freedesktop.org/mesa/mesa/issues/2505
16:28 gitbot: Mesa issue 2505 in mesa "cache_test intermittently fails in ppc64el/s390x build jobs" [Glsl, Opened]
16:29 Venemo: thx MrCooper
18:59 jhli: daniels: Would you mind merging libdrm getfb2? Got reviewed by eric_engestrom now
18:59 jhli: https://patchwork.kernel.org/patch/11376679/
19:28 eric_engestrom: jhli: I just pushed it on a branch on my libdrm fork, and it failed the tests because you're exporting a couple of new symbols and need to add those to the list of allowed symbols (it's there to avoid accidentally exporting something)
19:28 eric_engestrom: jhli: https://git.io/JvCrg fixes it
19:31 eric_engestrom: jhli: https://gitlab.freedesktop.org/eric/libdrm/pipelines/107377 all green now :)
19:32 eric_engestrom: daniels: I'll let you have the final word on merging this though since it's your patch
19:35 Lyude: mlankhorst, mripard - have any of you gotten to the drm-misc-fixes merge yet?
20:06 jhli: eric_engestrom: Thanks!
20:22 jhli: eric_engestrom: daniels: added the symbols in v8 https://patchwork.kernel.org/patch/11376835/
20:22 jhli: eric_engestrom: thanks for all the help, much appreciated!
20:23 eric_engestrom: jhli: :)
20:24 eric_engestrom: jhli: btw running `ninja test` runs the tests, always a good idea to do that before sending patches
20:25 jhli: ahh got it
20:33 anholt_: daniels: I assume our arm builders are supposed to be running jobs at -j4 like x86, right?
21:08 pcercuei: What's the purpose of DRM_MODE_TYPE_PREFERRED exactly? It's the preferred mode when there is more than one?
21:08 ajax: typically for lcds it's the native pixel format
21:09 ajax: so, kinda yeah.
21:12 pcercuei: panel-simple.c confuses me, it sets this flag only if there is one single mode
21:17 seanpaul: Lyude: getting some unexpected timeouts on the mst tx_waitq on a new sideband message i'm working on (QUERY_STREAM_ENCRYPTION_STATUS)... it's not super deterministic, but when it fails it tends to fail multiple times. can you think of anything i should be on the lookout for?
21:31 sravn: pcercuei: See cda553725c92b9f908f6f69e9bc05de81384d817 for a little background info
21:32 sravn: pcercuei: But I do not know anything more than that, so if your analysis come uo with something better please let me know
21:33 pcercuei: hmm ok
21:33 pcercuei: I wonder if it's possible to change the fbdev emulation's video mode at runtime
21:47 Lyude: seanpaul: sigh, mst timeouts are always a pain. I guess the first few things that come to mind: improperly encoded messages, sending more then one tx at a time to the same mstb without waiting (this should have gotten fixed by amd), forgetting to clear an interrupt in the ESI
21:48 Lyude: Also: it's always good to make sure it's an actual tx timeout, and not some vague deadlock-like scenario between threads
21:52 Lyude: but yeah... there's a lot of stuff that seems to make hubs timeout instead of actually just, raising a sensible error code
21:53 anholt_: tomeu: any idea why !3661 is making t860 so slow? https://gitlab.freedesktop.org/anholt/mesa/-/jobs/1605456
21:54 anholt_: I've seen OOM killer happen in previous runs.
21:56 anholt_: I don't think I've increased ram pressure really -- +2MB of qcom firmware, but minus a bunch of kernel image. I think we strip out all the apt stuff, so adding non-free to the repos should be fine.
22:42 seanpaul: Lyude: thanks for the punch list!
23:20 daniels: anholt_: iirc the arm ones are aimed for -j8
23:20 anholt_: oh, interesting. if so, we should be bumping up our build jobs other than kernel and dropping down the kernel one.
23:21 anholt_: more -j would certainly help as it's taking me 50 minutes every time I try to make a kernel for the lava cluster.
23:22 anholt_: because we build arm32 and arm64 deqp and kernel in a single arm_build container.
23:22 anholt_: cache setup on the arms should be the same as for x86?
23:23 anholt_:would love some stable ccache
23:23 Kayden: you have to build the kernel? :(
23:23 anholt_: Kayden: we get to pick our kernel and deploy it. so you only need to rebuild it when you need to rebuild, but unfortunately a bunch of rebuilds are all globbed together and we have no ccache currently.
23:24 anholt_: with my docker setup, everyone gets whatever kernel I deployed on the cheza/db410cs and we have to live with that until I go offline them and update them individually, which is obviously awful
23:24 daniels: jhli: pushed now, thanks
23:27 jhli: thanks!
23:33 daniels: anholt_: there are only two aarch64 runners and they both have pretty big disk, so you should be able to see ccache
23:33 anholt_: daniels: ok, so we've got the /cache volume mounted to some storage on the disk
23:34 anholt_: oh. cool. we've got ninja with no -j args for the gl case. /o\
23:34 anholt_: wonder if this has contributed to some of our runners getting weird.
23:35 anholt_: (we really need kubernetes to load balance between our containers. and even then it would be nice if kube could lie to the pod about how many cpus existed so that we didn't have to manually tune our -js)
23:47 imirkin_: anholt_: idle curiousity on my part, but with is "no -j args" bad?
23:48 anholt_: imirkin_: ninja will make about 1 process per CPU, but we have concurrent jobs = CPUs / 4 (ish). so on big runners, now everyone's putting memory pressure on to try to get parallelism that isn't available.
23:48 imirkin_: aha, i see
23:49 anholt_: things probably mostly work out because you're not often stacked up against someone else that screwed up. but how much of our random shared runner failure is due to that, I wonder
23:49 imirkin_: and you're definitely incurring a lot more system time cost with that setup