00:03 karolherbst: ehhh...
00:04 karolherbst: the heck :/
00:04 karolherbst: sooo mhh
00:04 karolherbst: samplers declared inside the kernel are a bit busted
00:04 karolherbst: as it seems
00:04 jenatali: We do some post-processing on them after vtn
00:04 karolherbst: what kind?
00:05 jenatali: For one thing, deduping
00:05 jenatali: Apparently LLVM creates a new sampler for every call site where it's used
00:05 karolherbst: super
00:05 jenatali: Beyond that I think we just reflect the info out to the runtime so it can bind an appropriate D3D sampler at the right spot
00:05 karolherbst: mhh
00:05 karolherbst: right...
00:06 karolherbst: atm the image lowering pass jekstrand wrote trips over it :/
00:06 karolherbst: ahh heh
00:06 karolherbst: /* TODO: Constant samplers */
00:06 karolherbst: :D
00:07 karolherbst: I guess I should fix the CTS stuff first :D
00:19 jenatali: Hmmm, running with a debug build I get a metadata assertion after nir_lower_vars_to_ssa
00:25 jenatali: Or maybe after nir_opt_algebraic
00:41 jenatali: karolherbst: it was nir_opt_algebraic because it early-returned due to OOM... after I fixed that assertion, the compile gobbled so much memory it hung my PC
00:41 airlied: assigning clover CI to marge now
00:41 jenatali: airlied: Nice!
00:42 airlied: daniels, MrCooper, anholt : any issues caused with the clvoer CI job feel free to take this comment as an r-b for temporary switching off if I'm asleep :-P
00:42 karolherbst: jenatali: just disable swap :p
00:45 jenatali: karolherbst: That'll fix the machine hang but it'll still just OOM and crash
00:45 jenatali: Seems like there's some memory usage somewhere that needs to be optimized...
01:34 airlied: llvmpipe scratch support working
03:50 jekstrand: karolherbst: Yeah, I'm not sure what's going on with 3D. They're busted on iris too.
03:51 jekstrand: karolherbst: Throw me your branch and I'll look at it tomorrow
03:53 jekstrand: karolherbst: Yeah, I didn't get to immutable samplers. They shouldn't be too hard. We just need to do the deduplication like jenatali suggests (possibly as its own pass?) and come up with something to scrape them out and tell clover to set up samplers. I'm sure it's already got the binding stuff for it for LLVM, we just need to write the scraper and wire it up.
03:57 airlied: karolhebst, jekstrand: does the ppiglit calls test fail in validation for you?
03:57 jekstrand: airlied: I don't know. I've never run piglit. Command line?
03:58 airlied: ./bin/cl-program-tester ./tests/cl/program/execute/calls.cl
03:59 jekstrand: airlied: Yup
03:59 jekstrand: airlied: On a ptr-as-array on a uvec4
03:59 jekstrand: airlied: Which is weird because I didn't think OpenCL SPIR-V allowed that.
04:00 jekstrand: Wait...
04:00 jekstrand: Yeah, that's nir_validate throwing a fit when it shouldn't
04:00 jekstrand: ptr_as_array needs to be allowed on everything in CL
04:00 jenatali: Yep
04:02 jekstrand: It's phis that are blowing up
04:02 jekstrand: airlied: If you delete that bit of validation, it passes.
04:06 jekstrand: airlied: https://paste.centos.org/view/595a219a
04:06 jekstrand: Hacking on OpenCL is too much fun...
04:07 jenatali: :P
04:08 airlied: jekstrand: works for me
04:10 airlied: if you do put it in an MR the CL CI results will need updaint
04:11 jekstrand: airlied: Or I can just let you put it in an MR. :P
04:12 airlied: I'll just add it to the end of this fixes one I'm doing now
04:29 airlied: jekstrand: now part of https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7058
04:31 jekstrand: cool
05:01 jekstrand: airlied: So, who's hooking up clover for radeonsi?
05:41 airlied: jekstrand: I've got the start of it somewhere from before
05:42 airlied: switches over from the llvm native path to the nir path
05:48 airlied: jekstrand: I'll likely revive it once I get llvmpipe a bit more polished
06:17 AndrewR: airlied, thanks you !7051 and !7058 dramatically improved piglit tests for me :}
06:28 airlied: wow those piglit trig tests blow out in runtime, piglit times them out v quick
06:34 airlied: jenatali: how do you handle mad_hi on non-32 bit got some lowering?
06:36 jekstrand: airlied: nir_lower_int64 will do it
06:36 airlied: jekstrand: for 8 and 16bit?
06:37 jekstrand: airlied: Uh... no. But for those, you can just do a bit_size*2-wide mul and take the top half
06:37 jekstrand: airlied: Not sure if we've got a thing for that or not
06:37 airlied: I can probs just do it in the nackend
06:37 airlied: backend
06:38 airlied: it's one of the few remainging piglit fails, tomorrow me problem
06:38 jekstrand: nice
07:10 jekstrand: karolherbst: Fixed the readimage3d tests. It was a bug in my clover_arg_size_align function.
07:10 jekstrand: karolherbst: If you pull the latest version of " compiler/types: Allow images and samplers in get_explicit_type_for_size_align
07:10 jekstrand: from my tree, that should fix it.
07:10 jekstrand: karolherbst: 44d8676a7d176fce7f79d07c3d288f7af74ba93e
07:19 jekstrand: karolherbst: Actually, did a bit more work. You want both compiler/types patches and "clover/nir: Calculate sizes of images and samplers properly"
07:21 jekstrand: karolherbst: clover_arg_size_align was returning an alignment of 0 for samplers which causes nir_lower_explicit_io to reset the offset to 0 thanks to the way the ALIGN macro works.
08:00 pq: hey, that's a cool new term: "nackend" :-D
08:01 pq: a bit like a mock I suppose but just says no to everything
08:21 AndrewR:reads patents ... https://patents.google.com/patent/US6308237B1/en - not sure if ATI ever applied this idea to any real (AGP) GPU?
08:22 AndrewR: and this probably about command processor on ATI cards from 1998 era .... https://patents.google.com/patent/US6184908B1/en
08:23 pq: Shouldn't you know better than to read any patents?
08:25 AndrewR: pq, I'm only user, not real developer ....
09:03 danvet_: tzimmermann_, I said "maybe too much to do in this series"
09:04 danvet_: i.e. not an expectation from me that you'll do ttm_bo_vmap/vunmap
09:04 danvet_: it's a bit more than I thought
09:04 tzimmermann_: danvet_, i've done it already
09:04 tzimmermann_: it's actually a bit hard for me to tell what you what to see in the next iteration
09:05 danvet_: well sometimes I just don't know what's reasonable
09:05 krh: mareko: I assume your R-bs were for the st/mesa commits oonly
09:05 danvet_: or something that looks reasonable isn't
09:05 tzimmermann_: ttm_bo_vmap requires certain amount of additional code. the alternative is the existing ttm_kmap_obj_to_dma_buf_map
09:05 tzimmermann_: there's really no middle ground
09:05 danvet_: yeah I realized that with the discussion
09:06 danvet_: I guess the split you had is ok, if a bit ugly
09:06 danvet_: but should be just interim
09:06 tzimmermann_: but adding ttm_bo_vmap and drm_gem_ttm_vmap allows to remove code in amdgpu, radeon and nouveau. so the net-diffstat is probably negative :)
09:07 tzimmermann_: i'll send out the next iteration and then you'll see. but please don't ask me to cleanup ttm_bo_kmap() as well :P
09:07 danvet_: yeah that's why I suggested it, it's really what most drivers would want
09:07 danvet_: nah ttm_bo_kmap is a different thing :-)
09:08 tzimmermann_: with ttm_bo_vmap in place, only vmwgfx uses ttm_bo_kmap
09:08 tzimmermann_: i wonder if there's a better/simpler interface
09:08 tzimmermann_: that does the same thing
09:09 tzimmermann_: i think all other drivers could be done with ttm_bo_vmap
09:10 danvet_: tzimmermann_, outside of ttm it's split in two interfaces
09:10 danvet_: vmap for "map entire thing as virtual-contig block"
09:10 danvet_: and kmap for "map individual pages"
09:11 danvet_: both exist in an iomem and system memory version
09:11 danvet_: so 4 variants in total
09:11 danvet_: ttm smashes them all into one big function
09:11 tzimmermann_: maybe ttm could adopt that policy
09:11 danvet_: yeah I think that's the plan with Christian
09:12 danvet_: ttm_bo_vmap for the contig stuff, with the iomem vs normal hidden behind dma_buf_map
09:12 danvet_: and same for kmap side
09:12 tzimmermann_: yeah
09:13 danvet_: we might also just pull the kmap variant out
09:13 danvet_: since the most efficient one for that isn't supported by ttm I think
09:15 danvet_: tzimmermann_, [PATCH] drm/fb-helper: Add locking to sysrq handling <- if you got time for a small one
09:15 danvet_: only noticed while reading code
09:22 tzimmermann_: danvet_, done
09:44 Amarok19: I've got the simplest newbie question about building mesa from source with meson: after I ran `ninja -C build/` where should I expect .so files to appear?
09:49 vsyrjala: find build -name \*.so
09:57 Amarok19: OK, thanks! And if this yields nothing can it happen that my build compiled but generated no "artifacts"?
10:00 vsyrjala: did the build actually succeed?
10:03 Amarok19: yes, it did. Only some casual warninigs popped up about declared-but-not-used variables, nothing more serious. But I'm not really experienced in building using meson, so there may theoretically be something I'm missing.
10:08 vsyrjala: at least if you didn't disable all apis/drivers/platforms/etc. with meson i'd expect a bunch of things to be there
10:09 vsyrjala: could also do 'DESTDIR=/tmp/foo ninja -Cbuild install' and see what files come out
10:10 Amarok19: In my case I'm after one particular .so file, so I used -Ddri-drivers=i965 when configuring the build
10:11 Amarok19: My bad that I started discussing this now at the office where I don't have access to my personal machine I've been building on so I can't paste any particular info here.. But it looked as if it all worked
10:11 Amarok19: Oh
10:11 Amarok19: But wait
10:11 Amarok19: I never used the `install` keyword
10:12 MrCooper: there is no i965_dri.so in the build directory, if you're looking for that specifically
10:12 Amarok19: Alright so maybe I'm trying to do the entirely wrong thing building mesa altogether
10:12 Amarok19: I'll describe my case A-Z if you don't mind?
10:14 MrCooper: i965_dri.so is only created during ninja install, as a hardlink to the single *_dri.so in the build directory
10:14 Amarok19: Ahh, this explains a lot!
10:15 Amarok19: OK, I don't think I can get anywhere without explaining what I'm trying to do, so I'll just go ahead and try to shortly describe it
10:15 MrCooper: if you want to use it directly out of the build directory, you can create a symlink there
10:18 Amarok19: I'm trying to package an app in a snap (snapcraft) and the resulting app crashes on a segfault on Wayland. My (first ever) attempt to use gdb led me to info that the segmentation fault occurs in i965_dri.so.
10:19 Amarok19: So as my snap is built using Ubuntu 18.04's repositories... I thought "OK, let's build this file from source from a fresher release, maybe the problem resulting in the segfault it fixed by now."
10:20 Amarok19: And this is why I'm trying to build it specifically without installing these drivers on my system - to dump it in to a snap as-is and see what good it does
10:30 MrCooper: you can affect where things are installed via meson's prefix or via the DESTDIR environment variable
10:31 Amarok19: OK, I tried with -Dprefix=/tmp/foo
10:32 Amarok19: But I suppose this lack of files is still related to the fact that I never used the `install` keyword, only `ninja -C /build` with no verbs
10:33 Amarok19: Could you elaborate a bit on what this "single *_dri.so" is?
10:33 Amarok19: Is there a single file containing drivers to which all files like for example i965_dri.so *and* i915_dri.so point?
10:37 AndrewR: robclark, hello. I found a bit surprizing referecne to your work on freedreno relative to old ati GPUs: https://trisquel.info/en/forum/so-true-about-amd-trisquel and fast forward into 2020 there was https://cgit.freedesktop.org/mesa/mesa/commit/?id=536f43cb96be91c95f6b4a88dfc8c2ba33dbda4d&utm_source=anzwix
10:37 AndrewR: robclark, I wonder if you can help two other devs in this area?
10:37 MrCooper: Amarok19: exactly, it's called "megadriver"
10:37 MrCooper: (the concept, not the file)
10:40 AndrewR: robclark, https://github.com/artyom-tarasenko/qemu (mostly Sparc emulation) and http://zero.eik.bme.hu/~balaton/qemu/amiga/ (specifically ati emulation in qemu)
10:41 Amarok19: OK, I know next to nothing about drivers but I'm starting to get the feeling that if gdb tells me the segfault occurs in a hard link, the problem is actually in the 'megadriver', so what I'm doing may not even do the trick after all..
10:46 MrCooper: Amarok19: it shouldn't make any difference
10:50 Amarok19: OK, I've got something to work with now!
10:50 Amarok19: As soon as I'm back home, I'll give it a try! Thanks a bunch for help!
11:18 AndrewR: http://allsoftwaresucks.blogspot.com/2016/09/trying-out-and-debugging-open-source.html - a bit old, but still interesting? "As we've seen with libfreenect2 kernels, private address spaces do not work. It is necessary to figure out if they are not supported at all or it is just a simple bug. Until this is resolved it effectively renders a lot of GPGPU applications unusable."
13:45 karolherbst: jekstrand: do you remember why you had to write https://gitlab.freedesktop.org/karolherbst/mesa/-/commit/761a6b2eb2f4ba884c7b251f65fcc8fce423ecbd ?
14:02 jekstrand: karolherbst: I'm not 100% it's needed. It just seemed right
14:02 jenatali: jekstrand, karolherbst: We actually just found a 0.5 that's needed to get correct sampling on some hardware - but it's not there
14:02 jenatali: D3D doesn't support sampling with non-normalized coords, so for point sampling, before dividing by image width we're missing a 0.5
14:04 jekstrand: jenatali: I wondered about that. :-)
14:13 jekstrand: karolherbst: The idea is that when you just do i2f(coord), it's not center-pixel. i2f(coord) + 0.5 is.
14:14 jenatali: airlied: Regarding mul_hi for 8 and 16bit, nir_lower_alu can do it: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6313/diffs?commit_id=9232887c6991151df267d835668c64ba25754240
14:14 karolherbst: ehhh
14:14 karolherbst: basic hostptr sounds annoying :/
14:14 karolherbst: without useptr that is
14:14 karolherbst: *userptr
14:20 karolherbst: even with userptr it's annoing as the things are not PIPE_BUFFER :/
14:23 jekstrand: yeah, we've got userptr so it's pretty easy. I don't know that it's wired up but the kernel side is ther.
14:24 karolherbst: well, we have mmu_notifiers to get the same thing :p
14:24 karolherbst: just annoying as there is still some code not aware of it and relies on a bo being there
14:27 jekstrand: karolherbst: Did you pick up my new type patches I mentioned last night?
14:27 karolherbst: nope, but you didn't push it either
14:27 karolherbst: or maybe you pushed a cuple of times
14:28 karolherbst: dunno :p
14:28 karolherbst: I guess I should rebase on your clover-images branch
14:30 karolherbst: ahhh crap :/
14:31 jekstrand: It totally pushed
14:31 karolherbst: mhh
14:31 karolherbst: yeah.. then the commit just doesn't exist anymore :p
14:31 jekstrand: karolherbst: Oh, the SHA doesn't exist anymore
14:31 jekstrand: be99825051740a924f752b91425d3e3fc505a0cd
14:31 jekstrand: f64d011a992f7336117f43f767d34025046c6145
14:32 jekstrand: 8ee462853ff2bf32fc7fd093fde19b6bcfcaf866
14:32 jekstrand: 65410906ca8437acf4dd8208c97c83d2efe554a0
14:32 karolherbst: I just pull in your clover-image branch :p
14:32 jekstrand: WFM :)
14:32 jekstrand: karolherbst: Anyway, I fixed readimage3d
14:33 karolherbst: cool
14:33 karolherbst: jekstrand: if you want to have fun you can run luxmark4 :p
14:34 jekstrand: karolherbst: Does that require images?
14:34 karolherbst: yeah
14:34 karolherbst: but that's not the problem
14:34 karolherbst: it casts from union to float :)
14:34 karolherbst: I mean.. pointers
14:34 karolherbst: so the deref opt stuff trips over it
14:35 jenatali: For me it just ate all my memory
14:35 jekstrand:is downloading
14:36 karolherbst: jekstrand: it's fun though, the kernels are .. huge
14:36 karolherbst: jekstrand: [01:38] <karolherbst> " vec1 64 ssa_17793 = deref_struct &ssa_17792->field5 (global struct.DecomposedTransform) /* &(*(struct.InterpolatedTransform *)ssa_17789)[0].field5 */" :D
14:36 karolherbst: the spaces are real :p
14:37 karolherbst: ehh
14:37 karolherbst: wait
14:37 karolherbst: IRC eats doule spaces
14:37 karolherbst: https://gist.githubusercontent.com/karolherbst/c2e2792d8ded95ae980ea8a366c46c2d/raw/d6f4247165ac68d73e54fb5ba55a895ab2027c6a/gistfile1.txt
14:37 karolherbst: :p
14:37 jekstrand: karolherbst: Lots of control-flow. :)
14:37 karolherbst: :)
14:37 kisak: test triple spaces
14:37 karolherbst: and lots of ssa values
14:38 karolherbst: I think once luxmarks runs, we have a working OpenCL stack :p
14:38 jekstrand: heh
14:40 jekstrand: karolherbst: What are these unions you're talking about? SPIR-V doesn't have unions.
14:40 karolherbst: well.. the struct was called union
14:40 karolherbst: point was, it casts from a struct to a scalar type
14:41 jekstrand: sure
14:41 karolherbst: and some code expected to be able to get the base type of stuff
14:41 karolherbst: wait.. I can probably trigger it again
14:41 karolherbst: just mess to print as we can't print single instructions :p
14:42 jekstrand: karolherbst: I'm getting shader compile errors when I run luxmark that look like they're coming from clang
14:42 karolherbst: heh...
14:43 karolherbst: you might want to force CL 1.2
14:43 jekstrand: Are there some flags I need to pass?
14:43 karolherbst: CLOVER_DEVICE_VERSION_OVERRIDE=1.2 CLOVER_DEVICE_CLC_VERSION_OVERRIDE=1.2 CLOVER_PLATFORM_VERSION_OVERRIDE=1.2
14:43 karolherbst: anyway, it crashes inside is_vector_bitcast_deref in opt_store_vec_deref
14:44 jekstrand: Now SPIR-V validation is failing
14:44 jekstrand: How do I shut that off?
14:44 karolherbst: uhm.. I guess inside clover.. wait
14:44 karolherbst: https://gitlab.freedesktop.org/karolherbst/mesa/-/commit/daccb7eb2cfefb5ecc176dda3098319a096bae37
14:44 karolherbst: so the rought crash is near the "/* Don't bother with 1-bit types */" check
14:45 karolherbst: parent-type is a struct
14:45 karolherbst: and cast->type is float :)
14:46 karolherbst: I think it is probably easier to write a small CL test to hit this
14:46 karolherbst: but also union casting to float... ugh...
14:52 jekstrand: Ugh... function inlining....
14:53 zmike: question for any dri experts who are around: when I get the first swapbuffers call, there doesn't seem to be any fencing for the pending draws/blits/etc to the surface, so I'm wondering exactly how the driver is supposed to know that it needs to finish the frame in time?
14:54 zmike: I could force a fence wait on the first frame, but this seems like not the most correct solution
14:55 karolherbst: jekstrand: yeah...... I guess we are getting close where function inlining isn't the way to go :/
14:55 jekstrand: karolherbst: It's hard to tell
14:55 jekstrand: karolherbst: Maybe we could do some optimization before function inlining?
14:55 jekstrand: karolherbst: Maybe there's a recursive call?
14:55 karolherbst: mhhh
14:56 karolherbst: maybe
14:56 karolherbst: I wasn't hitting such issues :p
14:56 jekstrand: I didn't think that was allowed in SPIR-V
14:56 karolherbst: I think it's allowed indirectly
14:56 karolherbst: at least in OpenCL C it is
14:56 jenatali: It's not allowed
14:57 karolherbst: jenatali: direct recursion is not allowed
14:57 karolherbst: but you can create cycles
14:57 karolherbst: and runtimes just allow this
14:57 jenatali: karolherbst: We had this discussion a while ago, I thought we found that it's not allowed
14:57 karolherbst: and so applications just use recursion
14:57 karolherbst: jenatali: so? the spec is worthless if everybody ignores it anyway :p
14:58 karolherbst: but yeah.. there shouldn't be
14:58 karolherbst: and I guess we could say it's a bug if we run into it
14:58 karolherbst: but we have 1. llvm which is stupid and might optimize in such a way
14:58 karolherbst: 2. runtimes allowing it and 3. applications just say "hey, it works" and move on :p
15:00 jekstrand: And... gitlab went down
15:00 jekstrand: karolherbst: I've got a fix for opt_deref
15:00 karolherbst: nice
15:00 jekstrand: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7064
15:01 karolherbst: welll....
15:02 karolherbst: yeah, I guess that's fine :p
15:05 MrCooper: zmike: there's generally an implicit flush in SwapBuffers (not with GLX if the context isn't current for the window passed in)
15:06 MrCooper: the swap needs to be synchronized to that flush
15:06 AndrewR: anyone remember how to run piglit's quick driver test?
15:07 Venemo: jekstrand: I changed the GS commit like you asked. can you take a look to see if it's good now?
15:08 zmike: MrCooper: sure, I'm getting that flush (this is with glx), and I'm flushing my queue then, but I'm not specifically stalling/waiting on it at that point
15:08 jekstrand: Venemo: Yeah, in a bit
15:08 Venemo: awesome, thanks jekstrand
15:08 MrCooper: zmike: it should happen automagically due to implicit synchronization
15:08 MrCooper: in the kernel
15:09 zmike: MrCooper: uhhhh define "automagically"
15:10 MrCooper: the kernel keeps the current fence for each BO, and implicitly synchronizes access from other contexts to that
15:11 zmike: hm
15:11 zmike: well I guess it's not being synchronized for this case
15:11 AndrewR: https://pastebin.com/7LM1Kcy1 - for some reason piglit aborts for me ...
15:15 jekstrand: karolherbst: This kernel is... impressive.
15:15 karolherbst: yep
15:15 jekstrand: karolherbst: I genuinely don't see a way to implement it without real function calls.
15:15 karolherbst: yeah...
15:15 karolherbst: it's quite insane
15:16 karolherbst: spilling is one issue, but also overall compexity
15:16 zmike: MrCooper: is there any feasible way to debug/detect that occurring?
15:16 jekstrand: We could try to do a bunch of optimization pre-function-inlining and hope
15:16 karolherbst: nobody sane would be able to debug it :p
15:16 jenatali: jekstrand: I tried that, that's what ate all my memory :P
15:16 karolherbst: maybe
15:16 jekstrand: jenatali: Tried what?
15:16 jenatali: jekstrand: Pre-inlining optimizations
15:17 jekstrand: jenatali: Weird... Did you sweep occasionally?
15:17 jenatali: Pretty sure
15:17 jekstrand: That's even more impressive.
15:18 jenatali: jekstrand: Dunno, maybe my optimization loop is garbage though :P
15:18 AndrewR: ah, it was clinfo returning something strange ....
15:18 MrCooper: zmike: what exactly isn't getting synchronized to the implicit flush?
15:18 zmike: MrCooper: the draw that's happening just prior
15:19 MrCooper: prior to the flush?
15:19 zmike: yea
15:19 MrCooper: I mean, what happens after the flush which doesn't see the result of the commands before the flush
15:19 jekstrand: jenatali: Lots of vec3-as-vecr going on....
15:20 jekstrand: :-(
15:20 jekstrand: *vec3-as-vec4
15:20 jenatali: Awesome :(
15:20 AndrewR: https://pastebin.com/8sZcXfiv - clinfo was busted ...it spills out some of driver config ???
15:20 zmike: MrCooper: well there's the swapbuffers (+flush) happening after the draw, and I'm not seeing the draw show up in the window
15:21 MrCooper: does the GPU work get submitted to the kernel before the flush call returns?
15:21 zmike: yes
15:22 MrCooper: how are the window contents presented? (Xorg with / out compositor or Wayland, ...)
15:22 zmike: composited in xorg
15:23 MrCooper: the compositor uses iris?
15:24 zmike: probably i965? I think that's still the default on fedora
15:24 MrCooper: not in 32 or 33
15:25 zmike: oh
15:25 zmike: well I'm 32, so then I guess it's iris
15:25 MrCooper: anyway, sounds like some kind of issue between anv / zink / kernel / iris so far :)
15:25 zmike: that's a big area
15:26 MrCooper: does calling glFinish before SwapBuffers fix it?
15:27 Thymo: Are the instances where request_firmware won't warn for missing firmware? I just discovered after some debugging that r8169 was missing firmware but never complained about it.
15:28 zmike: MrCooper: yup
15:28 zmike: well, I'm inlining an explicit fence wait into the pipe_context flush since this is a compiled binary that I can't modify
15:28 zmike: but should be the same thing
15:29 MrCooper: sounds like zink / anv isn't properly flushing the GPU work to the kernel before the flush call returns then
15:31 MrCooper: note that the flush may also need to e.g. resolve compression, in the Gallium flush_resource hook
15:33 zmike: huh I hadn't looked into that
15:40 jekstrand: karolherbst: Adding an opt loop maybe helps a bit but it's not enough
15:40 jekstrand: karolherbst: I did find a memory leak in clover though. :)
15:40 karolherbst: nice
15:40 jekstrand: karolherbst: We never delete the nir_shader. :-/
15:41 karolherbst: ufff
15:41 jekstrand:sends a patch
15:42 zmike: MrCooper: the docs on flush_resource are actually a bit light; what exactly is this supposed to be flushing?
15:44 MrCooper: zmike: in a nutshell, it needs to ensure that other contexts accessing the BO can actually see the results of the previously queued drawing commands
15:45 zmike: MrCooper: so this should then wait on any fences corresponding to flushes which include writes to that BO?
15:45 MrCooper: it's not about fences
15:45 MrCooper: it's about things like fast clears / compression / multi-sampling
15:46 MrCooper: which may not be visible to other contexts
15:46 zmike: hm okay so then this would be like a present layout? (I'm trying to relate this back to things I'm more familiar with)
15:46 zmike: or is just "any" read-type layout sufficient
15:47 MrCooper: don't know enough about Vulkan yet to help with that, but could be one of those
15:48 zmike: I'm trying to figure out what "access" means in this context I guess
15:48 zmike: will try playing around with some barriers and see what happens
15:49 zmike: MrCooper: thanks btw, I think I'm on the right path now in some sense
15:50 MrCooper: I hope so, no worries, good luck
15:50 MrCooper: "access" basically means the GPU reading from or drawing to the same BO in a different context
15:51 MrCooper: or possibly even a different device doing so
16:00 danvet_: zmike, with modifiers you should be able to flush a lot less
16:00 danvet_: since then we can allow stuff like compressed buffers as shared buffers and fun stuff like that
16:01 danvet_: without modifiers it's essentially up to each driver what "flushed" means
16:01 danvet_: I think at least, this is just my take with a heavy kernel pov slant to it :-)
16:02 zmike: danvet_: I haven't learned much about the kernel side of things yet, so it's good to get that pov too :)
16:03 danvet_: zmike, well maybe "how should modifiers work" pov
16:03 danvet_: with modifiers there should be a clear layout public layout for that buffer, and that's what you need to flush to
16:04 danvet_: so if rendering is compressed for efficiency reasons, but the modifier isn't, then you need to flush
16:04 danvet_: or if the compression is different (afaik amd has different compression layout for display than rendering) then that needs to be fixed up
16:04 danvet_: or multi sampling resolve
16:05 danvet_: without modifiers I think all drivers go with "resolved and decompressed" as the common state after flush
16:05 zmike: I see
16:06 zmike: I think in this particular case there's no modifiers in play, so I'm just looking at a synchronization issue where the draw isn't complete at the point when swapbuffers presents the surface
16:07 danvet_: zmike, that should be orthogonal
16:07 danvet_: and handled with implicit or explicit fencing
16:07 zmike: right, and so I think that's my issue :)
16:07 danvet_: I think vulkan equivalent is a resolve pass
16:08 danvet_: for the gallium flush thing
16:08 zmike: hm
16:08 danvet_: but it's been a while I looked at that
16:08 danvet_: there's also another flush to get the rendering out somewhere
16:11 danvet_: oh that's just flush
16:17 zmike: right
16:22 karolherbst: danvet_: can you add the nouveau group to https://gitlab.freedesktop.org/drm/nouveau ?
16:23 karolherbst: or add me as a maintainer as well or something :D
16:23 karolherbst: would like to be able to add other people as well to it
16:24 danvet_: karolherbst, how do I add the group again?
16:24 karolherbst: no clue... I just now that the mesa group was added to drm... but no idea if that works for projects
16:24 danvet_: maybe it doesn't work because I'm not in the nouveau group
16:24 danvet_: I'll add you as maintainer
16:25 danvet_: then you can add @nouveau as develoeprs hopefully
16:25 karolherbst: cool thanks :)
16:25 danvet_: pls yell if you can't invite the entire group yourself
16:25 danvet_: because I can do stuff like invite mesa or xorg
16:25 karolherbst: I already added the nouveau group :)
16:25 danvet_: but I'm there already
16:26 danvet_: oh cool
16:26 danvet_: anyway have fun
16:26 karolherbst: thansk!
17:23 jekstrand: dangit airlied, why'd you have to go make that CI? Now I have to update it when I fix bugs. :-P
17:30 ccr: "developer shakes fist at CI cloud"
17:45 jekstrand: Venemo: Much better, thanks! Reviewed.
18:00 chrisf: perhaps just being blind, but how do i change password on the fdo wiki?
18:01 karolherbst: chrisf: ssh
18:05 karolherbst: and probably someone with permission to change that
18:06 karolherbst: chrisf: anyway.. I recommend moving the wiki over to gitlab pages
18:09 karolherbst: I already did so and it's not much work
18:09 karolherbst: and probably less if you just copy&paste whatever I did
18:11 chrisf: karolherbst: i dont have time to move things, im just trying to flush out some old bad passwords
18:13 karolherbst: I don't know who can change your password, but it's some apach2 user database and you need the access to change it :)
18:13 chrisf: i see
18:13 karolherbst: probably daniels can help out
18:13 karolherbst: but I think longterm we should get away from the old wiki server, especially because of that
18:18 Venemo: jekstrand: thanks Jason!
18:18 jekstrand: Venemo: You're welcome. Thanks for your patience.
18:19 Venemo: jekstrand: do you need to get this thru the Intel CI? Asking because some Intel code was touched, though in a trivial way.
18:20 jekstrand: Venemo: It wouldn't hurt
18:21 Venemo: jekstrand: if you feel that it should go there, please be my guest :)
18:21 jekstrand: Venemo: I just kicked it off
18:21 jekstrand: Venemo: Poke me again in an hour or so and I should have results
18:23 Venemo: jekstrand: ok! btw, with the last commit you get the compile-time-known primitive count, too, if you want, all you need is to replace the NULL
18:23 jekstrand: karolherbst: Just for giggles, I tried running geekbench on clover. It's surprisingly non-terribl right up until it crashes on what I think is likely an immediate sampler.
18:24 jekstrand: karolherbst: > 50% of Vulkan perf.
18:24 karolherbst: heh
18:24 karolherbst: not too bad
18:24 jekstrand: karolherbst: Given how quick it is to lower to scratch, that's really not bad.
18:24 jenatali: \o/
18:24 Venemo: btw, speaking of clover, does it work with radeonsi now?
18:24 jekstrand: Venemo: No, but most of the pieces should be there.
18:25 karolherbst: I think I should create an MR for images...
18:25 jekstrand: Venemo: If you've got VK_KHR_buffer_device_address wired through the compiler, that's probably 50%.
18:25 jekstrand: Venemo: Solid 8/16-bit type support is also important
18:25 jekstrand: karolherbst: Getting close to having all the basic image tests passing?
18:25 karolherbst: they already pass, it just the annoying bits which don't
18:26 karolherbst: I don't plan on enabling images yet though
18:26 jekstrand: karolherbst: Which annoying bits?
18:26 karolherbst: just hoping for reviews/comments on some of the more questionable changes
18:26 karolherbst: hostptr
18:26 jekstrand: karolherbst: Oh, that's required for images?
18:26 karolherbst: well....
18:26 karolherbst: CL thinks that images created form USE_HOST_PTR buffers should behave sanely
18:26 karolherbst: so there we are
18:27 jenatali: It doesn't have to actually share the host ptr, but it needs to at least consume the data from it
18:27 karolherbst: jenatali: it also has to write the data back
18:27 jenatali: FWIW CLOn12 just copies back and forth between the app's ptr and a shadow
18:27 jenatali: karolherbst: Yeah, but only on map/unmap boundaries
18:27 karolherbst: and CL allows you to copy between host ptr data, schedule a kernel and then the result should be correct and stuff
18:27 karolherbst: sure
18:27 jekstrand: Yeah, clover makes a lot of assumptions about the way transfer ops work.
18:27 jekstrand: We really need a u_blitter equivalent for clover
18:27 karolherbst: jenatali: we have that in clover as well, but that's a bit broken
18:29 Venemo: jekstrand: I thought radeonsi has all of that
18:29 jekstrand: Venemo: It probably does
18:29 jekstrand: Venemo: I expect wiring clover up on radeonsi is probably less than a dozen patches.
18:30 jekstrand: You have to expose a few more caps and handle a couple more state setup entrypoings.
18:30 jekstrand: It's really not bad
18:30 Venemo: mhm
18:30 karolherbst: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7069
18:30 karolherbst: should clean up some stuff though...
18:31 Venemo: maybe it's worth doing. so many people inquire about opencl on amd
18:31 karolherbst: well.. if somebody goes ahead and wires it up :p
18:31 karolherbst: although the person will run into the bikeshedding discussion of llvm vs nir backend :p
18:32 Venemo: what about it?
18:32 jekstrand:is still very confused as to why integer coordinates are allowed with sampling.
18:33 karolherbst: jekstrand: feel free to fix up some of your commits there as well :p
18:34 karolherbst: but I also expect some of them to break vulkan or gl.. mhh.. no clue
18:34 karolherbst: or maybe they are all fine
18:38 jenatali: jekstrand: You can also use float non-normalized coords... is the expectation there that the app better just use a coordinate that points to the center of a texel?
18:41 jekstrand: jenatali: Yes, I believe so.
18:42 pmoreau: It would be nice to have a version check for libclc: it took me a bit to figure out why clinfo was no longer listing any devices on this laptop despite setting all the proper env vars.
18:43 karolherbst: pmoreau: we already talked about bumping libclcs version and require that one :p
18:43 pmoreau: Yeah, I saw it in the logs
18:43 pmoreau: Where do I get the source for libclc? The link they have on their website gives me a 404.
18:43 karolherbst: oh wow
18:43 karolherbst: git rebase output is now useful
18:43 karolherbst: "dropping c67eac57b8bc5f83024ba91a1aa8dc1465b5d625 nir/opt_deref: Fix the vector bitcast optimization -- patch contents already upstream"
18:43 karolherbst: nice
18:44 pmoreau: Neat!
18:46 jenatali: pmoreau: libclc is part of the LLVM monorepo
18:47 pmoreau: karolherbst: Do I need a particular branch of libclc, or can I use the current master?
18:47 pmoreau: jenatali: Thanks!
18:47 jenatali: pmoreau: Current master has all the SPIR-V patches
18:47 pmoreau: Perfect!
18:49 jekstrand: karolherbst: Over-all, that branch looks pretty good IMO
18:49 karolherbst: jekstrand: naturally you'd say that as most of the patches are from you :p
18:50 jekstrand: karolherbst: hehe
18:50 jekstrand: karolherbst: I'm very happy about not using set_compute_resources. :-)
18:51 jekstrand: jenatali: Do you have an immutable sampler deduplication pass?
18:51 jenatali: jekstrand: Yeah, though it's a bit naive, probably could use some improvements like a hash table or something
18:51 jenatali: One sec
18:51 jenatali: jekstrand: https://gitlab.freedesktop.org/kusma/mesa/-/blob/msclc-d3d12/src/microsoft/clc/clc_nir.c#L358
18:52 karolherbst: jekstrand: btw, luxmark-3 hits the constant sampler
18:52 jenatali: jekstrand: Oh, hold on, that hasn't had the image reworks from upstream landed yet, let me find that
18:53 jenatali: jekstrand: https://gitlab.freedesktop.org/kusma/mesa/-/blob/c0d866afb1215d26d565b81145b21cd233c4e6a4/src/microsoft/clc/clc_nir.c#L358
18:55 jekstrand: jenatali: Yeah, it wouldn't be too hard to write a quick pair of hash/compare functions and throw in a hash set
18:55 jenatali: The linear search might be okay depending on how many uniforms you have, but yeah, either way
18:56 jekstrand: jenatali: In any case, we should pull that into core NIR and share it.
18:56 jekstrand: With or without the linear search
18:56 jenatali: jekstrand: Yep, sounds good
19:02 jekstrand: karolherbst: Does clover have support for read/write images yet?
19:02 jekstrand: karolherbst: I only see image_rd_argument and image_wr_argument
19:02 karolherbst: uhhh... no idea?
19:02 karolherbst: is this an optional thing?
19:02 karolherbst: is this some 1.2 or 2.0 thing?
19:03 jekstrand: karolherbst: It's definitely in 2.0
19:03 jekstrand: karolherbst: It may be an extension on older versions
19:03 jekstrand: But it's definitely not required by core 1.2
19:03 karolherbst: mhhh
19:03 karolherbst: looking at bind_surface
19:03 karolherbst: clover called it with rw = true
19:03 karolherbst: which created a surface being writeable.. mhh
19:03 jenatali: It's optional in 1.2
19:04 karolherbst: jenatali: how is it declared btw?
19:04 jekstrand: karolherbst: I think it's declared in the shader
19:04 jenatali: karolherbst: readwrite attribute on the image in the kernel
19:04 jenatali: No attribute is read-only, and then write-only and read-write need to be explicitly specified
19:05 jekstrand: karolherbst: convert_image_type in spirv/invocation.cpp
19:09 jekstrand: karolherbst: If we want r/w support, we probably want a new module::argument type for it
19:09 jekstrand: At least that's the way it seems based on how clover is currently architected
19:20 pcercuei: What is the unit for the hdisplay / hsync_start / htotal etc. fields of struct drm_display_mode?
19:21 pcercuei: Is it counted in pixels, or in clock ticks?
19:21 karolherbst: jekstrand: makes sense
19:26 anarsoul: pcercuei: I believe it's in pixel clock ticks, i.e. in pixels
19:28 pcercuei: anarsoul: alright, thanks
19:30 karolherbst: mhh "ERROR: Unable to get list of supported image formats!" :/
19:31 karolherbst: ehh wait
19:31 karolherbst: that's that r_count vs count patch...
19:32 karolherbst: or something else?
19:32 pmoreau: karolherbst and EdB_: I did a quick update to the OpenCL status (https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4979); I have not included things in pending MRs or sitting in branches. Feedback welcome
19:32 pmoreau: Is printf the only missing thing for OpenCL 1.2?
19:35 Venemo: jekstrand: ping, how'd the ci turn out?
19:35 jekstrand: Venemo: One more BDW has yet to finish
19:36 jekstrand: Should be any minute now. Vulkan was ok
19:36 karolherbst: mhh 1d images...
19:55 karolherbst: jekstrand: now that branch explodes :D
19:55 jekstrand: karolherbst: ?
19:56 karolherbst: you'll see in a moment
19:56 karolherbst: pushed :p
19:57 karolherbst: wondering if there are more good commits on some magic branch around somewhere :D
19:57 karolherbst: insane how that works though
19:58 karolherbst: and I should probably clean those commits up, they are partly a bit messy
19:58 jekstrand: karolherbst: Did you mean PIPE_IMAGE_ACCESS_WRITE? You used ACCESS_READ. :-)
19:58 karolherbst: ahh yeah...
19:58 karolherbst: it seems like it doesn't matter for nouveau
20:00 airlied: pmoreau: yeah i think printf might be the main thing left and pzssing cts
20:00 airlied: jekstrand: where did generic ptrs grt to.
20:01 airlied: ?
20:01 pmoreau: airlied: Got it, thanks!
20:01 jekstrand: airlied: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6332
20:02 jekstrand: airlied: One second while I give it a quick rebase (it almost never rebases clean)
20:03 karolherbst: "PASSED 370 of 370 sub-tests." noice
20:03 jenatali: karolherbst: Which test is that?
20:03 karolherbst: cl_get_info
20:03 karolherbst: ./build/test_conformance/images/clGetInfo/test_cl_get_info to be precise
20:03 jenatali: Ah cool
20:04 airlied: pmoreau: we should just pile on to cl 3.0, though i think it might be challenging for khronos open source conformance policy
20:04 karolherbst: I am quite lucky I didn't have to write those patches :D
20:04 airlied: to get 3.0 conformance proper
20:04 jekstrand: airlied: Why? Does the X.org agreement not apply to CL?
20:05 pmoreau: It should
20:05 jekstrand: But, yeah, we should go straight for 3.0
20:05 airlied: i think the agreement is free only if someoene has paid already at that lvl for that hw
20:05 karolherbst: mhhh
20:05 karolherbst: image arrays are a bit borked
20:05 jekstrand: airlied: Ah
20:06 karolherbst: "FAILED 222 of 370 sub-tests."
20:06 karolherbst: ./build/test_conformance/images/clReadWriteImage/test_cl_read_write_images
20:06 airlied: like im sure there is soke negotation to be had :-p
20:06 karolherbst: 1D also a bit broken
20:06 jekstrand: airlied: MR rebased
20:06 jenatali: airlied: We've paid for 3.0, FYI
20:07 jenatali: Not sure if we count in any way that matters
20:07 karolherbst: ehhh
20:07 karolherbst: jekstrand: image_deref_format :/ we need to handle that one somehow as well :p
20:07 jekstrand: airlied: I don't expect it'll take long for 3.0 conformance results to come in from NV and AMD.
20:07 karolherbst: ehh wait...
20:07 jenatali: karolherbst: We ended up supporting that one by putting it in the kernel args
20:07 karolherbst: mhhh
20:08 jenatali: karolherbst: We have a lowering pass that converts that instruction into just a load_kernel_input
20:08 karolherbst: yeah.. maybe that's for the best
20:08 karolherbst: right..
20:08 karolherbst: clover already supports that
20:08 karolherbst: mhhh
20:08 karolherbst: yeah.. I think I should do that
20:09 karolherbst: for image_size as well
20:09 pmoreau: Wasn’t there some (semi-)recent discussion that we could submit CTS results even if the vendor had not? IIRC it meant we could send CTS results for Nouveau for OpenCL 2.0+ even if NVIDIA had not.
20:09 karolherbst: yeah.. I think we talked about it somewhere with someone
20:09 karolherbst: I am quite sure to know where and who though :p
20:09 karolherbst: maybe I should write an email :D
20:11 jekstrand: karolherbst: Yeah, clovers uses 8 bytes for images. I'm not sure what they store in those 8 bytes.
20:12 jekstrand: But I'm guessing the channel order and format are in there somewhere
20:20 airlied: pmoreau: yeah not sure if that discussion concluded though
20:20 karolherbst: mhh
20:20 karolherbst: are 1D images 2.0+?
20:21 jenatali: karolherbst: No?
20:21 pmoreau: 1.2
20:21 karolherbst: mhh
20:21 karolherbst: "TEST skipped, Opencl 2.0 + requried for this test1D passed"
20:21 jenatali: Uh..
20:21 karolherbst: maybe that test does something special
20:21 karolherbst: ./build/test_conformance/images/kernel_read_write/test_image_streams
20:21 jenatali: Is it read-write?
20:21 karolherbst: yeah
20:21 pmoreau: 1D, 1D buffer, 2D array were introduced in 1.2.
20:22 jenatali: pmoreau: Isn't 3D also made required by 1.2? Or was that earlier?
20:22 pmoreau: cl_khr_3d_image_writes was made core in 2.0
20:22 jenatali: Right, writes
20:23 pmoreau: And 3D was introduced prior to 1.2, but I am not sure whether it was mandatory or not
20:23 jenatali: I thought 3D at all was an extension at one point, maybe I'm misremembering
20:24 karolherbst: anyway.. the branch already improves most of the image support by a lot :O
20:25 pmoreau: It looks like CL_MEM_OBJECT_IMAGE3D has been there since 1.0, similar to the 2D version.
20:25 jenatali: Ah cool
20:26 pmoreau: Though of course it is only supported if the device sets CL_DEVICE_IMAGE_SUPPORT.
20:26 pmoreau: karolherbst: Very nice!
20:27 karolherbst: jenatali: do you know if the CTS tests constant samplers?
20:28 jenatali: karolherbst: There's a command line flag for it... but I don't think the conformance playlists use that flag
20:28 karolherbst: gimme :p
20:28 karolherbst: what test and what flag?
20:29 jenatali: karolherbst: test_image_streams local_samplers
20:29 karolherbst: ahh
20:29 karolherbst: cool thanks
20:29 karolherbst: nice, it crashes :)
20:30 pmoreau: \o/
20:40 Venemo: jekstrand: 'sup?
20:46 airlied: jenatali: just not sure I wanted to lower the 32/64-bit versions alwas
20:46 jekstrand: Venemo: Looks good to CI
20:46 airlied: or at least the 32-bit version
20:46 jenatali: airlied: Ah, sure
20:47 jenatali: Seems like that should be hooked up to nir_lower_bit_size or something
20:48 airlied: but I can do the 8/16 bit lowering in my backend anyways
21:10 karolherbst: jenatali: are you already working on upstreaming the dedup pass or should I just copy whatever you have? I will probably focus on the runtimes bits for now and leave the duplicates alone for now though
21:10 jenatali: karolherbst: I haven't started on it yet, no, feel free to grab it
21:10 karolherbst: okay
21:10 jenatali: But yeah you can probably get pretty far just letting it duplicate
21:14 karolherbst: what surprises me the most is that I don't have to do anything about those weirdo clamp modes :D
21:14 karolherbst: seems like gallium does support those already
21:14 jenatali: Weirdo? Aren't they standard?
21:14 karolherbst: no idea?
21:15 karolherbst: didn't know that OpenGL apparently has that stuff as well
21:15 airlied:assumes all the clamp modes are just GL ones
21:16 jenatali: CL doesn't even have mirror
21:23 Venemo: jekstrand: great! :)
21:24 karolherbst: mhhh
21:24 karolherbst: what confuses me a bit is how those sampler args even work...
21:24 jekstrand: karolherbst: ?
21:24 karolherbst: I mean.. how does the multiple sample, same read image work?
21:25 karolherbst: I don't really see how that pans out at runtime
21:25 jekstrand:is confused
21:26 karolherbst: ohhh..
21:26 karolherbst: mhhh
21:26 karolherbst: we iterate the vars and just set the constant index
21:26 karolherbst: okay..
21:26 karolherbst: and I guess indirects are not allowed?
21:27 karolherbst: mhh
21:27 jenatali: No, indirects aren't allowed
21:28 karolherbst: wondering if the CTS has tests with multiple samplers as well :D
21:29 jenatali: Hm... not sure about that
21:30 karolherbst: oh well.. seems like we do support indirects already given that jekstrand handles it in the lowering pass
21:30 karolherbst: but I suspect we could hit them in weird cases anyway
21:30 karolherbst: at least I remember that being a result from a discussion we had
21:30 karolherbst: okay..
21:33 jekstrand: Yeah, I think we should be mostly ready for them
21:33 jekstrand: If they're ever a thing
21:34 karolherbst: yeah, the code looks fine :) Now I just have to do the ugly part of pulling them out...
21:34 karolherbst: wondering how that works on the LLVM side...
21:34 karolherbst: probably not at all
21:36 karolherbst: jekstrand: I think the best idea would be to just place them last in the variable list, do the lowering and just bind them after the API provide one
21:36 karolherbst: any other ideas?
21:36 jekstrand: karolherbst: For immutable samplers? Seems reasonable.
21:37 karolherbst: mhh.. I think that is best done inside clover_lower_nir as it messes with the arguments already anyway :D
21:37 karolherbst: and lower_images just picks it up
21:37 karolherbst: mhhh
21:37 karolherbst: I think we might want to start pulling out those passes into their own files..
21:37 karolherbst: feels a bit crowded now
21:39 karolherbst: okay.. but today is too late for that :D
21:47 jenatali: karolherbst: That's pretty much exactly what we do for the record, add the inline samplers to the end of the kernel args
21:47 karolherbst: yeah... but we don't really have storage for those :p
21:47 karolherbst: it's all runtime
21:48 karolherbst: ohh.. lower_images adjusts driver_location already :O
21:48 karolherbst: this will be soo simple then
22:01 mareko: krh: I don't remember what I reviewed last night, but I didn't look at any freedreno commits if that's what you're asking
22:05 krh: mareko: roger
22:07 alyssa: Looking at https://docs.mesa3d.org/release-calendar.html
22:07 alyssa: When is the next branch point expected?
22:07 alyssa: (For a feature release)
22:10 jekstrand: dcbaker: ^^
22:11 dcbaker[m]: that's a really good question
22:11 dcbaker[m]: also, why haven't I merged the updated calender for the 20.2 release series?
22:11 alyssa: dcbaker[m]: Not looking for anything precise, just roughly, are we expecting a release before the end of the year?
22:12 alyssa: Trying to calculate roughly how stressed to be going into finals ;)
22:12 jekstrand: alyssa: Typically, we have 4 releases per year, so yes there should be another.
22:12 jekstrand: Probably branching soon, I'd think.
22:12 dcbaker[m]: IIRC the .0 usually lands around the US thanksgiving holiday
22:12 alyssa: jekstrand: Yeah, but it's 2020.
22:12 dcbaker[m]: (end of November)
22:13 dcbaker[m]: Don't tempt 2020
22:13 alyssa: Indeed.
22:16 ccr: dun dun duuunn
22:26 tuxd3v: hello guys
22:26 tuxd3v: I am trying to build Clover mesa driver for amd64
22:26 tuxd3v: I am issuing:
22:26 tuxd3v: meson build/ --buildtype release --prefix=/opt/build --libdir=lib/x86_64-linux-gnu -Dgallium-drivers=auto,swrast -Dopencl-spirv=true -Dgallium-opencl=standalone -Dgallium-xa=auto -Dgallium-va=auto -Dplatforms=x11,drm,surfaceless -Dvulkan-drivers= -Ddri-drivers= -Dllvm=false
22:27 tuxd3v: but I get a error:
22:27 tuxd3v: meson_options.txt:45:0: ERROR: Options "" are not in allowed choices: "auto, i915, i965, r100, r200, nouveau, swrast"
22:27 tuxd3v: can anybody help?
22:27 tuxd3v: thanks in advance
22:30 tuxd3v: I forgot, I have amd rx580 cards, and also a amd r7 card
22:34 kisak: I think that's "-Ddri-drivers=" biting you
22:36 jekstrand: specifying auto plus other stuff probably doesn't work
22:36 Kayden: sounds like it, though that's surprising, it should definitely be allowed to do an empty list there
22:37 Kayden: and yeah, auto + stuff is not what you want
22:37 Kayden: generally auto is the default
22:37 Kayden: or you specify something that you want
22:43 dcbaker[m]: tuxd3v: are you using an old version of meson?
22:43 dcbaker[m]: try -Ddri-drivers=[] instead
22:48 karolherbst: jekstrand: what would be the best way to reorder uniforms? :/
22:48 karolherbst: that really feels messy to do
22:48 jekstrand: karolherbst: You don't really have to
22:48 jekstrand: I mean, you can
22:48 jekstrand: Just exec_node_remove and exec_list_push_tail
22:49 karolherbst: any better ideas?
22:49 karolherbst: my current plan was to bind those last
22:49 tuxd3v: dcbaker[m], yeah I believe so :(
22:49 tuxd3v: 0.45.1
22:49 jekstrand: karolherbst: In theory, actual argument order should be determined by location
22:49 karolherbst: ahh
22:49 jekstrand: karolherbst: In practice, I think we assume they're sorted by location
22:50 jekstrand: So that may not be good enough. :-/
22:50 karolherbst: mhhh
22:51 jekstrand: karolherbst: Maybe a tiny NIR pass which throws them all in an array, qsorts by location, and then puts them back in the list?
22:51 karolherbst: mhhh
22:52 tuxd3v: kisak, what should I choose, that is the problem :)
22:53 kisak: anything that you enable that's not your hardware is only a minor time loss in compile time. There literally is no wrong answer there
22:53 kisak: it doesn't hurt to enable everything x86 hardware can use
22:55 tuxd3v: game over :(
22:55 tuxd3v: meson.build:21:0: ERROR: Meson version is 0.45.1 but project requires >= 0.52.
22:57 tuxd3v: I am on ubuntu bionic
22:58 tuxd3v: the backprts version of meson is the same as in the main
22:59 jekstrand: tuxd3v: Just pull meson from git
22:59 jekstrand: tuxd3v: You can run it straight from the repo without installing
23:03 dcbaker[m]: or if you have pip you can do `pip install --user meson`, just make sure ~/.local/bin is in your path
23:04 dcbaker[m]: on debian it might be pip3, actually
23:05 tuxd3v: I got meson from github, but runned meson.py
23:08 tuxd3v: I am now with:
23:08 tuxd3v: meson.build:874:0: ERROR: <ExternalProgram 'python3' -> ['/usr/bin/python3']> is not a valid python or it is missing setuptools
23:09 tuxd3v: /opt/meson-0.55.3/meson.py build/ --buildtype release --prefix=/opt/build --libdir=lib/x86_64-linux-gnu -Dgallium-drivers=swrast -Dopencl-spirv=true -Dgallium-opencl=standalone -Dgallium-xa=auto -Dgallium-va=auto -Dplatforms=x11 -Dvulkan-drivers=[] -Ddri-drivers=[] -Dllvm=false
23:10 tuxd3v: Python 3.6.9
23:12 tuxd3v: 'it is missing setuptools' --> what is setuptools?
23:12 dcbaker[m]: apt install python3-setuptools
23:12 dcbaker[m]: it's the de facto build system for python
23:13 dcbaker[m]: most linux distros (and the python for windows build) install it by default. Debian/Ubuntu doesn't for some reason
23:13 tuxd3v: thanks that did the trick :)
23:13 tuxd3v: another error o.O
23:13 tuxd3v: meson.build:1549:2: ERROR: Problem encountered: The OpenCL "Clover" state tracker requires LLVM, but LLVM is disabled.
23:14 dcbaker[m]: you can try adding -Dllvm=true to your configuration
23:14 dcbaker[m]: you may be missing llvm-dev though
23:14 dcbaker[m]: (I think llvm defaults to auto)
23:17 tuxd3v: ERROR: Dependency "SPIRV-Tools" not found, tried pkgconfig
23:17 tuxd3v: another one :S
23:21 airlied: tuxd3v: you need a lot of deops that aren't packaged if you want to run the NIR paths in the opencl stuff
23:21 airlied: I doubt whatever you want exists yet
23:21 tuxd3v: I wanted to try OpenCL with Clover driver :)
23:22 airlied: which clover driver though
23:22 tuxd3v: on amd cards :)
23:22 airlied: the amd card support is the same as it ever was
23:22 airlied: no spirv suppoer yet
23:22 tuxd3v: mesa
23:22 airlied: ro -Dopencl-spirv=true isn't needed for amd gpu
23:23 kisak: in general, you're probably looking for oibaf's PPA
23:23 karolherbst: inline sampler are annoying :D
23:24 karolherbst: jekstrand: ehh.. I think I need to add a new section type to clover::module....
23:27 airlied: jekstrand: ./bin/cl-program-tester ./generated_tests/cl/builtin/math/builtin-float-fmax-1.0.generated.cl
23:27 airlied: pass or fail?
23:31 tuxd3v: airlied, I was trying master branch from mesa, that landed support for OpenCL 1.2 in clover
23:31 tuxd3v: and I was trying to build Clover, to test it :)
23:31 airlied: it doesn't advertise 1.2 yet
23:32 airlied: since it's still missing printf support
23:32 tuxd3v: yeah, but even so, that was the idea :)
23:33 airlied: tuxd3v: in that case you need llvm and you don't need opencl=spirv
23:33 airlied: jekstrand, jekstrand, karolherbst : were other drivers going to implement fisnormal?
23:34 tuxd3v: yes I enabled it, thanks :)
23:34 airlied: and do we need fisnormal32 for bool->32 bit loewring
23:34 karolherbst: airlied: I think the plan was to add unordered comparisons first :p
23:34 karolherbst: but I guess we want to always lower it
23:35 tuxd3v: now it just fails in this dependency : dep_elf = cc.find_library('elf')
23:35 airlied: tuxd3v: libelf devel packages needed
23:35 airlied: karolherbst: okay I'll let unord happen first then
23:36 karolherbst: although not sure if it helps with isnormal...
23:36 airlied: I might need 32-bit variants of those for bool lowering if the backend is expected to handle it
23:36 karolherbst: I never had a good overview of those helpers
23:40 tuxd3v: this is the summary of meson:
23:40 tuxd3v: https://paste.debian.net/1166433/
23:41 airlied: tuxd3v: you need gallium-drivers=radeonsi,swrast
23:41 airlied: if you want to run on the gpu
23:42 tuxd3v: I am trying now with:
23:42 tuxd3v: radeonsi,
23:42 tuxd3v: /opt/meson-0.55.3/meson.py build/ --buildtype release --prefix=/opt/build --libdir=lib/x86_64-linux-gnu -Dgallium-drivers=radeonsi,swrast -Dgallium-opencl=standalone -Dplatforms=x11 -Dvulkan-drivers= -Ddri-drivers= -Dllvm=true