00:05 karolherbst: dcbaker[m]: I bet the first answer will be "use include! and an env var" :p
00:05 dcbaker[m]: lol, yeah
00:22 dcbaker[m]: PSA: sorry mesa people, I just pushed the 20.3 branchpoint. now that I think about it I think that messes up marge
00:28 jenatali: Doesn't look like marge was in the middle of anything
00:28 dcbaker[m]: lucky me :)
00:29 kisak: dcbaker[m]: congrats, you've disrupted a total of 0 merge requests https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests?scope=all&utf8=%E2%9C%93&state=opened&assignee_username=marge-bot
00:29 dcbaker[m]: \o/ something is working right for me today!
00:39 karolherbst: nice
00:41 karolherbst: I also managed to do some progress today: https://gist.githubusercontent.com/karolherbst/08cb1379598eccaf8359ce77f9c9230d/raw/5460f6eefacdf8981ea06796dc7944e141949457/gistfile1.txt :)
00:41 karolherbst: boilerplate code is annoying to write
00:43 karolherbst: airlied: I think I am just using your name suggestion now :D
00:53 karolherbst: dcbaker[m]: ohh.. I think rust_flags don't work either
00:53 karolherbst: tried to add "--color=always"
00:53 karolherbst: but doesn't get added to the invocation
00:54 dcbaker[m]: I think meson controls --color, I think there's like b_colorout or something like that
00:54 karolherbst: doesn't work either
00:54 dcbaker[m]: okay, I'll look at that too
00:54 karolherbst: b_colorout is set to always here :)
00:54 karolherbst: thanks
00:56 airlied: karolherbst: nice!
01:15 karolherbst: nooooo :/
01:15 karolherbst: that C hack with the NUM_* whatever enum field is quite annoying now :/
01:34 karolherbst: CL_DEVICE_AVAILABLE ehh.... what a pointless thing :D
02:00 airlied: pmoreau: I cleaned up your versioning changes, in 7520 now
02:08 karolherbst: ufff
02:09 karolherbst: rust is quite powerful, but the documentation sucks
02:32 karolherbst: airlied: :p https://gitlab.freedesktop.org/karolherbst/mesa/-/blob/fbe28e902458cd6efbc94c4085cf8e925f28adf7/src/gallium/frontends/rusticl/core/version.rs
02:33 karolherbst: somehow I get the feeling that whatever we do in clover, it's always overcomplicated
02:35 karolherbst: uhhh.. that cl_name_version thing will also be slightly annoying.. oh well
02:44 karolherbst: uhhhh
02:44 karolherbst: get_compute_param :/
02:44 karolherbst: this terrible interface again :/
02:55 soreau: There is wf-recorder screen recorder for wayland compositors and it supports vaapi via libav. Intel drivers happily allow RGB data and converts automatically to YUV but the gallium drivers just crash when fed RGB data as they expect YUV. So, I wrote an opencl shader to do the RGB>YUV conversion on the gpu and it saves cpu cycles compared to doing the conversion on the cpu but I was asked, 'why not do the conversion with a compute shader instead of
02:55 soreau: opencl?'..
02:55 soreau: The best answer I have is that libav is already using the render node (and there's no way to access the context that I know of) so I'd have to context switch on each frame, which is avoided by using opencl
02:56 karolherbst: soreau: why would it avoid context switches?
02:56 soreau: karolherbst: well that's kind of my question
02:57 karolherbst: GL compute shaders and OpenCL kernels are really executed on the same thing
02:58 soreau: karolherbst: but for instance, I have no problem setting up opencl while libav has a context setup for the render node but trying to setup another context in the same thread fails so I can only do it in a thread
02:59 karolherbst: ohh, you mean contexts on the CPU.. mhh
02:59 karolherbst: yeah...
02:59 karolherbst: mhhh
02:59 karolherbst: I guess if you have two OpenGL contexts they would fight each other quite a lot...
02:59 soreau: yes
02:59 soreau: which makes me think that libav should have some way to share its context but that's besides the point..
03:00 karolherbst: although... depends on the driver
03:00 karolherbst: for intel with their external VA thing it might not matter
03:00 karolherbst: dunno
03:00 karolherbst: but for mesa drivers, yes
03:00 soreau: karolherbst: what depends on the driver?
03:01 karolherbst: depends on how much is shared
03:01 soreau: huh
03:01 karolherbst: but anyway, if you have two OpenGL contexts from the same driver, then yes.. you kind of have some context switching going on
03:02 soreau: karolherbst: however, compared to opencl..?
03:02 karolherbst: well, the point is, you usually end up with two different stacks
03:02 soreau: I can use opencl in the same thread without any explicit switching
03:02 karolherbst: but what if both sides are from mesa?
03:02 karolherbst: same situation then
03:02 karolherbst: (a little)
03:02 karolherbst: details are different as we share less between contexts than we do with GL
03:03 karolherbst: soreau: well, for the driver it just looks like two different applications then
03:03 soreau: Ultimately I'd like to have a compute shader that runs with the same context but after fiddling with it a bit, I'm not sure how
03:03 soreau: karolherbst: but the cost is when the application switches contexts, right?
03:03 karolherbst: sure, normal threading stuff
03:05 soreau: well s/I'm not sure how/I made glsl compute work only in a separate thread with explicit context switching and it drags everything down to like 1FPS
03:05 karolherbst: mhhh
03:05 soreau: not like I expected it to be fast, but that's the only way I could get it working at all
03:06 karolherbst: yeah.. I don't think you want to have a second context, as switching can lead to some weird syncing
03:07 karolherbst: the assumption is somehow that there will be one rendering thread doing the real work and several helper threads doing streaming (if you multithread OpenGL)
03:07 karolherbst: but if you start doing real work on several threads then I guess that;s something mesa is not opitmized for
03:07 karolherbst: maybe
03:08 karolherbst: and it's potentially also very difficutly to get right
03:09 soreau: but if I could get the libva context and do everything on the same thread, compute might possibly perform as good as what I have now without opencl
03:09 karolherbst: probably
03:09 karolherbst: or dlopen libGL again and just make it look like a second application :D
03:09 soreau: and it's slightly annoying that the gallium driver doesn't accept RGB data and just handle this like intel, but that's another story too
03:10 soreau: karolherbst :D
03:15 dcbaker[m]: karolherbst: you win the prize
03:18 karolherbst: dcbaker[m]: :)
03:18 karolherbst: I mean, that was kind of expected :D
03:19 dcbaker[m]: Of course they didn't really read the question before answering, lol
03:20 karolherbst: well... env vars you can point to random locations
03:20 karolherbst: :p
03:21 karolherbst: could probably do "include!(env!("MY_AWESOM_GENERATED_FILE"))"
03:21 karolherbst: and have an absolute path
03:24 dcbaker[m]: For meson though the problem is more basic than that. We always put generated stuff in build, never in source. In fact, several OSes make the source tree read only
03:24 karolherbst: I don't see the problem with that
03:24 karolherbst: so you have your file inside your source tree doing the include
03:24 karolherbst: and the env var points to a file inside your build directory
03:24 karolherbst: doesn't matter where it is
03:25 dcbaker[m]: What if the generated file is a .rs file
03:25 karolherbst: it's included
03:25 karolherbst: works just as a normal CPP include
03:25 karolherbst: just that the path is read from env
03:25 karolherbst: and can be relative and absolute
03:26 dcbaker[m]: But what they suggested was "use OUT_DIR like cargo", which site sounds like "write into the source dir"
03:26 karolherbst: relative doesn't help, as you would have to calculate the path relative to the source rs root
03:26 karolherbst: no
03:26 karolherbst: OUT_DIR points somewhere inside the build dir
03:27 karolherbst: $ find . -iname cl-bindings.rs
03:27 karolherbst: ./target/debug/build/rustcl-65ab7743d60d3981/out/cl-bindings.rs
03:27 karolherbst: and this is my include statement: include!(concat!(env!("OUT_DIR"), "/cl-bindings.rs"));
03:29 dcbaker[m]: That works in the case of include, but what about `use foo`?
03:29 dcbaker[m]: If foo or some part of foo is generated
03:29 karolherbst: it's included in the rs file
03:29 karolherbst: so I have it at src/api/bindings.rs
03:30 karolherbst: and I can just use it like this: use crate::api::bindings::*;
03:30 karolherbst: and as the cl-bindings.rs stuff is included in src/api/bindings.rs, this just works
03:31 karolherbst: of course you can't use the file directly
03:31 karolherbst: but...
03:31 karolherbst: even the doc say you should use include!
03:32 karolherbst: but I agree that maybe you just want to place the file somewhere and use it directly, but... I doubt anybody does it
03:32 karolherbst: and it wouldn't work with cargo anyway
03:34 dcbaker[m]: What I'd really like is something more like a -I option, where I can pass multiple folders together. The thing is cargo doesn't use it, but cmake, meson, autoconf, etc would have use for it
03:34 karolherbst: yeah...
03:35 dcbaker[m]: For bindgen you want include
03:35 karolherbst: but I think it's more of a design decision where you have this root file and everything gets added from there
03:35 dcbaker[m]: But imagine if you just wanted to do something like configure_file for a version
03:35 karolherbst: include! ?
03:35 karolherbst: :D
03:36 dcbaker[m]: I guess that's what you'd have to do in every case. Of course, meson would want to populate the include with a configure_file
03:36 karolherbst: dcbaker[m]: apparently cargo dumps that stuff into env vars
03:37 dcbaker[m]: Yay infinite recursion
03:37 karolherbst: CARGO_PKG_VERSION and stuff :)
03:37 dcbaker[m]: Yeah. I'm hoping maybe they might take a --env option
03:38 karolherbst: mhh, that might be good enough indeed
03:38 dcbaker[m]: Because otherwise rust is going to require a wrapper
03:38 dcbaker[m]: And that stinks for performance
03:38 karolherbst: well
03:38 karolherbst: you only execture rustc once anyway
03:38 karolherbst: *execute
03:39 karolherbst: so it wouldn't be _that_ terrible
03:40 dcbaker[m]: Still, id rather not have to wrap it
03:40 karolherbst: yeah, me as well
03:57 karolherbst: oh wow... get_compute_param needs at least three unsafe blocks :/
03:58 karolherbst: anyway.. getting late :D
04:27 airlied: oh quite close to vk 1.0 cts for lavapipe
08:16 DaRock: hey guys
08:19 DaRock: there's a lot of conusing/conflicting info on the rpi situation both armv and aarch64 - can someone provide a definitive link/answer on what is available now and what will be available when vis a vis rpi versions?
08:28 airlied: bnieuwenhuizen: amd next is merged to drm-next now, so probably time to go find out where modifiers are broken :-P
09:06 kusma: So, when can I merge that D3D12 driver? IIRC, in the past I think the "consensus" has been that new drivers don't really need reviews, as long as they don't touch other drivers. The few commits in that MR that aren't vendor/driver specific here has all been reviewed, all that's missing review is "internal" support-code. And that code was all reviewed internally by Microsoft and Collabora while developing
09:06 kusma: it...
09:07 kusma: The reason I'm a big trigger-happy here, is we have more MRs to stack on top, like a DXGI-winsys, CI-bits, the CLC compiler API etc
09:13 MrCooper: dcbaker[m]: looks like you pushed some unrelated tags (from chadv?) along with the 20.3 branchpoint one
09:27 tzimmermann: danvet, sorry about the channel issue
09:27 danvet: tzimmermann, hm the armsoc drivers, did that not fail when compile testing when pushing?
09:28 danvet: I thought function pointer type mismatch blows up with an error?
09:29 tzimmermann: danvet, my fault. they are only for 32-bit arm. i missed to build them before pushing.
09:31 danvet: hm I thought my msm builds for both 32 and 64bit
09:31 danvet: iirc we only have one armsoc driver which only builds on 64bit
09:32 danvet: yeah they're both enabled in my config here
09:33 danvet: tzimmermann, anyway, whacked an r-b onto it
09:34 tzimmermann: danvet, i see. so it's my config
09:34 tzimmermann: thanks for checking
09:36 danvet: tzimmermann, a script which generates a minimal config and then enables everything in DRM + an explicit list of things would be nice
09:36 danvet: instead of everyone hand-rolling a config of their own
09:37 danvet: ideally we'd also complain if a symbol in a drm config isn't enabled in any of the ones we generate across a set of architectures
10:04 sravn: danvet: allmodconfig; make drivers/gpu/ -j 12 works for me. For non-trivial changes I have allmodconfig + allyseconfig + a few handpicked config for 10 architectures. Thats a nice long coffee break
10:05 sravn: And then when I do the occasionally git checkout drm-misc-fixes everything needs to build again because I do not have branch specific output dirs (yet)
10:06 sravn: So yeah, hand-rolled
10:06 danvet: sravn, well allmodconfig is a bit excessive in the amount it compiles
10:06 danvet: plus 10 architectures
10:07 danvet: ideally it'd be something we can run on gitlab CI without fd.o admins screaming at us :-)
10:07 sravn: limited to drivers/gpu/ - makes it tolerable for me
10:07 danvet: and still complete in like 10 minutes total (with massive cc cache and running in parallel a lot)
10:08 danvet: sravn, but how do you catch missing symbols and other stuff that depmod reports?
10:08 sravn: But not CI material, just what works for me
10:08 sravn: depmpd stuff is left to the bots - which shows that my approach is not good
11:03 austriancoder: is there a way to pass a parameter into a custom algebraic.py opt pass?
11:53 mripard: danvet: are you ok with https://lore.kernel.org/dri-devel/20201105135656.383350-1-maxime@cerno.tech/ ?
11:53 mripard: (and https://lore.kernel.org/dri-devel/20201029134018.1948636-1-maxime@cerno.tech/ ?)
11:55 danvet: dt stuff isn't my turf
11:56 danvet: mripard, do you want me to review the code, or all fine after our discussion?
11:56 danvet:kinda behind on patch review
11:56 danvet: badly even :-)
12:07 mripard: danvet: for the second one, the DT stuff should be alright, Rob acked-it, but you reviewed the DRM side in the previous version (https://lore.kernel.org/dri-devel/20201029134018.1948636-2-maxime@cerno.tech/ is the new version)
12:08 mripard: and for the mux one, it should have addressed your comment about mentionning the semaphore in the comment
12:08 mripard: the code is pretty much the same, except for the first patch that fixes again an issue you pointed out already
12:09 danvet: mripard, did I bring up the freq range request?
12:09 danvet:is a stateless reviewer
12:34 mripard: danvet: you did :)
12:41 danvet: mripard, ah then I guess it's all good
12:46 mripard: is that an a-b? (for both series?)
12:49 danvet: uh maybe not so much
14:18 danvet: tzimmermann, wrt your cached-by-default series, would be good to coordinate with pcercuei
14:19 danvet: if pcercuei series for this hasn't died in the feedback from hch :-(
14:19 tzimmermann: that was the series about cached gem mappings?
14:20 danvet: yeah
14:20 danvet: well the one from paul
14:20 danvet: yours about the default
14:21 danvet: just figured would be good if you two sync up so there's no confusion
14:21 danvet: airlied, I just backmerged -rc3 into drm-next, $reason in the merge commiit
14:21 danvet: agd5f_, ^^ some conflict in the amd driver, pls double check I'm not a fool :-)
14:21 danvet: tzimmermann, can you pls backmerge this into drm-misc-next? $reason int eh merge commit, you can copypasta that one
14:22 danvet: and pls ping me when it's done, so I can apply the patch from jason gunthopre
14:22 tanty: eric_engestrom: could you confirm your R-b at https://gitlab.freedesktop.org/mesa/piglit/-/merge_requests/394 ?
14:22 gitbot: Mesa issue (Merge request) 394 in piglit "gitlab-ci: use parallel jobs syntax for tox jobs" [Ci, Opened]
14:24 tzimmermann: danvet, pcercuei's series is about cma, mine is about shmem
14:24 tzimmermann: there's little overlap
14:25 danvet: oh right
14:28 tzimmermann: danvet, how urgent do you need that backmerge? a local testbuild will require a bit; or i can just push it
14:31 danvet: tzimmermann, maybe test build, we broke a bit much :-)
15:14 mripard: danvet: so I'm not sure if I should merge them then?
15:24 danvet: mripard, I think good if you have someone else ack it?
15:24 danvet: I guess you can wait for my review, but the queue is kinda long right now
15:25 dcbaker[m]: MrCooper: yeah, i thought of deleted all of them. I'll get the rest written I get started at work today
15:25 dcbaker[m]: *when
15:27 MrCooper: maybe you did, I just noticed the notification e-mails from when you pushed them
15:33 karolherbst: curro: fyi: https://github.com/KhronosGroup/OpenCL-Docs/issues/478#issuecomment-723323392
15:33 gitbot: KhronosGroup issue 478 in OpenCL-Docs "Unclear requirements for NULL region/offset/origin arguments in various functions" [Open]
15:37 dcbaker[m]: I really could have missed some. I didn't realize git push tags --all would push tags from other remotes 😕
15:38 mripard: danvet: if you'll get to it, it can wait :)
16:13 tzimmermann: danvet, i pushed the backmerge
16:16 danvet: tzimmermann, thx a lot!
16:16 danvet: mripard, uh that's not the answer I hoped for
16:16 danvet: no review trading with some other -misc driver?
16:16 danvet: maybe tzimmermann or sravn have a few things ...
16:16 danvet: otherwise I guess I'll add it to the list and then call in some favours :-P
16:33 jekstrand: Seriously??? bionic doesn't have qsort_r?
16:33 jekstrand: *sigh*
16:33 jekstrand: Stupid Android....
16:34 jekstrand: I guess the man page says it requires _GNU_SOURCE :-/
16:34 krh: hooray for android in CI though
16:34 karolherbst: :/
16:34 jekstrand: krh: :P
16:35 karolherbst: jekstrand: well.. it does have qsort_r in the source tree....
16:36 mimi89999: Hello. I tested OpenCL on my AMD RX 580 with hashcat, but it wasn't able to recover any passwords. I tested it also with 2 other backends and it worked. I filled https://gitlab.freedesktop.org/mesa/mesa/-/issues/3768 and built latest master, but it still does not work. What else can I do?
16:36 gitbot: Mesa issue 3768 in mesa "OpenCL might produce incorrect output" [Opened]
16:36 karolherbst: huh.. even in the header
16:37 jekstrand: karolherbst: I'm tempted to implement qsort_r in mesa with a TLS global variable.
16:38 karolherbst: jekstrand: I am more wondering why you don't see qsort_r... bionic has it
16:38 jekstrand: karolherbst: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/5509568
16:39 karolherbst: jekstrand: did you include stdlib.h?
16:39 karolherbst: mhh
16:39 karolherbst: but the undefined symbol is.. uhm..
16:39 karolherbst: annoying
16:40 karolherbst: ohh, might be linking order wrong as well or something stupid
16:41 karolherbst: anyway, bionic has it since 2009
16:41 mimi89999: I'm worried that I might be getting wrong results for other tasks as well.
16:50 jekstrand: Ugh... How do you use TLS?
16:50 karolherbst: jekstrand: the C11 way or the crappy way?
16:50 jekstrand: karolherbst: Uh.... C11 maybe?
16:50 jekstrand: I don't know if we can depend on that, though.
16:51 karolherbst: thread_local int a;
16:51 emersion: no include?
16:51 karolherbst: nope
16:51 karolherbst: core lang feature
16:51 emersion: interesting
16:51 karolherbst: without it you have to target pthread directly
16:51 karolherbst: emersion: yeah, every C before C11 sucks :p
16:51 emersion: hm, internet says it's in <threads.h>
16:51 emersion: because the core feature is _Thread_local
16:52 karolherbst: ahh
16:52 karolherbst: yeah, okay, the define is in threads.h then
16:52 jekstrand: karolherbst: I don't know that I can target c==
16:52 emersion: (to not clash with potential user types)
16:52 jekstrand: c11
16:52 jekstrand: But I can use C++ maybe?
16:52 jenatali: The C++11 keyword is thread_local
16:52 karolherbst: jekstrand: uhm.. c++17 is C11 based? dunno
16:52 karolherbst: ohh
16:52 karolherbst: c++11 also added thread_local
16:53 jenatali: You can also drop down to non-portable compiler-specific options if you need, GNU and MSVC both have extensions for it
16:55 karolherbst:wants to move to C11 for non crappy atomics as well
16:55 karolherbst: jenatali: soo, how long do we have to wait for proper C11 support in MSVC? :p
16:56 jenatali: karolherbst: Don't look at me, not my team :P
16:57 karolherbst: ohh seems like "__thread" for thread local is quite widespreadly used
16:57 karolherbst: just MSVC needs __declspec(thread)
16:57 jenatali: Yeah, could easily just macro define that
16:57 jekstrand: karolherbst: This is a wrapper, I can totally do C++
16:57 jekstrand: So that's what I'm doing.
16:58 karolherbst: :D okay
16:59 jenatali: karolherbst: Does rust have thread-local? :)
16:59 karolherbst: sure
16:59 karolherbst: even in std
16:59 jenatali: Awesome
16:59 karolherbst: it's a macro though, but.. hey :D
17:00 karolherbst: mhhhhhh
17:00 karolherbst: oh well.. couldn't use it for my use case anyway
17:05 jekstrand: Ok, qsort_r implemented. Of course, I've not tested it. :)
17:08 mimi89999: Hello. I tested OpenCL on my AMD RX 580 with hashcat, but it wasn't able to recover any passwords. I tested it also with 2 other backends and it worked. I filled https://gitlab.freedesktop.org/mesa/mesa/-/issues/3768 and built latest master, but it still does not work. What else can I do?
17:08 gitbot: Mesa issue 3768 in mesa "OpenCL might produce incorrect output" [Opened]
17:08 zmike_: T🤔ST🤔D
17:09 karolherbst: mimi89999: fix clover
17:10 karolherbst: I might look into random applications with clover at some point, but atm I am still working on CL image 1.2 support
17:17 mimi89999: Hmmm... That's rather a hard task. Do you have good tests?
17:17 karolherbst: there is a OpenCL conformance test suite
17:18 karolherbst: but yeah, it's not easy sadly
17:18 karolherbst: otherwise we would already be done
17:24 karolherbst: curro: ping on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7460 btw. I think you were fine with the change, just waiting on a r-by mainly or comments :)
17:24 gitbot: Mesa issue (Merge request) 7460 in mesa "clover/queue: Flush automatically if applications do not flush themselves" [Clover, Opened]
17:26 DottorLeo: hi! how can i check if GL_EXT_blend_func_extended is it supported on my Sandybridge with Mesa 20.2.1?
17:26 karolherbst: glxino
17:26 karolherbst: uhm
17:26 karolherbst: glxinof
17:26 karolherbst: ....
17:26 karolherbst: glxinfo
17:26 karolherbst: !
17:27 DottorLeo: with also grep?
17:27 ajax: someone should really write the "how to guess if an extension is supported from reading the code" howto
17:27 sravn: mripard: Looking at the DT binding, is "wifi-2.4ghz-coexistence" really describing the HW or is this a property to configure the hdmi controller?
17:28 sravn: mripard: browsed the patches referenced in your discussion with danvet. The vc4 patches is outside what I look at - because you and others usually take good care
17:29 ajax: DottorLeo: the answer is yes. EXT_blend_func_extended is supported in gles if ARB_blend_func_extended is supported in gl, and for intel the ARB one is supported for gen6 and above, and sandybridge is gen6
17:29 karolherbst: DottorLeo: yeah, you can grep the output
17:29 DottorLeo: thanks ajax! i've tried now with grep and indeed it's supported! :D
17:29 karolherbst: cool
17:30 DottorLeo: this beast will never die with emulators :D
17:30 ajax: the former fact about EXT-if-ARB you can discover from src/mesa/main/extensions_table.h, and the latter about intel generation support from src/mesa/drivers/dri/i965/intel_extensions.c
17:31 karolherbst: ajax: yeah.. although I'd like the idea of just being able to fake everything and generate a table out of it... :p
17:32 agd5f_: danvet, the documentation or something else?
17:32 DottorLeo: ajax: thanks, i'm a simple user (not a deverloper sadly ^^") and i was curious how can i check if my GPU support some OpenGL extensions, because some emulators require them and Sandybridge is really the minimum :D
17:32 ajax: karolherbst: yeah, i think the plan there was to add enough pci ids to fake drm
17:32 karolherbst: DottorLeo: yeah, but depending on the simulator, you won't have much fun with a sandybridge GPU though :/ I guess it works good enough for 2D stuff though
17:33 karolherbst: ajax: for nouveau we'd need to fake the UAPI :/ or at least libdrm
17:33 ajax: then you could just say like MESA_PRETEND_I_AM=1002:67df glxinfo
17:34 karolherbst: we don't rely on PCI IDs at all
17:34 karolherbst: also, vendors are messing it up sometimes :/
17:34 ajax: yeah, i know, the real id is somewhere else in the register file
17:34 ajax: still
17:34 karolherbst: yeah..
17:34 karolherbst: but the chipset is returned by the drm API
17:36 DottorLeo: karolherbst: yeah but i'm waiting for the "almost perfect" laptop to change this one. I have to say that with Linux i can use OpenGL 3.3 on sandybridge instead with windows i'm stuck to 3.1. Just with this one thing i can run light games on Steam that require Opengl 3.3. The same games what will not work on Windows because the ancient OpenGl drivers for sandy!
17:38 danvet: agd5f_, hm didn't see anything in docs
17:38 danvet: just a few places which had green_sardine from -fixes ves other stuff enabled in -next
17:39 danvet: git somehow committed a ton of conflict markers for reasons I didn't quite get
17:39 danvet: I didn't see any conflicts in the docs
17:44 mripard: sravn: kind of both
17:44 mripard: it's because there's a wifi chip and an HDMI output that we need to configure the HDMI controller differently
17:52 sravn: mripard: I find it hard to draw the line what to put in DT and what not. Often the details are hidden behind specific compatible and not stored in DT. This is on the border line I think
18:01 mripard: sravn: not really, it's board specific in that case
18:01 mripard: if there's no wifi chip on the board, you don't have any issue
18:02 mripard: so it's not really a property of the SoC, but rather how and what it was integrated with
18:23 jekstrand: Ugh.... We set -D_GNU_SOURCE on Android builds but then link against bionic(). Seriously?
18:23 agd5f_: Does anyone know if genpd plays nicely with runtime pm? E.g., if we have a PCI device which multiple power domains?
18:24 daniels: jekstrand: bionic speaks _GNU_SOURCE
18:24 karolherbst: agd5f_: multiple power domains as in sub devices or all in one?
18:25 agd5f_: karolherbst, one driver
18:25 jekstrand: daniels: Without qsort_r() :-/
18:25 daniels: _GNU_SOURCE doesn't mean 'literally glibc', it means 'GNU extensions to POSIX/BSD/XOpen/SUS/aslkdjfasdf'
18:25 karolherbst: agd5f_: I asked about devices, not drivers ;)
18:25 daniels: jekstrand: right, but like ... glibc has added entrypoints over time, right?
18:25 jekstrand: Yeah, from my googling, qsort_r was 2014 or so
18:25 daniels: jekstrand: _GNU_SOURCE is where you request that the libc expose certain new features which are not Real True UNIX
18:26 daniels: it may not live up to your hopes and dreams, so you still need to test individually
18:26 agd5f_: karolherbst, depends how you want to look at it. Multiple IP blocks, but all of those IP blocks are handled by a single driver
18:26 jekstrand: In any case, I need to figure out how to ask meson to check for a thing.
18:26 karolherbst: agd5f_: I meant like PCI devices, is it one real devices or is it exposed as several functions?
18:26 karolherbst: like the usual GPU vs HDA split
18:26 karolherbst: or really as one device
18:26 agd5f_: karolherbst, one device
18:27 karolherbst: okay.. in this case I think the domains have to be managed inside the driver as the runpm is strictly tight to struct device;
18:27 daniels: jekstrand: https://gitlab.freedesktop.org/wayland/wayland/-/blob/master/meson.build#L29
18:28 agd5f_: karolherbst, yeah. I was reading that there was some attempts to unify genpd with runpm, but I didn't see any evidence that that had happened
18:28 karolherbst: ahh, not aware of anything in this regard though
18:39 mimi89999: Can I run OpenCL on my CPU with LLVMpipe?
18:39 karolherbst: mimi89999: yes, with LP_CL=1
18:39 karolherbst: but it might not work as expected because $random bugs
18:41 jekstrand: daniels: Yeah, I found the related line in our meson
18:54 mimi89999: What should I see in clinfo with it?
18:54 mimi89999: I still see the GPU
18:59 karolherbst: mimi89999: ohh, I think you'd need to build from source
18:59 karolherbst: probably not in any release yet
19:00 mimi89999: I have built e3893ee2. I will try on that.
19:04 mimi89999: I don't see any difference.
19:05 mimi89999: On `e3893ee2`
19:05 ajax: i'm going to regret asking this, but: anyone know where the gles1 cts lives?
19:06 airlied: mimi89999: likely not built correctly
19:06 airlied: you need spriv tools and llvm spirv translator
19:07 ajax: nm, the answer is khr internal gitlab
19:07 airlied: and the opencl spirv build flag
19:12 mimi89999: How exactly should I build?
19:13 agd5f_: danvet, nevermind, was looking at the wrong thing. Looks good so far.
19:14 airlied: -Dgallium-opencl=icd -Dopencl-spirv=true -Dgallium-drivers=swrast
19:14 airlied: mimi89999: ^ as a baseline
19:14 airlied: then you have to make sure to install whatever it complains is missing
19:16 curro: karolherbst: what did you say is overcomplicated?
19:16 danvet: agd5f_, I guess once you diff against your internal tree it should pop out if I misplaced something?
19:17 danvet: agd5f_, you're thinking of modelling the amdgpu chip more like a soc in the kernel driver?
19:17 danvet: re your genpd and runtime pm question
19:18 agd5f_: well, I'd like to be able to handle static powergating on IPs on the GPU without re-inventing the wheel
19:19 agd5f_: but still be able to support d3cold like stuff at the device level
19:19 karolherbst: curro: just a general feeling when working on the code. Like I'd like to template the core::image class, but we can't because of annoying reasons (mainly caused by how we wrap cl objects)
19:19 karolherbst: and generaly that is always some annoying issue I run into when working on stuff
19:20 karolherbst: see e.g. the inline sampler patc
19:20 karolherbst: h
19:20 karolherbst: following the architecture makes stuff hard
19:20 karolherbst: anyway, it just fells all of this could be way easier to do
19:22 karolherbst: also the pointer stuff and wrapper objects we have feel like NIH, as the c++ STL provides those features as well, but replacing this also means rewriting nearly everything
19:23 karolherbst: and it's not even just me saying this
19:23 karolherbst: external people who tried to look into usinv clover for their stuff rather wrote something from scratch instead of reusing it because "it's hard to work on it"
19:24 curro: karolherbst: funny thing is the wrapping of CL objects is designed with the simplicity of the implementation in mind, so proper checking is guaranteed to occur at any entry point that needs to convert a CL API object to a Clover object
19:25 karolherbst: sure, but I ran into problems with it, because 1. it's not clear it happens 2. you can't make use of internal stuff using cl_objects in interfaces, because you were not aware and just ran into memory corruption even though the compiler was happy
19:25 curro: karolherbst: intrusive smart pointers used by clover weren't available in STL when Clover was written, IIRC there was a similar alternative in the Boost library but adding that dependency would have been even more controversial
19:26 karolherbst: and why was sharder_ptr not enough?
19:26 karolherbst: *shared_ptr
19:27 karolherbst: anyway, it't not to blame anybody here or questioning design decision, just saying how it fells to me today
19:27 karolherbst: and others made similiar experiences
19:27 karolherbst: and maybe it's because I didn't do enough C++, but if that means it's hard for everybody else, then maybe that's already a bad sign
19:28 jenatali: IMO, too much was hidden inside magic function calls. It's neat how tiny all of the entrypoints are, but trying to actually figure out what's going on takes a lot of effort
19:28 karolherbst: also, throwing stuff also messes up control flow and is a pain to debug issues
19:28 karolherbst: "catch throw"? haha, if you run into many errors with the applications
19:29 karolherbst: step? "woops" stepped over a throw, now you are out
19:29 curro: karolherbst: shared_ptr may have worked in some places but would be less efficient than an intrusive ptr (with nearly identical interface), because we're trying to take advantage of the reference counter part of every CL object
19:30 karolherbst: maybe, maybe not
19:30 karolherbst: but if we would have wanted to be efficient, we would have disabled exceptions anyway ;)
19:31 karolherbst: makes code also more efficient
19:31 curro: karolherbst: point is, even if we were using shared_ptr internally we would need to do the reference-counting we're doing right now, so the complexity reduction is minimal
19:31 curro: karolherbst: error-based exception handling is actually extremely efficient in the typical case where you don't get any of them thrown
19:32 karolherbst: if you have exceptions enabled, but disabling exceptions alone is a significant benefit
19:32 curro: how so?
19:32 karolherbst: the compiler generates better code
19:35 karolherbst: also, not trying to say that decisions made are bad or so, often it's just not apparent why they were made and working with the code and debugging is sometimes quite painful. But that's also the nature of C++ compared to C
19:35 karolherbst: all of that just piles up
19:36 curro: karolherbst: any quantitative evidence for that statementn? i've looked into quite a bit of research about exception handling and am not aware of any solid evidence that enabling exceptions has any significant effect on performance beyond increasing the binary size
19:38 danvet: agd5f_, so I think if you create you're own hierarchy of struct device nested under the pci device
19:38 danvet: that should work
19:38 danvet: never tried though
19:38 danvet: but you can link up your power domain to the sub devices, and then I think it's integrated with the runtime pm there
19:38 danvet: and since it's hierarchiecal, it'll block runtime pm of the pci device if anything is in use
19:38 curro: karolherbst: anyway, i admit the lack of documentation of some of this infrastructure may have made it hard to work with, but i'm skeptical of that being evidence of a bad design as you say. most of the time so far when you've complained about something being excessively complicated (like the event dependency graph the other day), it turned out there was some compelling reason behind it that just wasn't documented clearly enough
19:39 karolherbst: curro: well, if it wouldn't make a difference, why does something like "noexcept" exist? The reason it got added was that it does increase performance if the code knows there are no exceptions to be expected
19:39 danvet: I think we looked at it when we did the power domains for i915 way back, but then people figured it's simpler to invent a private wheel
19:39 karolherbst: also, I've heard that high perf C++ projects do disable exceptions, also if they target "embedded" systems
19:39 karolherbst: like game consoles
19:39 karolherbst: so games usually have exceptions disabled
19:39 karolherbst: not sure if there are new studies or anything
19:39 danvet: I'm still not sure which way is best, since within a driver the abstraction definitely has cost
19:40 karolherbst: and maybe it's much better know
19:40 karolherbst: might be
19:40 danvet: and sometimes gets in the way if you just want to do a quick hack
19:40 danvet: e.g. so many drivers got their runtime pm for sub-devices wrong in atomic commit
19:40 qyliss: lgo
19:40 danvet: since there's now a layer in the middle you need to understand vs just directly typing in the programming sequence the hw people gave you
19:40 karolherbst: curro: yeah, that's why I tried to push it into the "it feels overcomplicated" direction, rather than a "it could have been simplier"
19:40 curro: karolherbst: the existence of noexcept means the type system can tell whether exceptions need to be handled for each bit of code, so you can get the best of both worlds
19:41 danvet: otoh, there's some really neat concepts and automations
19:41 danvet: and you get some stuff like autosuspend, hystersis, locking headaches and all that solved for you
19:41 karolherbst: curro: sure, but we couldn't really make much use of it as we have tons of places where we can throw stuff. Anyway, it comes with some costs but I doubt it's a huge factor anyway
19:42 karolherbst: just sometimes it's okay to go with a little cost if it makes other htings easier
19:43 dcbaker[m]: karolherbst: exceptions and threads are bad in C++ because only one exception can be in flight at a time. That's why high performance threaded applications don't use them
19:44 karolherbst: dcbaker[m]: exception per application not thread?
19:44 curro: karolherbst: you can make use of noexcept() relatively easily in generic code and take advantage of it whenever it's instantiated for code that also doesn't use exceptions
19:45 karolherbst: but yeah, I don't know much about the details, just that apparently there is a benefit of just disabling them globally
19:45 dcbaker[m]: karolherbst: that's my understand. Something to do with the way c++ exceptions unwind the stack
19:45 curro: dcbaker[m]: lol, that's like saying that assembly instructions are bad because only one can be executed at any given time by one thread
19:46 karolherbst: dcbaker[m]: well.. that'd be bad indeed, but also surprising
19:46 karolherbst: but does it mean threads have to lock on the execption unwinding? yeah.. might be the case, dunno. don't know the internals enough to be able to make anu judgements here
19:47 dcbaker[m]: curro: I like exceptions when used in exceptional cases, but there are legitimate reasons they can be bad. It's really like to complement them with a Either type
19:47 curro: karolherbst: and that benefit is mixed, exception handling *can* reduce your runtime in the typical case where no exceptions are thrown, even though they might indeed make some optimizations less effective in some cases but it's not nearly as expensive as a full optimization barrier like e.g. an indirect function call
19:47 dcbaker[m]: *I'd
19:48 karolherbst: curro: we don't do indirect function calls all that often (well, execpt for virtual functions), but cpus are optimized against small control flow
19:48 karolherbst: and it matters not at all
19:50 curro: karolherbst: CPUs are optimized for indirect function/virtual method calls too, but they are optimization barriers regardless of what the CPU does if there is no way for the compiler to de-virtualize the call
19:51 dcbaker[m]:wishes c++17 had given us std::expected like was proposed
19:52 karolherbst: anyway, now with the rust I was doing, I am already at the "Rust is the C++ we always needed" level
19:53 karolherbst: dcbaker[m]: that also sounds like an overcomplicated thing to solve something simple :p
19:54 karolherbst: but yeah, that looks like Rusts std::Result thing
19:54 karolherbst: which gives you exception, just in non painful
19:54 dcbaker[m]: yeah, they're both ADTs, borrowed from functional programming languages
19:54 curro: dcbaker[m]: I also like Either-like error handling very much but it can get rather annoying in some cases compared with exception-based error handling whenever you have a long chain of operations that can potentially fail. C++17 did give us something comparable with std::optional BTW
19:55 karolherbst: Rust has the ? operator
19:55 karolherbst: which makes it really painless to write code in functions returning Result<>
19:55 dcbaker[m]: yeah, but optional either has a value or no value, expected would be a value or an error, which is even better
19:55 dcbaker[m]: I do like optional a lot though
19:55 karolherbst: so in Rust you can do: let e = func_with_error(...)?;
19:56 karolherbst: and if it throws an error your func also early returns automatically
19:56 karolherbst: if it returns Result<> and the error type matches
19:56 jekstrand: ? is awesome
19:56 karolherbst: yeah
19:56 karolherbst: I use it for CL error codes :D
19:57 dcbaker[m]: is ? a null-coalessing operator in rust?
19:57 dcbaker[m]: s/a/the/
19:57 karolherbst: it suffers from the same problem in gdb though
20:00 karolherbst: dcbaker[m]: no, that's a seperate thing
20:00 curro: karolherbst: '?' operator is pretty cool yeah. in Haskell there is the Maybe monad that gives you similar convenience. but it doesn't really help whenever you need to do something non-trivial in response to the error beyond also throwing an error
20:01 karolherbst: right, but for that you have the Result class allowing you to do an .or_else(lambda...) thing
20:01 agd5f_: danvet, does genpd require device tree? Also I think there may be conflicts between genpd and power domains as defined by ACPI, but I haven't dug too far into it yet
20:02 danvet: agd5f_, I thought with all this you can always instantiate it all yourself
20:02 jekstrand: Yeah, in Rust, you can match on the return value of a thing and sort-of use that as try/catch if you want.
20:02 jekstrand: Or ? for easy ones
20:02 danvet: it gets more awkward since you have to do all the connections yourself too
20:02 danvet: since you don't have a dt
20:02 karolherbst: jekstrand: that was quite a bit annoying to get your head around :D but yeah
20:02 danvet: or acpi doing it for you
20:03 karolherbst: but I also have to concentrate on writing "understandable" code and not just abuse every feature as much as I want to :D
20:03 karolherbst: like what is also a bit annoying is, that error handling is quite hidden in clover
20:03 karolherbst: and you don't know if all error cases are actually handled or not
20:04 karolherbst: but you also have to be careful with code duplication :/
20:04 karolherbst: it's a tough call
20:04 karolherbst: but I prefer doing the checks explicitly in every function or at least comment what a called function is doing
20:04 karolherbst: so while looking at the function I know what is handled and what not
20:06 curro: karolherbst: error handling in clover is designed for simplicity primarily :P, the exception-based signallinng means less likelihood for you to forget a check at an entry point implementation that would cause an error condition to go unnoticed
20:07 karolherbst: yeah, I mean I understand why it is like it is, it just makes a bit harder to figure out if a given line in the spec was handled or not
20:08 karolherbst: even just a comment above the line which is supposed to throw the error would be sufficient
20:09 curro: karolherbst: you could argue error handling it being implicit could lead to conditions where someone accidentally fails to do some needed clean-up leading to memory leaks or similar, but that's one of the reasonns why clover tries to use RAII for pretty much everything including memory, locks, etc.
20:11 karolherbst: ohh, I was more refering to those "CL_.... if $param0 is $value_x" statements in the spec
20:11 karolherbst: so if one would want to verify one API implementation handles all of that (and doesn't return forbidden values) it's quite annoying to follow as you don't know where errors can come from, and have to jump around a lot
20:12 karolherbst: and having a // CL_INALID_VALUE if ... comment above a validate_params() call might be helpful already
20:12 karolherbst: but it would also be cool if we could validate statically that we don't throw invalid error values and stuff
20:13 karolherbst: but didn't play around with this part yet
20:13 curro: karolherbst: right, it would be great to document in comments in the API implementation, but you must admit it's nice for the error to be thrown if somebody passes the wrong CL API object, even if whoever implemented the entry-point forgot to check for that specific condition
20:13 karolherbst: sure
20:14 karolherbst: just arguing from a verifiability point of view
20:15 karolherbst: but now that indeed gave me an idea on what to look into next :D
20:20 agd5f_: danvet, yeah we spun our own for some stuff already, but are starting to get more and more of it, Trying to decide which is the better option.
20:22 danvet: agd5f_, I guess for you there's also the trade off with how much you have to reinvent for the other platforms
20:22 danvet: but I guess for DC you already deal with substantial amounts of that
20:29 curro: karolherbst: it's pretty easy to have the static guarantee that a given entry point doesn't return more than the error codes defined by the spec. but it would be hard to statically infer whether any of the code involved in an API call could potentially raise a different error code when it hits some unexpected run-time condition. maybe we could have done something with the obsolete throw() specification, except it doesn't really work
20:29 curro: and it's been removed from the language :P
20:31 karolherbst: yeah...
20:31 karolherbst: but it would be cool to know if something like that would be possible in Rust though
20:31 curro: karolherbst: how would you do it in rust?
20:31 karolherbst: no idea :D
20:32 karolherbst: well, I have some idea, but no clue if it would work out
20:33 airlied: so who's going to RE the M1 GPU :-P
20:33 karolherbst: airlied: no fun as you wouldn't be able to run your own kernel anyway :p
20:33 curro: karolherbst: anyway I doubt having unexpected runtime conditions kill a program with a loud warning when nobody remembered to map that error condition to a CL error code is really that bad in itself. seems no worse than using assert() for catching unexpected runtime conditions.
20:34 karolherbst: curro: it's more about "huh, that's an unexpected error, thanks compiler for telling me"
20:34 airlied: karolherbst: I give it a month before someone roots one :-P
20:34 karolherbst: :D
20:35 mimi89999: I rebuilt Mesa with those options and now I'm getting `clGetDeviceIDs(): CL_DEVICE_NOT_FOUND` on a device without GPU, so llvmpipe is clearly not working.
20:36 airlied: mimi89999: have you installed it at the system level or in a prefix, you maybe need to set LD_LIBRARY_PATH
20:38 curro: karolherbst: right, which the compiler doesn't know about either when you use assert() to catch unexpected runtime conditions, you need to run the code to find out you've messed something up
20:38 mimi89999: System level. I reused the dabian folder from the Debian package and built a Debian package that I installed.
20:38 karolherbst: curro: well.. rust is built in a way to figure a lot of things out statically
20:38 mimi89999: ldd /usr/lib/x86_64-linux-gnu/libMesaOpenCL.so.1.0.0
20:38 mimi89999: libLLVMSPIRVLib.so.11 => /usr/lib/libLLVMSPIRVLib.so.11 (0x00007f52d7c88000)
20:39 karolherbst: and I wouldn't be surprised you could figure this out as well
20:39 karolherbst: just a matter of how
20:39 karolherbst: mimi89999: set "LP_CL=1"?
20:39 mimi89999: It's correctly linked
20:39 mimi89999: Where?
20:39 karolherbst: env variable
20:39 mimi89999: Yes
20:40 mimi89999: `export LP_CL=1`
20:40 karolherbst: did you enable spirv?
20:40 karolherbst: opencl-spirv with meson
20:41 curro: karolherbst: if there is a way for you to do that in Rust there is a good chance the same will be possible in C++ since template metaprogramming is turing-complete...
20:41 karolherbst: just a matter on how to declare that in c++
20:42 karolherbst: and probably it is, but I don't think it's possible through the exception mechanism
20:42 mimi89999: Added `-Dopencl-spirv=true \` between https://salsa.debian.org/xorg-team/lib/mesa/-/blob/debian-unstable/debian/rules#L144-145
20:43 airlied: mimi89999: can you run strace -e openat -o /tmp/trace clinfo and pastebin /tmp/trace
20:43 karolherbst: airlied: I bet it's opencl-spirv not being set :p
20:44 airlied: karolherbst: it's linked to llvm spirv
20:44 airlied: as shown above
20:44 mimi89999: https://lebihan.pl/xmpp-upload/index.php/2879dfaf-047a-4de6-a7e1-7cb59ccab185/trace
20:44 karolherbst: ohh, indeed... mhh
20:44 karolherbst: but no spv tools?
20:44 mimi89999: Ah. Sory
20:44 karolherbst: strange
20:45 mimi89999: https://lebihan.pl/xmpp-upload/index.php/53429140-eea0-4383-8aef-ffe1c475d944/trace
20:45 mimi89999: Forgot the export in that shell
20:45 karolherbst: ohhh
20:45 karolherbst: "/usr/lib/clc/spirv64-mesa3d-.spv"
20:45 karolherbst: ehh
20:45 karolherbst: right
20:45 karolherbst: airlied: when do people get it?
20:45 airlied: ah yes that is painful
20:46 airlied: it's kinda wait for llvm 12 or build your own libclc
20:46 airlied: https://people.freedesktop.org/~airlied/scratch/spirv64-mesa3d-.spv or grab that and stick it in /usr/lib/clc
20:47 mimi89999: Ouch
20:48 mimi89999: `Device #0: llvmpipe (LLVM 11.0.0, 256 bits)`
20:48 mimi89999: Nice!
20:51 mimi89999: `fatal error: 'opencl-c.h' file not found`
20:51 mimi89999: Not yet
20:51 airlied: now that is generally a clang/llvm version mismatch, strace and see I expect
20:51 mimi89999: `libclang-common-12-dev` I need that? Right?
20:51 airlied: of 11 if you hve llvm 11
20:52 mimi89999: I have 11
20:52 karolherbst: well, you also need clang-11
20:52 karolherbst: why do you have 12 installed?
20:52 karolherbst: also, I think the headers are just part fo the normal clang packages?
20:52 karolherbst: dunno
20:52 karolherbst: install by path..
20:53 mimi89999: `Kernel minimum runtime larger than default TDR`
20:53 karolherbst: ahh yeah
20:53 karolherbst: stuck at CL1.1
20:53 mimi89999: You said I need 12
20:53 mimi89999: Installed `libclang-common-11-dev`
20:53 mimi89999: What's that?
20:54 karolherbst: heh what..
20:54 karolherbst: opencl-c.h is part of libclang-common-X-dev packages in debian? uff
20:54 airlied: no 12 was just for the future libclc library
20:54 mimi89999: OK. I installed that one.
20:55 karolherbst: guess that makes a little sense.. oh well
20:55 mimi89999: I mean the `Kernel minimum runtime larger than default TDR` error.
20:55 mimi89999: Now it's what I'm getting.
20:57 mimi89999: Wrong LLVM or something else?
20:57 karolherbst: no clue
20:57 karolherbst: not a mesa error afaik
20:57 airlied: yeah make sure you hae llvm and clang the same versions install and are linked to the same one, never seen that error
20:58 mimi89999: https://github.com/hashcat/hashcat/commit/73bba00286d815878b544d2d0aa6a79e6cf698ce
20:58 mimi89999: Meas timeout
20:59 curro: mimi89999: seems like the app decides your CPU is too slow of a CL device?
21:00 curro: maybe edit the '2000' threshold introduced by that patch?
21:00 karolherbst: or we loop forever
21:00 curro: but mimi89999 didn't get this problem when running on real GPU hardware, right?
21:01 karolherbst: well, but the result was wrong afaik
21:01 mimi89999: No. The benchmark run, but https://gitlab.freedesktop.org/mesa/mesa/-/issues/3768
21:01 gitbot: Mesa issue 3768 in mesa "OpenCL might produce incorrect output" [Opened]
21:01 curro: right, which seems like a completely different failure mode
21:02 mimi89999: With LLVM md5 is `2676.6 kH/s`, md4 is `3675.8 kH/s`
21:02 mimi89999: Not that bad
21:02 curro: cool
21:02 curro: mimi89999: but does it actually work?
21:03 mimi89999: No clue. Not the hash I need to CTF
21:03 mimi89999: No. It;s very bad
21:04 mimi89999: POCL is `194.0 MH/s` md4 and `111.9 MH/s` md5
21:05 airlied: probably need to tune it a bit then :-)
21:06 curro: mimi89999: yeah i guess that's expected to be rather slow... would be nice to check whether it actually finds a solution as a way to understand if the failure you've reported on the radeon GPU is a pipe driver or a front-end issue
21:11 airlied: suppose I better find a solution to the last printf issue
21:16 curro: karolherbst: one idea for static checking of error codes would be to change the constructor of clover::error to take a templatized static exception specification argument, which would basically be a tuple where each element denotes a type of CL-mapped exception that might be thrown, along with some rules for taking subsets of an existing spec. from the constructor off clover::error we could then static_assert that the type of the
21:16 curro: current exception is allowed by the specification. this means that in order to be able to throw an exception of type T you'd need a specification allowing it, which you would also pass to the thing catching the exception and mapping it to a CL error code, which would then guarantee that no other error code is ever returned
21:21 curro: karolherbst: you were just arguing against overcomplicated things though ;), TBH aborting at runtime with a loud enough warning when an unforeseen error condition occurs seems good enough to me
21:25 mimi89999: What printf issue?
21:26 airlied: just making strings work on gpus, master doesnt have printf at all
21:26 mimi89999: Just several days ago I was patching nmap: https://github.com/nmap/nmap/pull/2174 and https://github.com/nmap/nmap/pull/2177
21:26 gitbot: nmap issue (Pull request) 2174 in nmap "Change hostmap-crtsh to split SANs on newline" [Nse, Bug, Open]
21:26 gitbot: nmap issue (Pull request) 2177 in nmap "Change nseU_gettarget to prefer targetname" [Closed]
21:26 mimi89999: I think it's the annoy FOSS dev tasks.
21:27 karolherbst: curro: yeah.. just a matter of how annoying it would be to put that into code
21:32 jenatali: airlied: I'm in the middle of rebasing our CL compiler stack onto master, which means I'll actually be able to help validate any further tweaks you want to make to that printf MR
21:32 mimi89999: > would be nice to check whether it actually finds a solution as a way to understand if the failure you've reported on the radeon GPU is a pipe driver or a front-end issue
21:32 mimi89999: It will take hours on that LLVMPIPE.
21:34 curro: karolherbst: i think the largest annoyance would be threading the exception specification through everything that can possibly lead to an error being thrown down the call chain, and likely templatizing some amount of exception-throwing code that currently lives in a .cpp file, but that seems like the feature having the desired effect and forcing you to document /all/ exception-throwing code at the type system level
21:34 curro: karolherbst: but yeah i agree the effort likely outweighs the benefit
21:37 airlied: jenatali: cool, ive really only got the string handling left to work out,
21:37 mimi89999: OK, so the 4 char pass got guessed by llvmpipe, but not Radeon.
21:38 mimi89999: curro: I have the answer for you.
21:38 airlied: not sure digging it out of shader is practical for clover, but i havent thought through it all yet
21:39 curro: mimi89999: hmm, i guess that points at either a radeon pipe driver bug or a synchronization bug
21:40 mimi89999: Can I debug sync?
21:42 curro: maybe airlied knows how to get the driver to flush and synchronize at every compute call?
21:43 airlied: hmm for radeonsi not really sure
21:48 mimi89999: Isn't it one of the best supported backends?
21:49 airlied: there are no supported backends
21:50 airlied: it is the best unsupported backend
21:50 mimi89999: Right
21:50 airlied: but nobody really has time to csre for it
21:50 airlied: so its very best effort
21:50 mimi89999: Besides of course the i965 that also has good support.
21:51 airlied: for cl it has no support at all
21:51 mimi89999: You don't have https://mesamatrix.net/, but for OpenCL?
21:54 ajax: mimi89999: not yet. https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4979 though
21:54 gitbot: Mesa issue (Merge request) 4979 in mesa "WIP: Add OpenCL to docs/features" [Opencl, Docs, Opened]
21:54 airlied: we don't really have a baseline yet
22:06 mimi89999: Should I open a bug against radeonsi then?
22:07 airlied: yeah but don't execpt much traction, as I said nobody cares officailly about opencl on radeonsi
22:07 airlied: the issue you have opened is probably sufficient
22:08 airlied: if you are feeling experimental you could try https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7231 and set R600_CL_NIR=1
22:08 gitbot: Mesa issue (Merge request) 7231 in mesa "WIP: radeonsi support for clover nir" [Opencl, Clover, Radeonsi, Opened]
22:14 mimi89999: A bug against radeonsi is a bug against the Kernel, right?
22:16 jekstrand: mesa
22:42 jenatali: karolherbst: https://devblogs.microsoft.com/cppblog/c11-and-c17-standard-support-arriving-in-msvc/
22:46 karolherbst: nice
22:47 jekstrand: jenatali: About time!
22:47 jekstrand:looks forward to deleting piles of crap from mesa
22:47 mimi89999: airlied: Is that r600 or radeonsi?
22:47 mimi89999: The MR
22:49 airlied: mimi89999: radeonsi
22:55 karolherbst: jenatali: well, releasing a Linux based OS while not having a C17 capable compiler would also be very embarassing anyway, :p
22:56 Lyude: are they going through with the linux based os thing
22:56 karolherbst: Lyude: they'd be crazy if not :p
23:09 jenatali: I guess we're crazy then? :P
23:11 karolherbst: :p
23:17 mimi89999: I added a comment about what we have come to: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3768#note_689902
23:17 gitbot: Mesa issue 3768 in mesa "OpenCL might produce incorrect output" [Opened]
23:17 mimi89999: Works on LLVMpipe
23:22 mimi89999: airlied: It has conflicts in src/compiler/nir/nir.c, src/gallium/drivers/radeonsi/si_shader.c, src/gallium/drivers/radeonsi/si_shader_nir.c, src/gallium/include/pipe/p_defines.h. Could you rebase?
23:29 airlied: mimi89999: will do in a minute
23:29 mimi89999: Thanks!
23:32 airlied: mimi89999: pushed now
23:34 mimi89999: Pulled and building.
23:48 mimi89999: airlied: That's a build failure
23:48 mimi89999: ../src/amd/llvm/ac_nir_to_llvm.c:3251:1: error: control reaches end of non-void function [-Werror=return-type]
23:49 airlied: oops my rebase must have failed
23:50 airlied: doh wrong builddir, gimme another minute :-P
23:50 mimi89999: Sure
23:51 mimi89999: Ping me when finished
23:58 airlied: ouch radeonsi ran out of debug flags
23:58 airlied: mareko, pepp : you are on the edge of 64 debug flags