00:39 jenatali: Do we have any BSD or Haiku folks hanging around here? I'm wondering how important the non-ELF-TLS cases are these days. I believe I have a correctness fix which could have perf impact and I'd like to get some kind of signoff/ack if there's any stakeholders paying attention
00:40 imirkin: kallisti5: --^
00:40 imirkin: Ristovski: --^
00:41 jenatali: imirkin: Thanks!
00:41 imirkin: (for haiku and netbsd, respectively)
00:41 Ristovski: imirkin: hmm, not me sadly
00:41 imirkin: was it never you? i.e. am i misremembering? or just not up with the latest?
00:42 Ristovski: was never me :P
00:42 imirkin: hrmph. someone else with an R then.
00:42 imirkin: did you not do nouveau on netbsd?
00:43 Ristovski: imirkin: nope, I'm the guy with the cursed Haswell on Gentoo (should really donate my machine to the CI at one point >_>)
00:43 imirkin: ok. someone else with an 'r' then. my brain is mush by now.
00:43 Ristovski: heh, no worries :P
00:43 imirkin: (watch it be an 'x' or something)
00:45 imirkin: Riastradh was the username. not here though.
00:46 imirkin: i feel like i was on the right track
00:46 jenatali: Ah well, thanks anyway
00:54 Venemo: jenatali: you can always try the mailing list
00:54 jenatali: Venemo: Good point, I forgot that's a thing :)
01:11 jekstrand: jenatali: Does the SPIR-V linker de-mangle things?
01:17 jekstrand: Ugh... Maybe it's deleting inline things
01:17 jenatali: jekstrand: No, that's why we have a mangler in vtn when converting opcodes to functions
01:18 jekstrand: Yeah, looks like it's an inline getting deleted
01:18 jenatali: jekstrand: Do you have https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9085 ?
01:18 jekstrand: jenatali: Probably not. :)
01:19 jenatali: jekstrand: It is merged, so I would've expected it, but merged recently
01:20 jekstrand: jenatali: I've not rebased this branch in a while
01:20 jenatali: jekstrand: Cool, that'd probably do it then
01:21 jekstrand: Hrm... So I wonder why it's not translating write_mem_fence()...
01:21 jekstrand: I'm seeing it as a function call
01:21 jenatali: What's the full function name?
01:22 jekstrand: write_mem_fence
01:22 jekstrand: https://www.khronos.org/registry/OpenCL/sdk/1.0/docs/man/xhtml/explicitMemoryFenceFunctions.html
01:22 jenatali: Oh
01:22 jekstrand: I'm seeing that show up as a unlinked function call not a SPIR-V op
01:22 jekstrand: Translator bug, maybe?
01:24 jenatali: jekstrand: I'm not finding a SPIR-V opcode that'd correspond to
01:24 jekstrand: *sigh* SPIRV-LLVM-Translator seems to only understand mem_fence
01:24 jekstrand: It should be a MemoryBarrier
01:25 jenatali: Ugh
01:25 jekstrand: I'll file a bug
01:26 jenatali: Oh hey they finally actually have an LLVM 12.0 branch now
01:27 jekstrand: https://github.com/KhronosGroup/SPIRV-LLVM-Translator/issues/920
01:28 jenatali: Should be simple enough to fix I think
01:28 jekstrand: Yeah
01:28 jekstrand: But I'm lazy :P
01:28 jekstrand: So I'll just whack my kernel to use mem_fence() and move on
01:29 jekstrand: for now
01:31 jekstrand: I must say, it's a bit nuts watching ninja kick off N instances of my little CL compiler.
01:31 jekstrand: there is a lot of SPIR-V warning spew :)
01:31 jenatali: :P
01:31 jenatali: We should fix that... the linkage warning should really be suppressed for library SPIR-V at least
01:32 jenatali: What else are you getting besides that/
01:32 jekstrand: Groups and SubgroupDispatch
01:32 jenatali: Is Groups just from the async copy? Or something actually using groups while the compiler claims to not support it?
01:33 jekstrand: I think async copy
01:33 jekstrand: and I don't think any of these kernels actually use it
01:47 airlied: agd5f: what's up with that build failure in drm-next, is the patch broken or did some abi change?
04:53 jekstrand: Dang, if I don't zstd these pre-compiled OpenCL kernels, they're going to 2x ANV's .so size. :-/
04:54 jekstrand: Ok, with zstd, they go from 7.3M to < 1M. That's probably ok. I just need to hook in zstd.
04:55 jekstrand: Or make dcbaker do it later. :P
04:55 jekstrand: Or maybe ajax should make Fedora just zstd everything and decompress in ld.so. :-P
04:56 airlied: jekstrand: load them from somewhere else, like libclc? :-P
05:00 jekstrand: airlied: It's not libclc. It's pre-compiled BVH-building kernels.
05:00 jekstrand: They take long enough to build that I really don't want to do it on first load.
05:01 jekstrand: So into the .so they go
05:04 airlied: jekstrand: are you going to checkin the built kernels?
05:05 jekstrand: airlied: Nope. Plan is to check in the OpenCL C.
05:06 airlied: so we have to have a running clang available at build time?
05:06 jekstrand: libclang, yeah.
05:06 jekstrand: Is that a problem?
05:06 airlied: but should be fine I suppose
05:06 jekstrand: I guess I could check in SPIR-V
05:07 airlied: I think it's cross-compiling fun but should be fine for normal usage
05:07 jekstrand: It is but who seriously cross-compiles FOR x86?
05:07 airlied: yes it's unlikely to be a real problem
05:07 airlied: though I expect other might want to do the same thing later with CL C kernels
05:07 jekstrand: Yeah
05:08 jekstrand: I'm kind-of hoping that what I do will lay the groundwork for others to follow.
05:08 jekstrand: I suspect a lot of stuff could take advantage of a little OpenCL
05:09 jekstrand: And I probably don't need to compile all of them to binaries. It's only a few kernels that have serious build times.
05:16 jekstrand: Bummer... Looks like I have to wait for LLVM 13 for SPV_EXT_shader_atomic_float_min_max support. :-/
05:20 airlied: jekstrand: new intrinsic?
05:20 HdkR: jekstrand: That's rough, 12 is like...just releasing
05:21 jekstrand: airlied: Yup.
05:21 jekstrand: airlied: I've got hacks right now to handle it on older LLVM
05:21 jekstrand: So it's ok. I'll just drop them once we can rely on 13
10:30 danvet: anyone feel like reviewing my two drm/compat patches?
10:31 danvet: happy to trade for other reviews
10:44 danvet: tzimmermann, did you ever have a patch to move vgem over to shmem helpers?
10:44 tzimmermann: danvet, no
10:45 tzimmermann: i think we briefly discusse dit in one patchset's review. or something like that
10:46 tzimmermann: omg, it does all the memmgmt itself :/
10:46 danvet: tzimmermann, yeah that's why I asked :-)
10:46 danvet: imma type a patch
10:47 tzimmermann: danvet, happy to take a look at it
10:47 tzimmermann: danvet, vgem is only >800 lines. with the shmem patch, it could go to tiny/
10:49 danvet: vgem is a bit special since really it's for testing
11:55 danvet: hwentlan, [PATCH 01/11] drm/atomic-helper: Add dma-fence annotations
11:55 danvet: hwentlan, did you ever get around to test this with the new reset code in amdgpu?
11:55 danvet: would be nice to land this, and the amdgpu reset vs display fun is the big blocker for that one
12:10 esz: Hi! Hopefully the right place for a seemingly simple question: As I understand there are two "modern" ways to use OpenGL in Linux applications (when not using gui libs that wrap all this already), either link against egl and resolve all functions via eglGetProcAddress, or link against libOpenGL.so (libglvnd). Is that right? Is there a reason to prefer one over the other? And libGL.so is purely for legacy support and can be ignored, correct?
12:22 karolherbst: curro: I want to move the CL 1.2 image support a bit forward and extracted already reviewed commits: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9212
12:22 karolherbst: any concerns on landing those already or are you fine with that as well?
12:36 danvet: tzimmermann, new idea, since Greg seems to not like this hack
12:37 danvet: do not create a new _usb function
12:37 danvet: but instead use import_dev
12:37 danvet: but instead of drm_device->dev walk up the dev.parent pointers
12:37 danvet: until you find one with dma support
12:37 tzimmermann: danvet, thanks for speaking up
12:37 danvet: or give up
12:37 danvet: that should result in a patch with 0 usage of usb anywhere
12:37 danvet: and greg should be happy
12:37 danvet: plus we have this regression solved
12:37 danvet: because proper fix is going to be for 5.13 earliest
12:38 tzimmermann: danvet, we're sneaking in the bug fix :)
12:38 danvet: yeah
12:39 tzimmermann: all this is so ridiculus
12:40 danvet: yeah
12:40 danvet: it's like wtf
12:41 danvet: I also replied
12:41 danvet: tzimmermann, I'd just dupe the logic over all drivers, and not add anything to drm_prime.c
12:41 danvet: with a FIXME in each place
12:41 tzimmermann: danvet, probably the best idea for now
12:41 danvet: also cc fewer people :-)
12:42 danvet: I've also cc'ed airlied, in case he has to take some flack in the pull
12:42 tzimmermann: i need a break; will look at this tomorrow
12:45 danvet: tzimmermann, yeah take care
15:34 jekstrand: pendingchaos: I did give you a final RB on the copy-prop MR. I don't know if you notice because I didn't see the tags on your latest push.
15:34 jekstrand: karolherbst: You're back!
15:35 karolherbst: jekstrand: what do you mean? :D
15:43 jekstrand: karolherbst: I've not been able to find you on IRC lately.
15:44 karolherbst: ahh, yeah.. living between two flats and never bothered setting up a bouncer
15:45 jekstrand: Ah. That'll do it.
15:46 mripard: if anyone is interested, I've been writing a Rust library to support atomic mode-setting
15:46 mripard: https://github.com/mripard/nucleid
15:46 mripard: it's still in its very early stage, so if you have any feedback, please shoot :)
15:48 emersion: how much abstraction do you intend to provide?
15:51 mripard: I'm not sure it can be easily quantified, but low-level enough to expose the states and objects, while remaining convenient to use
15:55 karolherbst: now I had network foo :)
15:55 linkmauve: mripard, how much overlap with libliftoff would you want? ^^
15:55 linkmauve: I think that’d make it very useful.
16:01 mripard: linkmauve: it's not really clear to me what libliftoff aims to provide from the initial introduction or the current repo
16:02 mripard: the initial blog post by emersion seems to hint that there might be some policy decision involved?
16:02 emersion: yes
16:02 mripard: in which case, I'm not really interested in that, it should be as policy-agnostic as possible (and we can always build another library on top if someone really is interested)
16:03 emersion: makes sense
16:03 mripard: otherwise, there's definitely some overlap with the way objects, properties and so on are represented
16:04 emersion: my only recommendation would be, aim to do a better job than libdrm
16:04 emersion: shouldn't be too ahrd tbh
16:04 emersion: hard*
16:04 emersion: also better helpers to deal with KMS props
16:05 linkmauve: mripard, are you aware of the drm crate btw?
16:05 linkmauve: It does basically similar things to libdrm, with fewer allocations IIRC.
16:06 linkmauve: Doesn’t yet support no_std, that’s something you may be interested in.
16:09 emersion: btw, ideas to improve libliftoff's description are welcome
16:11 mripard: linkmauve: drm-rs is a wrapper around libdrm, and I didn't really want that
16:12 mripard: the first one is that I'm working fairly often with embedded/minimal systems, and getting libdrm in those is often inconvenient
16:13 mripard: the second one is that I was aiming at providing something better than libdrm like emersion suggested :)
16:13 mripard: so I didn't really need libdrm, and didn't really want it either
16:14 linkmauve: mripard, IIRC it uses the libdrm headers to not have to redefine everything, but other than that it uses pure syscall()s itself.
16:14 linkmauve: Unless that changed since I last had a look.
16:16 mripard: https://github.com/rusty-desktop/libdrm-rs/blob/master/src/ffi/xf86drm_mode.rs#L369
16:16 mripard: it seems to be calling into C code there
16:18 emersion: oh no, it still uses the name xf86
16:19 linkmauve: mripard, I’m talking about this crate: https://github.com/Smithay/drm-rs
16:19 linkmauve: libdrm-rs indeed seems to be just a binding to libdrm, as the name implies.
16:19 linkmauve: As well as not being maintained for four years.
16:20 emersion: if you ever need a Go equivalent, there is https://git.sr.ht/~emersion/go-drm :P
16:33 esz: anyone can help me out with my question above? Or should I rather ask on mesa-users ML?
16:37 ajax: esz: it's not entirely defined, unfortunately
16:37 esz: what, my question? Or the answer :)
16:38 ajax: esz: we (as in khronos and/or the fdo glvnd group) should really update the opengl abi spec for linux
16:39 ajax: the intent is that it works like this: https://www.x.org/wiki/Events/XDC2014/XDC2014RitgerGLABI/presentation-xdc2014.pdf
16:40 ajax: where you have libGLX or libEGL for your window system, and libGLES_v[12] or libOpenGL for your rendering API, and you link against the one(s) you want
16:40 ajax: and then libGL is a compatibility layer that is backed by libGLX + libOpenGL
16:41 esz: I had good success so far not linking against any gl lib, but just linking against libegl, and resolving all functions via getProcAddress
16:42 ajax: that should be fine, yes
16:42 esz: so I was wondering what the use case for directly linking the app to either libOpenGL or libGLES was
16:43 esz: given that I see still a lot of applications linking against those
16:43 esz: I suppose one would do that if one wants to skip the legwork of manually resolving the functions
16:43 ajax: i think there's an efficiency reason
16:44 esz: though when someone uses something like glew or glad, those basically emulate what the linker would do. At least I don't see a big efficiency disadvantage over linking
16:46 ajax: i think there's also a historical reason where some older egl versions specifically said you can't use eglGetProcAddress to resolve things in the egl core, just extensions
16:47 ajax: which was: dumb
16:47 ajax: and which a bunch of people just went ahead and ignored, egl vendors that is, but then apps had to be paranoid about it anyway
16:48 ajax: it's funny, for a 28 year old API, OpenGL keeps making some really boneheaded API design mistakes
17:07 imirkin: zmike: there's no good reason that builtin-gl-sample-mask should be flaky. there's some issue in your impl. or in llvmpipe.
17:08 esz: ajax: well, as long as it works of reasonably modern mesa that is good enough for me. Thanks for the info!
17:17 zmike: imirkin: the tests have been passing on a conformant implementation (which lavapipe isn't) for 6+ months, so I'm just not super interested in looking further into that right now when I still have 400+ patches remaining in my branch
17:21 mripard: linkmauve: ah, my bad
17:23 imirkin: zmike: ok. does airlied know?
17:24 imirkin: airlied: --^
17:24 imirkin: he does now!
17:24 zmike: imirkin: yes, we're working together very closely on zink+lvp in ci
17:24 imirkin: ah cool
17:27 mripard: linkmauve: from the example, I'd like to have a higher level abstraction though
17:29 linkmauve: Cool. :)
17:40 mripard: but yeah it does look like it's pure rust
17:47 imirkin: mripard: as you're probably aware, the challenge is that lots of hardware has very different capabilities. hard to enable using hw to full extent while maintaining high-level abstractions.
18:06 mripard: imirkin: yeah, that's a bit why I wanted to avoid any policy, because one that could work fine on one hardware / use-case might very well be suboptimal on another
18:07 mripard: but the abstraction I aimed at was to basically provide a convenient way to manipulate whatever is already exposed by libdrm
18:07 mripard: so you still have the notion of requests, connectors, planes, framebuffers and so on
18:10 imirkin: mripard: ah ok. so same thing as libdrm, but just more language-friendly
18:11 mripard: yep
18:12 mripard: and if someone has a more opiniated view on this, we can always build another library on top
18:32 airlied: zmike: btw the areas where lvp isnt confornant is like 10 tests, mostly kine rendering
18:33 zmike: something to look into for sure
18:33 airlied: you can treat it as conformant or nearly everything
18:33 zmike: good to know
18:33 airlied: i have a conformant branch
18:34 zmike: as in one you submitted or one with extra changes
18:34 airlied: just a few extra messy changes
18:35 zmike: cool, maybe I'll check that out for local testing
18:35 airlied: it shouldnt affect zonk at all
18:35 airlied: zink
18:36 airlied: since gl line renderihg cant use vulkan line rendering
18:38 zmike: I'm looking into setting up a cron job to run things on my branch overnight, so it's good to know any things to be looking out for 👍
18:39 zmike: though it seems today I've gotten ajax syndrome and now all the xfb tests Must Be Fixed
18:40 airlied: the only other busted thing I nkow about is point rendering issues, again unlikely to be a major issue
18:41 airlied: zmike: so really consider lavapipe as conformant as most other things from the pov of zink testing
18:41 zmike: awesome
18:41 zmike: TIL
18:44 zmike: also with the added benefit of not hanging my desktop session
18:51 daniels: zmike: you can define timed gitlab ci pipelines btw
18:52 airlied: zmike: I'll look at sample mask later to see if I can reproduce
18:52 zmike: daniels: that's pretty cool, but I feel like I'm not doing my duty if I don't create my own bespoke infrastructure component that I can blame whenever anything isn't working
18:53 zmike: airlied: oh awesome, thanks! actually not sure what's going on there given that nearly all the tests are skipped except a couple which randomly flip
18:55 airlied: karolherbst: btw we don't handle 1d image buffers properly in clover at all
18:55 karolherbst: airlied: what do you mean?
18:56 karolherbst: you mean like 1d buffer images or 1d images in general?
18:57 airlied: karolherbst: 1d buffer images
18:57 karolherbst: for that I have other patches
18:57 airlied: in C++ object violating patch form, https://paste.centos.org/view/70575644
18:58 airlied: one bug is the image data needs to be initialised from the buffer data,
18:58 airlied: the other is gallium doesn't specify buffers with formats
18:58 karolherbst: is that on top of !7241 ?
18:58 airlied: karolherbst: somewhere on top of it, my branch is a bit of a mess
18:59 karolherbst: okay
18:59 karolherbst: but yeah.. could be that all of that doesn't work correctly
18:59 karolherbst: hence why I created https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9212 to at least land stuff I am sure is correct :D
18:59 airlied: the gallium bits I don't care so much about, as I understand that, the C++ object interaction is probably something that I'd prefer to review than write :-P
19:00 karolherbst: sure
19:00 airlied: it at leasts fixes the test I was running
19:00 karolherbst: thing is, when I was doing tests it all worked just fine
19:00 karolherbst: ahh
19:00 karolherbst: lp
19:00 karolherbst: ?
19:00 karolherbst: anyway, once I get to cleaning up the other patches, I can look into it
19:00 karolherbst: still have to fix.. 3d images on nouveau for real
19:00 karolherbst: some corner cases producing wrong results
19:01 karolherbst: very annoying
19:01 imirkin: karolherbst: try reproducing with the texelFetch tests
19:01 imirkin: just hack the GL to set unnormalized coords to true on the sampler
19:01 airlied: the failing tests was images/samplerlessReads
19:01 karolherbst: airlied: ohh.. mhh
19:01 karolherbst: sampleress.. right
19:02 imirkin: oh
19:02 imirkin: texelFetch doesn't use a sampler at all
19:02 karolherbst: imirkin: it's unrelated
19:02 imirkin: (although it sorta does on hw, in various confusing ways)
19:02 airlied: karolherbst: but I have to rewrite shader_info's textures_used code
19:03 karolherbst: airlied: could be
19:03 karolherbst: why though?
19:03 karolherbst: I'd just change clover behaving more like st/mesa
19:03 airlied: textures_used is a 32-bit bitfield
19:03 karolherbst: uhhh
19:03 karolherbst: crap
19:03 airlied: and opencl has 128 sampler views
19:03 karolherbst: this annoying bit
19:03 jenatali: CL requires 128, yeah
19:03 karolherbst: yeah.. we have this with d3d9 as well
19:03 imirkin: jenatali: DX10 does too right?
19:03 jenatali: Yeah
19:03 airlied: CL also requires 64 images which might be an issue
19:03 karolherbst: yep
19:03 jenatali: Yep
19:03 karolherbst: looking into it once we get there :D
19:04 airlied: we also need to possibly add a samplers_used
19:04 imirkin: nvidia'd DX10 hw has 128 views and 16 samplers
19:04 karolherbst: for now I'd like the basic functionality to work at least
19:04 airlied: since for GL they are the same thing
19:04 airlied: but not for CL
19:04 karolherbst: CL is.. special
19:04 karolherbst: it's also about created, not bound sampler states, no?
19:04 airlied: well gallium also splits those thing
19:04 airlied: NIR just hasn't caught up
19:04 karolherbst: nir also supports it
19:04 imirkin: we really should use linked tsc's -- that'd allow us to use more textures. o well.
19:04 karolherbst: more or less
19:04 jenatali: airlied: Are you sure it's 64? D3D11 only supported 8 in its first go-around, I'd be surprised if CL needed 64
19:04 airlied: imirkin: it does but badly
19:05 imirkin: airlied: hm?
19:05 karolherbst: jenatali: yeah, that's not correct
19:05 karolherbst: CL terminology is... wrong
19:05 karolherbst: wait.. I have it nicely written down
19:05 airlied: "Max number of image objects arguments of a kernel declared with the write_only qualifier. The minimum value is 64"
19:06 airlied: "Max number of image objects arguments of a kernel declared with the read_only qualifier. The minimum value is 128 if CL_DEVICE_IMAGE_SUPPORT is CL_TRUE, "
19:06 airlied: "Maximum number of samplers that can be used in a kernel.
19:06 airlied: The minimum value is 16 "
19:06 karolherbst: jenatali: https://gitlab.freedesktop.org/karolherbst/mesa/-/blob/rusticl/src/gallium/frontends/rusticl/core/device.rs#L135
19:06 karolherbst: airlied: ^^
19:06 airlied: are the 3 lines I've read :-P
19:06 karolherbst: airlied: write images are images, not samplers :p
19:06 airlied: imirkin: textures_used in shader_info is a bit ambiguous when it comes to samplers vs sampler views
19:07 airlied: karolherbst: yup so 64 write images
19:07 airlied: what I said
19:07 imirkin: airlied: yes, completely.
19:07 airlied: 128 sampler views, 64 images, 16 samplers
19:07 karolherbst: ohhh
19:07 karolherbst: right
19:07 jenatali: Huh, guess I forgot. Cool
19:07 imirkin: airlied: but for GL, linked mode is perfectly fine.
19:07 airlied: also TGSI has a bunch of 32-bit fields
19:07 imirkin: except when you get to bindless or so
19:08 airlied: and since I translate my shader info into TGSI shader info for llvmpipe I also run into a bunch of problems
19:08 karolherbst: imirkin: I can implement the other mode :p
19:08 karolherbst: just didn't get to it yet
19:08 karolherbst: it's... not complicated
19:08 airlied: so I maybe to have to plumb non-TGSI shader info paths into llvmpipe a bit further
19:08 karolherbst: just need a little rewrite
19:08 karolherbst: *needs
19:08 imirkin: karolherbst: linked tsc mode? yeah, it's not *hard*, just ... needs small changes all over
19:08 karolherbst: yep
19:09 karolherbst: and getting the descriptor right
19:09 karolherbst: for fun reasons, volta+ has 3 different bindless modes
19:09 imirkin: lol
19:09 karolherbst: yep
19:10 karolherbst: it all makes sense
19:10 karolherbst: just annoying
19:10 karolherbst: one can be used for indirect GL samplers
19:10 karolherbst: so you don't have the index indirect, but just feed the sampler address and static texture
19:13 karolherbst: and then you have the reverse, texture address but static sampler
19:13 karolherbst: oh well...
19:14 karolherbst: not sure if we should make use of any of those "mixed" modes
19:14 karolherbst: dunno how much that would help
19:35 anholt: oh, wow. git noticed on rebase that I was adding a file to a dir that had been moved, and preemptively moved it for me. so nice.
19:35 karolherbst: yep
19:35 karolherbst: just think about working with SVN again
19:37 yshui`: actually git doesn't have a concept of moving files. it just compare files and consider similar files as moved
19:39 anholt: I know, the thing I'm noting is that it has at some point gained the idea of moving a directory, not just individual files, and that's great.
19:41 imirkin: zmike: just looking at you ci change. in the subject you say gl33, but in the actual change you do gl32. pointing out in case it was a mistake.
19:41 imirkin: oh. actually anholt's change. i presumed.
19:41 anholt: oops, yeah. gl33 support was incoming in another MR and I got them mixed up.
19:41 yshui`: anholt ah i see. yes that's pretty cool
20:10 onox: what determines which zwp_linux_buffer_params_v1@3.add calls are executed by eglSwapBuffers()? does it depend on the EGLConfig object?
20:25 emersion: also depends on the formats supported by the compositor
20:25 kallisti5: imirkin: jenatali: sorry, i've been preoccupied for a bit. "Do we have any BSD or Haiku folks hanging around here? I'm wondering how important the non-ELF-TLS cases are these days. I believe I have a correctness fix which could have perf impact and I'd like to get some kind of signoff/ack if there's any stakeholders paying attention"
20:26 kallisti5: I don't have enough info to make a call there. Do you have a patch somewhere related to it?
20:26 imirkin: jenatali sent email to the list with a more detailed question
20:26 imirkin: which ended up in spam for me due to DMARC failure
20:26 kallisti5: i'll take a look. Thanks!
20:26 jenatali: DMARC failure?
20:27 imirkin: could be lists.fd.o fail, or could be forwarding on my end fail.
20:27 imirkin: jenatali: yeah, DMARC is really not meant to be used with mailing lists
20:27 jenatali: Huh. Never heard of it
20:27 HdkR: "Gmail could not verify that it actually came from microsoft.com. Avoid clicking links, downloading attachments, or replying with personal information"
20:27 HdkR: Same, went to spam
20:27 imirkin: jenatali: basically authenticating that an allowed IP address sent an email
20:27 imirkin: like SPF
20:28 imirkin: but more better
20:28 imirkin: i believe the workaround is for the mailing list to not "forge" the sender
20:28 imirkin: but that causes various other annoyance
20:29 imirkin: daniels: am i imaginging things, or did you have some sort of dmarc-list of domains which have dmarc enabled, and do something diff for them?
20:35 jenatali: Huh, yeah I see that on my own bounced back copy. Interesting. Guess that's what I get for using such a well-known email sender domain :)
20:35 imirkin: jenatali: well, it's based on the domain config - you have DMARC configured in dns
20:36 imirkin: _dmarc.microsoft.com descriptive text "v=DMARC1; p=reject; pct=100; rua=mailto:d@rua.agari.com; ruf=mailto:d@ruf.agari.com; fo=1"
20:37 daniels: imirkin: we used to, but then we nixed it after we saw delivery attempts come way back up
20:37 imirkin: wow, harsh. p=reject is supposed to reject it at the SMTP level
20:37 daniels: emersion is the mail man now however
20:37 imirkin: which gmail obviously doesn't do
20:39 daniels: we asked gmail for special consideration of our need to forge identity and perform sender explosion on an industrial scale; they said they wouldn't do it as that's not something they do for anyone, however shortly afterwards our delivery success rate vastly increased
20:42 Venemo: jenatali: what do you use for editing the Mesa code BTW? Is it vscode or do you have something better?
20:43 imirkin:hopes the answer is 'emacs'
20:43 kallisti5: vim is the correct answer
20:43 jenatali: Venemo: I use full VS for Windows, and VSCode with WSL remote for Linux
20:43 kallisti5: or vi if you're a heathen
20:44 mattst88: nvim + ccls here :)
20:44 kallisti5: Text editors are text editors is the point. I'd personally use github's atom editor if I was forced into using Windows / Mac... but I would be using the vi / vim keyboard emulation.
20:45 Venemo: jenatali: did you ever get vscode to actually build mesa?
20:46 jenatali: Venemo: What I've done for VSCode was manually configure meson for ninja first, then point VSCode at compile_commands.json for intellisense, then use the integrated terminal to rebuild things
20:46 emersion: DKIM can work just fine with mailing lists, if the mailing doesn't add a silly footer to all messages
20:46 Venemo: jenatali: yeah, that's what I do too. I was hoping you knew something cooler :)
20:47 emersion: there is ARC that can work around that, but requires the recipient to trust fd.o
20:47 jenatali: Venemo: Nah. For Windows I use the vs2019 backend from meson which integrates nicely with the IDE build
20:47 emersion:still needs to set it up…
20:48 imirkin: emersion: hm, interesting. just noticed that the body hash is what's failing
20:48 Venemo: jenatali: sounds good, but I don't use Windows. I'm mostly happy with vscode, the only thing that bugs me is that it sometimes just gives up and needs to be restarted
20:48 imirkin: i sorta assumed it was a "sender not allowed" sort of thing, but it's not
20:48 emersion: yeah, the ML changes the body, so it breaks DKIM
20:48 imirkin: i don't suppose we could, like, not do that?
20:49 emersion: another ML service that i maintain, lists.sr.ht, doesn't break DKIM
20:49 jenatali: Venemo: Haven't seen that, but I'm also not running the Linux client, I'm running the Windows VSCode and just remoting it to a Linux VSCode server
20:49 emersion: we've talked about it, but daniels is concerned about GDPR
20:50 emersion: the message header also contains a link to unsubscribe
20:50 emersion: but it's not 100% clear it's enough
20:52 mattst88: what's the connection between the mailing list footer and GDPR? (/me is clueless about GDPR)
20:52 imirkin: emersion: what's the penalty? like 5% of revenue? does fd.o really have that much revenue? :)
20:52 emersion: lol
20:53 emersion: mattst88: the footer has a link to unsubscribe
20:53 emersion: i think?
20:53 emersion:checks
20:53 emersion: yeah
20:53 emersion: well
20:53 emersion: it's a link to the ML web page
20:53 clever: is there a simple way to test what % of the 3d core is being used at any given time? other then profiling the relevant kernel functions?
20:54 clever: i'm wanting to get a gpu usage% figure
20:54 emersion: which has a form to unsubscribe
20:54 imirkin: clever: how would you profile the relevant kernel functions?
20:54 imirkin: to obtain such a percentage
20:54 clever: imirkin: the answer ive seen before is to use something like kernel tracing probes, to capture the enter/exit timestamps for something that runs a given shader job
20:54 clever: but that just feels too hacky
20:55 imirkin: how does that get you percent utilization?
20:55 clever: i assume that the function is blocking, and wont return until the gpu has finished rendering the frame
20:55 imirkin: sure
20:55 imirkin: well
20:55 imirkin: normally a GPU is fed a FIFO of commands
20:55 imirkin: you want as much async as possible
20:56 clever: in the case of the 3d core of the rpi, you give it a control list that says how to render an entire frame
20:56 clever: but you can only have one list being executed at a time (per type, binning and rendering)
20:56 imirkin: clever: ok, but it's not like you wait on the CPU for that to finish
20:56 clever: the completion irq would then schedule the next one
20:56 mattst88: emersion: oh, and the GDPR requires an unsubscribe link or something like that?
20:56 clever: if one was pending
20:57 imirkin: mattst88: nobody knows what the GDPR requires in practice.
20:57 imirkin: it requires lots of wishy-washy things
20:57 mattst88: heh, okay
20:57 clever: imirkin: depending on the api, you may have a blocking function, that waits for the irq to un-block things
20:57 imirkin: there have only been a handful of court cases
20:57 robclark: imirkin: drm/msm has tracepoints on submit flush/retire (with timestamps captured on CP).. which will give you utilization.. but ofc it is a driver specific thing
20:57 clever: ive not tried that method yet, because i wanted a better option
20:57 emersion: mattst88: yeah, not clear either
20:58 imirkin: robclark: do you not just have a fifo of commands?
20:58 robclark: current things are a single ring, if that is what you are asking?
20:58 imirkin: so don't you just dump stuff onto the ring
20:58 imirkin: which then executes however it executes
20:59 imirkin: anyways, my point is that "utilization" is a very awkward thing to measure
20:59 clever: do you get completion events as things in the ring finish?
20:59 robclark: well, from the ring we dump timestamps into a separate ringbuffer of captured timestamps.. that is used to measure utilization for devfreq
20:59 daniels: emersion, imirkin: it's not GDPR which requires us to do one-click unsub, it's other laws e.g. the US 'CAN-SPAM' act. I have no objection to removing it you tell me you have confidence that us doing so isn't going to get us in hot water
21:00 robclark: yes, there is an irq.. although the timestamps captured from gpu are more accurate
21:00 anholt: for rpi you should be able to use gpu-scheduler timestamps to track busy, same as msm.
21:00 imirkin: daniels: yeah, i was thinking of CAN-SPAM as well. but that's for non-solicited mail
21:00 anholt: I think I had at times also used some hokey sampling of debugfs files.
21:00 imirkin: daniels: if you can provide a record of them soliciting mail, i don't think it's an issue. ianal :)
21:00 anholt: sadly, no gpu-generated timestamps in rpi land :(
21:00 emersion: daniels: CAN-SPAM seems to only include "electronic mail message the purpose of which is the commercial advertisement or promotion of a product or service"
21:01 daniels: you can argue that Mesa/Wayland/etc are a product ...
21:01 emersion: see https://www.ftc.gov/tips-advice/business-center/guidance/can-spam-act-compliance-guide-business
21:01 daniels: it explicitly _excludes_ personal and transactional messages, which we aren't clearly so
21:01 clever: anholt: i can see a way to get lower jitter to the timestamps, if the VPU also double-handles it, but it may record the same irq multiple times, if arm is late to ack
21:01 daniels: I feel like we fall into a grey area
21:02 emersion: daniels: that's the definition of "commercial messages"
21:02 clever: what about with the "amdgpu" driver? does that one record timestamps?
21:02 daniels: and we certainly get quite a lot of false subs, e.g. for the lists I'm the admin contact on I get a lot of confused messages from people on Yahoo or whatever who have been subscribed against their will, because if they actually wanted to be on a dev list then they'd definitely understand how to click through and unsubscribe
21:03 daniels: again, if the headers do enough that you feel we're not going to be in violation of something awful, then I'm glad to set fire to the footers and never see them again
21:03 emersion: "List-unsubscribe is generally regarded as a best practice for fulfilling CAN-SPAM element number 5."
21:03 emersion: https://sendgrid.com/blog/list-unsubscribe/
21:04 clever: robclark: is there an example of how to enable those tracepoints?
21:04 emersion: not an official resource, but sendgrid is pretty well-known
21:06 robclark: clever: https://chromium.googlesource.com/chromiumos/platform/debugd/+/refs/heads/main/src/helpers/systrace.sh .. catapult (ie. chrome://tracing) on a non-ancient chromium knows how to decode them as well..
21:06 robclark: so something like `./systrace.sh start all; sleep 5; ./systrace stop > mytraces.txt`
21:07 robclark: hmm, maybe I linked to an old version.. one sec..
21:07 clever: yeah, that doesnt seem very resource friendly
21:08 clever: i'll poke around in that area in a bit, need to get something else done first
21:08 robclark: clever: https://chromium.googlesource.com/chromiumos/platform2/+/refs/heads/main/debugd/src/helpers/systrace.sh
21:09 clever: it seems fairly simple to just add the delta of start&end to a global counter, and expose it somewhere
21:09 clever: then i can just graph the rate its increasing at
21:09 clever: but i'll also need to exclude time spent in queue, i'll dig around in the source...
21:12 robclark: jenatali: hmm, if I'm understanding properly meson.build, it looks like some android versions use !elf-tls path as well..
21:13 jenatali: robclark: Oh yeah, I forgot about older android versions. I guess I assumed that old meant not used as much
21:14 robclark: I'm just double checking what abi we are building for but I suspect it is the one before elf-tls gets turned on
21:15 jenatali: If that's the case, it'd be great to get your feedback too :)
21:16 robclark: hmm, looks like -DANDROID_API_LEVEL=28
21:16 robclark: but yeah, I guess I should look more closely at that
21:18 robclark: yeah, we are defn not using -DUSE_ELF_TLS
21:20 jenatali: robclark: I don't really have a clear picture on what kind of perf impact it'd have, but if you wanted to run an API-overhead benchmark I'd be interested in the results. It should be minimal
21:21 robclark: hmm, but apparently android has an emultls thing? Not sure what that is
21:22 jenatali: robclark: When the USE_ELF_TLS was renamed to what it is, I think emultls was explicitly called out as not sufficient
21:22 robclark: jenatali: yeah, I suppose I can run gfxbench driver-overhead with a hack to not be actually a CP overhead benchmark.. I guess in the end it probably won't matter too much since you don't see a log of glBegin()/glEnd() stuff (I don't think we even ship gles1)
21:27 ajax: so, props to whoever wired up piglit html output to the ci artifacts
21:27 ajax: now if only i knew why this test was crashing
21:27 ajax: because it sure isn't crashing for me locally
21:30 anholt: something where running against an xvfb instead of your main x server could matter?
21:33 ajax: maybe. except it works against xvfb and xephyr...
21:39 robclark: jenatali: well, I *think* if it were really a problem for us we could write code to add emutls support..
21:40 jenatali: robclark: Good point
23:40 alyssa: zmike: https://rosenzweig.io/0001-glsl-Allow-int16-loop-iterators.patch Something like this is needed I think
23:40 zmike: uhhhh float doesn't sound right to me?
23:41 zmike: but I guess all the int sizes should be covered
23:41 zmike: err maybe I'm out of context
23:42 zmike: ah
23:42 zmike: yeah, that looks right 👍