01:12 kherbst: dcbaker[m]: btw, is rustfmt wired up as an implicit meson target as well?
01:12 kherbst: or will it be?
01:14 anholt: that doesn't feel like meson's job at all
01:14 anholt: I've got a CI job for it in my ci-rust branch.
01:15 kherbst: well, cargo does support it
01:15 kherbst: and I'd rather to ninja rustfmt instead of having to call rustfmt on all files I touched
01:15 kherbst: *do
03:19 kherbst: sooo.. now to implement OpenCL in rust :D
03:19 kherbst: until the mesa specific stuff is figured out I just do a stub API implementation with a validation layer
03:24 dcbaker[m]: kherbst: anholt I think there's a target for clang-format,I haven't thought about formatting yet. Just tests and cargo integration
03:24 kherbst: dcbaker[m]: "rustfmt" is it's own binary atm though
03:24 kherbst: although I suspect it just wraps around clang-format though? no clue
03:24 dcbaker[m]: I'm just saying there's precedent
03:25 kherbst: ahhh
03:25 kherbst: I see
03:58 kherbst: uff
03:58 kherbst: bindgen is able to parse the CL headers
03:58 kherbst: yay
03:59 kherbst: it even compiles :)
04:00 kherbst: mhhh
04:01 kherbst: it does complain about u128 being used though
04:13 jekstrand: kherbst: What's wrong with u128?
04:13 kherbst: instable ABI
04:13 kherbst: but...
04:13 kherbst: the bigger problem is that long double becomes i128
04:13 kherbst: uhm
04:13 kherbst: u128
04:14 kherbst: "note: 128-bit integers don't currently have a known stable ABI"
04:14 kherbst: https://github.com/rust-lang/rust-bindgen/issues/1549
04:14 gitbot: rust-lang issue 1549 in rust-bindgen "long double becomes u128" [Enhancement, Help Wanted, Open]
04:14 jekstrand: I'm not sure they're 100% well-defined in C either.
04:14 kherbst: yeah...
04:14 jekstrand: What in CL uses u128
04:14 kherbst: it also only happens 6 times, so maybe we can just ignore it long enough
04:14 kherbst: long double :p
04:14 kherbst: not u128
04:15 kherbst: but I think it's also mainly fallout?.. let me check
04:16 kherbst: jekstrand: cl_char16
04:16 kherbst: apparently a bunch of types enfore alignment or so..
04:16 kherbst: mhhh
04:16 kherbst: but
04:17 kherbst: typedef __m128i __cl_char16
04:17 kherbst: there is a bunch of those as well
04:17 jekstrand: Oh... That's pretty terrible.
04:17 kherbst: _and_ included C apis through headers
04:17 kherbst: like strtold
04:17 kherbst: or qecvt
04:17 jekstrand: How do they enforce alignment for cl_long16? :P
04:18 kherbst: you really want to know? :D
04:18 kherbst: oh wow
04:18 kherbst: is that terrible
04:18 kherbst: typedef union magic
04:19 kherbst: cl_long CL_ALIGNED(128) s[16];
04:19 kherbst: "__CL_ANON_STRUCT__ struct{ cl_long8 lo, hi; };" uuuhhh
04:19 jekstrand: Oh, they just use C alignment attributes.
04:19 kherbst: yeah...
04:19 kherbst: anyway
04:19 kherbst: that tripps it of a little
04:19 kherbst: and I am not sure if it even matters
04:20 kherbst: I think those things are just used to be able to use those types as placeholders
04:20 jekstrand: Yeah, I don't think it matters for C ABI.
04:20 jekstrand: Maybe if you were trying to write CL code in Rust and wanted to place things in a map.
04:21 kherbst: soo, there are three functions I have to implement: clGetExtensionFunctionAddress, clIcdGetPlatformIDsKHR and clGetPlatformInfo
04:21 kherbst: and those are more or less the only functions we have to export
04:21 kherbst: exporting is easy.. now let's see if impementing that stuff is annoying
04:22 kherbst: kind of annoying we have to do both ways
04:23 jenatali: kherbst: Not sure if it's relevant, but MSVC ABI for long double is just double, so if rush flat out assumes it's i128, that's... broken
04:23 kherbst: types in C are just broken :p
04:24 jekstrand: Well, yeah....
04:24 kherbst: we have 2020 and there is still "int" and "long"
04:24 kherbst: ...
04:26 kherbst: hihi "pub struct _cl_icd_dispatch {"
04:26 kherbst: I think that comes in handy to start filling this struct from the begining
04:26 jekstrand: kherbst: Even though you don't have to export any other functions, you still have to return function pointers and those need the right ABI.
04:26 kherbst: pub struct _cl_icd_dispatch ;)
04:26 kherbst: we have to embed a pointer to the dispatch table into each API object anyway
04:27 kherbst: this is all part of the ICD ABI
04:27 kherbst: we have this huge struct in clover to set all the func pointers
04:27 kherbst: and if we do the same, the compiler should tell us if we mess up or not
04:27 kherbst: at least I hope
04:32 jekstrand: One would hope
04:32 kherbst: ohhh
04:32 kherbst: rust also annoys us if we redefine stuff incorrectly
04:42 kherbst: mhhhh
04:43 kherbst: I think we have to exclude all func declarations
04:47 jekstrand: ?
04:47 jekstrand: Have you come up with a good rusty name?
04:47 kherbst: it's an error in rust if you implement a declaration
04:48 kherbst: but maybe we can cheat here a little
04:49 kherbst: still need to figure out how all this visibility stuff is working out, especially with generated source files
04:53 karolherbst: everything just assumes you either want to use a C API or generate C header files, but nothing assumes you really want to implement a given C API :/
04:53 karolherbst: anyway
04:53 karolherbst: it's late
04:56 jekstrand: For you? Yeah....
12:08 karolherbst: jekstrand: it compiles \o/ https://gitlab.freedesktop.org/karolherbst/rustcl/-/blob/master/src/api/icd.rs
12:08 karolherbst: I thinks this is a good enough starting point :)
12:09 daniels: karolherbst: nice!
12:09 karolherbst: I just have no clue if that works at runtime :D
12:10 karolherbst: but the ocl-icd does some validation at some point
12:10 glennk: rusty names... IronCLad?
12:10 karolherbst: https://gist.github.com/karolherbst/29c916dbafd3be169b09681908c6a3f6
12:10 karolherbst: it's a start...
12:11 karolherbst: expected fn pointer `unsafe extern "C" fn(*const i8) -> *mut std::ffi::c_void` found fn item `extern "C" fn() {api::icd::clGetExtensionFunctionAddress}` nice :)
12:11 karolherbst: so this works indeed
12:37 karolherbst: "_get_function_addr: Function and symbol 'clGetPlatformInfo' have different addresses (0x7f27803601e0 != 0x7f278013b280)!" :/
12:58 karolherbst: ohh apparently that's harmless
13:31 uis: Hi. What faster? Draw quads or triangles? Apply per-quad data from ubo in vertex shader or in geometry? On which hardware?
13:31 uis: Using gl 3.3
13:40 uis: Or maybe do everything in geometry shader?
13:41 bnieuwenhuizen: don't use geometry shaders if you don't absolutely need to. They tend to be slower than the alternative
13:44 uis: But it faster than instancing, isn't?
13:44 bnieuwenhuizen: I don't actually know :)
13:44 bnieuwenhuizen: wouldn't be surprised if it isn't though
13:46 uis: http://www.joshbarczak.com/blog/?p=667
13:47 uis: http://www.joshbarczak.com/blog/wp-content/uploads/2015/03/graph1.png
13:56 linkmauve: uis, these don’t specify the driver nor its version. :/
13:57 daniels: it's DX
14:47 karolherbst: instanced drawing is fast on capable hw :p
14:48 karolherbst: but you wouldn't see the benefit with one invoc
14:52 karolherbst: instancing makes a difference if you can do 1 instead of 100k draw calls
14:53 karolherbst: (and already before)
14:53 karolherbst: but such analysis as shown there are just uselss
14:53 karolherbst: if there would be a "fastest way for everything" we wouldn't have such complex APIs
14:53 karolherbst: uhm
14:54 karolherbst: "one way being fastest in everything"
14:54 karolherbst: also, microbench marks sucks for decision making
14:54 karolherbst: *microbenchmarks
14:57 bnieuwenhuizen: karolherbst: I think instancing is better than separate draws, but there is some per instance overhead so if you do just a quad per instance or so (particle system) it is better to just generate a proper index buffer and use VS or GS (or use a texelbuffer + generate coords in the VS without indices)
14:57 bnieuwenhuizen: in a single draw
14:57 karolherbst: probably
14:58 karolherbst: if you can do something in one draw without instancing, sure
15:53 karolherbst: jekstrand: https://gitlab.freedesktop.org/karolherbst/rustcl/-/commit/82048704c0dac89ca9d303d2c7d16e50e308eed1
15:54 karolherbst: and the ICD picks up the dispatch table and everything :)
15:55 karolherbst: still not sure how easy it will be to split validation from implementation on the API level as the API is designed in a way that in most cases splitting it just doens't make much sense :/
15:58 jekstrand: karolherbst: Nice!
15:58 karolherbst: it's also less ugly than expected :D
15:58 karolherbst: Box::leak is gold
15:58 jekstrand: ?
15:58 karolherbst: to "leak" memory outside rusts control
15:59 karolherbst: so if we have to return memory
15:59 karolherbst: see cl_icd_get_platform_ids_khr
15:59 karolherbst: it's not even usnafe :D
15:59 karolherbst: it's essentially like a c++ smart ptrs get()
15:59 jekstrand: Oh, so it just returns the pointer?
16:00 karolherbst: yes
16:00 jekstrand: Does the box drop its reference then?
16:00 karolherbst: yes
16:00 karolherbst: and skips destructor call
16:00 jekstrand: And then you can re-box it later
16:00 jekstrand: ?
16:00 karolherbst: yes :)
16:00 jekstrand: Nice!
16:00 karolherbst: Box::from_raw
16:00 jekstrand: Yeah, that's the way to do it for heap-allocated API objects.
16:00 jekstrand: leak() on create and from_raw on destroy
16:00 karolherbst: yep
16:00 karolherbst: well
16:01 karolherbst: we should always box so we can just use it internally
16:01 karolherbst: although...
16:01 karolherbst: mhh
16:01 karolherbst: annoying
16:01 karolherbst: guess we won't have to
16:01 karolherbst: just pass a &mut around without the box
16:01 jekstrand: Yeah
16:02 jekstrand: I don't think you want to re-box every tim
16:02 jekstrand: *time
16:02 karolherbst: yeah..
16:02 jekstrand: I think rust also has a refcounted thing which might be useful for some objects.
16:02 karolherbst: I think the platform is managed by the driver anyway
16:02 karolherbst: there is no "free" API
16:02 karolherbst: maybe we can just keep a static ref somewhere
16:03 karolherbst: yeah...
16:03 karolherbst: mhhh
16:04 karolherbst: this is just the more annoying bit
16:04 karolherbst: let's see if I can do some magic with lazy_static
16:23 karolherbst: uhhhh
16:23 karolherbst: rust just makes it soo hard to do dangerous things :D
16:49 lrusak: hey guys, I'm trying to use EGLImageTargetRenderbufferStorageOES to attach a gbm_bo dmabuf via an eglimage to my framebuffer but when I render I don't see anything on the dmabuf after. I'm not sure if I'm missing something or if this isn't supposed to work this way. Code is here in the CaptureVideo method: https://github.com/lrusak/xbmc/commit/3663a002c801afbb37a0ebe368a387017a97a0c6
16:50 igorkovalenko: I see this revert https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7375 did not made it into 20.2.2 - is it because it was too late, or it needs some tag so scripts pick it?
16:50 gitbot: Mesa issue (Merge request) 7375 in mesa "r600: revert disabling llvm draw" [R600, Opened]
16:56 dcbaker[m]: igorkovalenko: it needs a tag. Either a fixes: tag for a commit in 20.2 or a cc tag for 20.2
16:57 dcbaker[m]: You can open a merge request against the staging/20.2 branch for 20.2.3
17:00 igorkovalenko: dcbaker[m]: !7315 is the merge request into 20.2 branch, it has Part-of: <!6706> but no CC tag; can this merge request be amender or do I need another one?
17:02 dcbaker[m]: Oh,I missed that was for the 20.2 branch already
17:03 dcbaker[m]: I'll pull that for 20.2.3 which is due Wednesday I think
17:04 dcbaker[m]: I had some hardware problems this week, so the releases have been delayed a bit
17:06 igorkovalenko: dcbaker[m]: I think there used to be milestones for merge requests in gitlab, seems like those are not used
17:06 igorkovalenko: dcbaker[m]: I do not think it is possible to filter merge requests by destination branch, is it?
17:08 kisak: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests?scope=all&utf8=%E2%9C%93&state=opened&target_branch=staging%2F20.2
17:14 igorkovalenko: kisak: thanks, missed that target-branch clause
18:28 daniels: lrusak: you’re missing glFinish
18:28 lrusak: daniels, ah thank you :)
18:30 daniels: lrusak: I would also use gbm_bo_import on the FB followed by the EGLImage import from the BO, rather than EGL dmabuf import
18:31 lrusak: daniels, I'm not sure I follow
18:32 daniels: lrusak: instead of DRM FB -> dmabuf -> EGLImage from dmabuf, do FB -> dmabuf -> gbm_bo -> EGLImage import from GBM BO
18:33 daniels: that works around painful GEM handle uniqueness issues
18:34 daniels: (each buffet is guaranteed to have only one GEM handle per DRM FD, so if you have the same buffer referenced through your own DRM prime import + EGL, you can end up killing the buffer too early, whilst EGL is still trying to use it)
18:36 karolherbst: jekstrand: pro tip: exclude types from generation and just make it *const instead of *mut
18:38 karolherbst: and I think we can actually do it for most objects which get shared with the runtime as all the other bits are more alloc/free driven
18:38 karolherbst: platform_id just seems an annoying exception
18:39 karolherbst: mhh, clover also only has a list of devs in the platform
18:39 karolherbst: and supported extension
18:39 karolherbst: I think this will work :)
18:40 karolherbst: anyway, it compiles
19:04 linkmauve: On GLES, is there an equivalent of GL_ARB_timer_query?
19:04 linkmauve: I’m trying to make GTK 4 run on a GLES 2.0 GPU (using Lima).
19:09 FLHerne: linkmauve: GL_ANGLE_timer_query seems to be a direct equivalent (but Mesa doesn't seem to expose it, at least on my machine)
19:10 FLHerne: Oh, GL_EXT_disjoint_timer_query, maybe? Mesa does have that
19:10 FLHerne: https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_disjoint_timer_query.txt
19:11 linkmauve: https://linkmauve.fr/files/lima-gles.txt got very few of them. :x
19:12 linkmauve: FLHerne, interesting, this extension defines the same symbols as EXT_occlusion_query_boolean.
19:12 linkmauve: (Plus some others.)
19:17 FLHerne: linkmauve: See Issues (16) if you haven't
19:18 linkmauve: Ack, I wasn’t there yet, thanks!
20:17 airlied: rusticl
20:17 airlied: karolherbst: as a name suggestion :-p
20:18 karolherbst: airlied: mhhhhh
20:18 karolherbst: airlied: let's reserve it for a sycl impl
20:23 karolherbst: mhhh
20:23 karolherbst: somehow the dispatch table is not working correctly :/
20:26 karolherbst: ohhh... :/
20:26 karolherbst: missing #[repr(C)]
20:27 karolherbst: mhh.. or maybe something else
20:27 karolherbst: ...
22:30 lrusak: daniels, will gbm allow me to import a YUV format though?
22:42 daniels: import as R8 + RG88 (or RG88 + ARGB8888) and convert in shader
22:42 daniels: the hardware almost never does it natively for you anyway
22:43 daniels: though when EGL can do it natively, GBM will allow it too
22:51 emersion: hm, i've seen it supported on intel
22:52 emersion: and rpi maybe?
22:53 karolherbst: ahhhh
22:53 karolherbst: some details in rust are really not worked out yet :/
22:54 emersion: or maybe it's just mesa doing some magic?
22:54 karolherbst: no
22:54 karolherbst: it's a plain rust project
22:54 karolherbst: a momemt.. I'll push
22:54 karolherbst: emersion: given this file: https://gitlab.freedesktop.org/karolherbst/rustcl/-/blob/master/src/api/icd.rs
22:55 karolherbst: you see those func references, right?
22:55 emersion: yeah, mesa seems to be doing some magic, since EGL advertises YUV9 YU11 YU12 YU16 YU24 YVU9 YV11 YV12 YV16 YV24 NV12 P010 P012 P016 NV16 AYUV XYUV YUYV UYVY
22:55 karolherbst: the ICD goes into a recursion
22:55 karolherbst: ohh
22:55 karolherbst: you didn't mean me :D
22:55 emersion: karolherbst: eh :P
22:59 linkmauve: karolherbst, maybe you’re missing a pub before your extern "C" fn?
22:59 karolherbst: nope
22:59 linkmauve: IIRC that’s the __visibility__((default)) of cargo.
22:59 karolherbst: it's not about visibility
22:59 linkmauve: Or whichever the syntax is.
23:00 karolherbst: I reference a function
23:00 karolherbst: I even namespaced it explicitly
23:00 karolherbst: but it still points to the ICD version of that symbol
23:00 karolherbst: see the file
23:00 karolherbst: clGetPlatformInfo is the function the ICD calls into
23:01 karolherbst: and with gdb I also see that it points to the ICD libs version
23:01 karolherbst: but the ICD also dlsyms it
23:01 karolherbst: and this works
23:02 karolherbst: but there is also this " _get_function_addr: Function and symbol 'clGetPlatformInfo' have different addresses (0x7f4c4dacf1e0 != 0x7f4c4d8aa350)!"
23:02 karolherbst: dump_platform: clGetPlatformInfo=0x7f4c4dacf1e0 [0x7f4c4dacf1e0/(nil)]
23:02 karolherbst: the last thing is the ICD dispatch table entry
23:43 karolherbst: alas some progress: https://gist.githubusercontent.com/karolherbst/837e883ff5ea4fada1b170fa6a4c578c/raw/7011b02967033bfc1c444979258dacfb34245f1b/gistfile1.txt