01:54 bl4ckb0ne: wow i wasnt expecting drm debug output to be 1500 lines long
02:18 alyssa: jekstrand: relevant case we handle in the backend scheduler (courtesy of icecream95) -- we can't reorder e.g. load_shared related to store_shared, but we *can* reorder *_shared related to *_scratch [likewise *_ssbo/*_global under certain possibly-architecturally-defined assumptions]
02:19 alyssa: I don't know if NIR would benefit from modeling that correctly, though.
02:22 airlied: anholt: asan says I have to rewrite lvp descriptor layout handling :-(
02:23 alyssa: I like asan
02:24 HdkR: Me too
02:24 airlied: vulkan has a descriptor set layout object, and apperently it's lifetime is not what I expected of it :-P
02:25 alyssa: airlied: You can't have a use-after-free if you never free memory 🙃
02:27 bnieuwenhuizen: airlied: what did you expect of it?
02:27 bnieuwenhuizen: and what is it in practice?
02:27 airlied: bnieuwenhuizen: I thought it was like everything else, once you use it you can't kill it until every object usihng it is finished
02:28 Plagman: wasn't there another instance of layout lifetimeconfusion recently? maybe dxvk related
02:28 airlied: but once you care a pipeline layout with it you can destroy it
02:28 bnieuwenhuizen: Plagman: Baldurs Gate 3 had that in ~Nov
02:28 alyssa: womp-womp
02:28 Plagman: ah yes that
02:28 Plagman: thanks!
02:28 airlied: yeah there is a CTS test for it
02:28 bnieuwenhuizen: which test?
02:28 airlied: but of course it needs asan or something to tell you it's failing for real
02:28 bnieuwenhuizen: the BG3 behavior turned out to be actually invalid
02:29 bnieuwenhuizen: so I'm happy at taking a stab at the CTS being wrong
02:30 alyssa: is working around app bugs in vk drivers frowned upon? (versus GL)
02:30 alyssa: I assume so given the philosophy around vk but what do i know
02:30 bnieuwenhuizen: not fun but sometimes needed
02:31 airlied: bnieuwenhuizen: https://gitlab.khronos.org/Tracker/vk-gl-cts/-/issues/856
02:31 bnieuwenhuizen: the advantage of vulkan is that we don't need to have a GLSL compiler
02:32 airlied: though I need to read the spec to figure it out
02:32 bnieuwenhuizen: which is probably like 2/3rd of the mesa GL app workarounds
02:32 alyssa: oh, true
02:35 bnieuwenhuizen: airlied: hmm, I suspect we get that one wrong too with radv ...
02:38 alyssa: https://gitlab.freedesktop.org/mesa/mesa/-/blob/master/src/compiler/nir/nir_divergence_analysis.c#L478-485
02:39 alyssa: Any reason we don't just drop the default and let -Wswitch kick in?
02:39 alyssa: Wait, duh, vendored intrinsics by venors that don't need divergence analysis
02:39 alyssa: i need to go to sleep and stop saying silly things
02:39 alyssa: sorry
02:42 airlied: bnieuwenhuizen: I glanced at radv and it didn't seem to suspectible
02:46 bnieuwenhuizen: airlied: we still use the set layout in the pipeline layout to compile our shaders, no?
02:46 bnieuwenhuizen: so if the set layout gets destroyed before pipeline creation ...
02:47 airlied: valgrind on dEQP-VK.api.descriptor_set.descriptor_set_layout_lifetime.compute might show it
02:48 bnieuwenhuizen: doesn't ...
02:48 airlied: bnieuwenhuizen: Invalid read of size 4
02:48 Peste_Bubonica: bnieuwenhuizen, i've run a game benchmark with and without resizeable bar enabled
02:49 Peste_Bubonica: with the same settings, i've got ~5.500 points with resizeable bar enabled, and 8400 disabled
02:49 airlied: bnieuwenhuizen: naybe it got fixed
02:49 bnieuwenhuizen: airlied: ah found it in a debug compile, happens here too
02:50 Peste_Bubonica: World War Z, a native vulakn game (run with wine)
02:50 bnieuwenhuizen: time to refcount all descset layouts?
02:52 bnieuwenhuizen: Peste_Bubonica: what CPU&GPU&mesa version?
02:53 DrNick: alyssa: AMD does some of their workarounds in layers that get implicitly loaded, so that's neat at least
02:54 bnieuwenhuizen: DrNick: IIRC most of those are performance hacks, not invalid API behavior workarounds
02:55 airlied: but maybe refcnt is enough
02:55 DrNick: I could've sworn one of them was actually bugfixing but now that I'm looking at them, they're removing unnecessary barriers and doing work in background threads
03:05 airlied: jekstrand: any idea if you suffer from that as well?
03:05 airlied: bnieuwenhuizen: I do wonder if the spec could just be clarified to say they have a lifetime
03:05 bnieuwenhuizen: feel free to file a spec bug, but the language seems fairly explicit?
03:06 airlied: the language seems non-existant or else I can't find it :-P
03:06 bnieuwenhuizen: 3.3.1
03:07 airlied: doh I was looking in the free descriptor set layout code
03:08 airlied: ah yes it makes sense then
03:24 jekstrand: airlied: We refcount them. :)
03:25 jekstrand: airlied: It's one of two things we refcount in the entire driver.
03:25 airlied:goes to steal refcounting
03:25 bnieuwenhuizen: jekstrand: the other being?
03:26 jekstrand: bnieuwenhuizen: We also refcount anv_shader_bin, our thing that represents a shader binary.
03:26 jekstrand: One of these days, I'm going to make it so we don't refcount descriptor set layouts
03:27 bnieuwenhuizen: no bo cache/suballocation yet?
03:27 jekstrand: bnieuwenhuizen: No, the app's supposed to do that. :-P
03:27 bnieuwenhuizen: jekstrand: well, sometimes it is beneficial for driver internal stuff, say a cmdbuffer or an event
03:28 jekstrand: bnieuwenhuizen: Well, yeah, we sub-allocate for events etc.
03:28 jekstrand: bnieuwenhuizen: We sub-allocate for all sorts of driver internal stuff
03:28 jekstrand: Not command buffers, at least not today. But other stuff.
03:28 jekstrand: We've got all sorts of little bits of state that are pointers in the HW packets.
03:29 bnieuwenhuizen: and you're not just putting them in the cmdbuffer and then skipping over it?
03:29 bnieuwenhuizen: (or like radv have 1 cmd buffer and 1 upload buffer per vulkan cmd buffer)
03:30 jekstrand: They come from different base addresses, sadly.
03:30 Peste_Bubonica: bnieuwenhuizen, R7 3700x // Mesa 21.1.0 (Commit: 13f92183c7dbff9d76a83656862d0b2c2536e25d)
03:30 Peste_Bubonica: GPU: Radeon 5700XT
03:30 jekstrand: state management in ANV is unfortunately complicated.
03:31 jekstrand: And, also unfortunately, all the complexity is 100% necessary.
03:31 bnieuwenhuizen: :(
03:31 Peste_Bubonica: bnieuwenhuizen, even mesa 20.3.4 was almost 10% slower with BAR enabled in BIOS
03:31 Peste_Bubonica: strange dont you think?
03:36 mareko: refcounting with atomics is great if you want your CPU overhead to be high
03:37 jekstrand: mareko: This is why we never refcount on the hotpath.
03:38 jekstrand: We have one atomic on the hotpath. It's for command buffer BO allocation and it's one atomic per 8K of batch.
03:39 jekstrand: I guess there are also some for state allocation, potentially. But, again, it's amortized out.
03:40 mareko: good for you
03:42 mareko: gl is a refcounting hell
03:42 jekstrand: Yeah, it is
03:42 zmike: that reminds me, I found a refcounting bug in core mesa yesterday related to xfb
03:42 zmike: is it worth filing a ticket or is that firmly in the realm of nobody cares
03:43 mareko: I care
03:43 zmike: ok
03:44 jekstrand: Speaking of random things in GL, I keep meaning to play with getting rid of hash maps for object lookup....
03:44 jekstrand: But convincing myself to care about GL enough to spend multiple weeks on it is hard. :-/
03:45 mareko: there is u_idalloc that might be faster?
03:45 jekstrand: util/sparse_array.h
03:46 jekstrand: It's a growing array that auto-allocates more space as needed.
03:46 mareko: for GL we also need to generate the lowest unused ID for some apps
03:46 jekstrand: Should be doable.
03:46 jekstrand: I looked into it a while ago, I just never sat down and worked out all the details.
03:47 jekstrand: IIRC, we should be able to do no worse than the current hash map
03:47 jekstrand: And lookups should be faster.
03:47 jekstrand: Also, no locking. :)
03:47 mareko: no locking is good
03:48 jekstrand: It's a N-ary tree data structure that's updated with atomics so you never have to lock to add space.
03:48 jekstrand: You can control the depth of the tree by controlling the node size.
03:48 jekstrand: If we set it with a node size of, say 1024, we'd basically never have a tree more than 2-deep.
03:49 jekstrand: So you can start with an empty array and call util_sparse_array_get(arr, 10000000) and it will allocate nodes as-needed to get you that element.
03:50 jekstrand: And I've got a free-list (sort-of like kernel idr) which should be able to manage glGen* for us.
03:50 jekstrand: I'm sure there's something that'd bite us and need some engineering but I think it should be doable.
03:54 mareko: with glthread, we don't lock buffers because glthread locks buffers for a whole glthread batch, so there are no mutexes in GL calls; any replacement should not use mutexes or atomics
03:55 jekstrand: The only interesting (used often) atomics are atomic_load() which should just be a regular fetch on x86
03:56 jekstrand: But we do have locks around a bunch of the object lookups today for things which may be shared across contexts.
03:56 jekstrand: I don't remember what all they are
03:59 mareko: yes, glthread locks those around every batch, so GL doesn't have to
03:59 mareko: it doesn't lock all of them though
04:00 jekstrand: Oh, interesting. I'm not familiar with any glthread details.
04:00 jekstrand: In any case, the thread safety is mostly a bonus. It doesn't add any cost, really.
04:00 mareko: lock_mutexes(); for (all queued GL calls) execute_call(); unlock_mutexes();
04:01 jekstrand: Nice.
04:04 mareko: also GL buffers don't do any reference counting in 99.9% of cases
04:17 jekstrand: Sure, but we do do a massive number of hash table lookups and, in my benchmarking, the sparse array was a lot faster.
04:17 jekstrand: I don't remember how much off-hand and, silly me, I didn't write it down in the commit message. :-/
04:20 jekstrand: According to comments I made on Khronos discussions, it's about 10x faster than util/hash_table
04:20 jekstrand: Even without any locking around the hash table
04:21 jekstrand: Ok, enough sales pitch. :-P
04:22 zmike: good pitch
04:23 zmike: I'm sold next time I go looking for speed loops to remove 👍
04:29 jekstrand: I filed a bug so we can forget about it together. :-)
04:29 jekstrand: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4253
05:11 HdkR: jekstrand: How much more virtual memory does the sparse array cause for the bad cases of applications allocating dumb high IDs?
05:12 HdkR: :)
05:13 HdkR: Gettng scared for those 32bit apps
05:15 jekstrand: HdkR: If they just allocate a bunch of stuff in the 100000000-100001000 range, about 1000 entries worth.
05:16 jekstrand: HdkR: If they decide to start at 1, grab every 1000th id, and scan through the whole 32-bit space, a lot. :)
05:17 HdkR: Oh, so it does do bucketing in a lockless way?
05:18 jekstrand: HdkR: There was a case (the Steam overlay, I think) that did just grab entries starting at 100000000 or so and hope they never conflicted with an app.
05:18 HdkR: yea
05:18 jekstrand: HdkR: Yup. It's a N-ary tree where N is usually something like 1024
05:19 HdkR: Alright, not too terrible
05:19 jekstrand: But with N = 1024 and 32-bit IDs, you're guaranteed a depth of no more than 4 so lookup is fast.
05:19 jekstrand: If N = 2048, depth <= 3
05:19 jekstrand: When memory needs to be allocated, new leaves are added as-needed and nodes are swapped in using atomics so there's no locking on the core data structure.
05:20 HdkR: Nice
05:20 jekstrand: The standard tree-walk to get to an element uses only p_atomic_read so you're not taking any hit from atomic updates either. The only time an atomic update happens is if memory needs to be allocated.
05:21 jekstrand: We use it in ANV to have an array of all BOs in the driver, indexed by GEM handle.
05:21 jekstrand: We also use it for some of our state allocators.
07:03 airlied: dang lvp also falls over pipeline layout rules which only haveto be valid for cmd buffer recording
08:22 MrCooper: airlied: FWIW, Furmark on radeonsi looks more like the reference image than the one with llvmpipe aniso filtering
08:50 pq: re: DRM debugging, I'm still eagerly waiting for the DRM flight recorder feature...
08:55 JEEB: sounds like a good feature
09:07 pq: Lyude, do you know how anonymity goes with DCO? Can you signed-off-by with a pseudonym?
09:14 pq: or should I just tell people who don't want to expose their real name to use a pseudonym that looks obviously like a real name, so I can claim to merge stuff in good faith with no questions asked?
09:15 MrCooper: how would you verify their "real name" actually is that?
09:15 pq: I can't, that's my protection. :-)
09:16 MrCooper: it means it's a meaningless requirement in the first place
09:16 pq: but if their name is "foobar9987", I suspect I should question that *if* signed-off-by requires real names
09:18 dolphin: https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin
09:18 pq: thanks, I was just looking for that
09:18 dolphin: "using your real name (sorry, no pseudonyms or anonymous contributions.)"
09:19 pq: It's not meaningless if it's required for the singed-off-by to be legally effective; if I accept an obvious pseudonym, it's my fault. If someone uses a pseudonym that is not obviously fake, it's their fault.
09:19 pq: fault, as in, responsibility
09:27 ccr: I'd say DoC is more a honor-based system. name by itself is no strong proof of anything. Google's proposal sounds far more invasive if somehow implemented in any truly meaningful way - how far this "chain of trust" vs. identity of any given developer would it have to take? tied to national ID/passport/whatnot?
09:28 ccr: sounds rather draconian (and impractical to implement)
09:28 ccr: +it
10:16 DPA: I'm a bit scared of what's going to happen in switzerland, where I live. Politicians try to introduce an eID, which could be used for registring and logging in to online services, and proving someone is real.
10:16 DPA: Currently, it seams the few which oppose it are mainly worried about not the state but other companies providing the id. But I'm more worried about it ending the pseudonomous nature of the internet, and it making it
10:16 DPA: impossible to avoid tracking / use uncorrelatable accounts for different online services. I'm sure once it exists, some online services will require it, then people will have to use it, then everyone will start requiring it,
10:16 DPA: and then other countries will follow suit. At this rate, I'm convinced it won't take long until a real id is needed online for everything, and it will be like living in china everywhere. It's inevitable...
10:19 danvet: vsyrjala, apologies for the massive confusion in my head I had :-)
10:20 danvet: airlied, kcmp patch into drm-next?
10:20 danvet: I have no idea who merges this stuff usually
10:21 danvet: hm looks like akpm, maybe we need to ask for an ack?
12:13 patrik: danvet, got a conflict in drm-intel/topic/core-for-CI when pushing with dim
12:14 dj-death: same
12:14 dj-death: I'm trying to fix it
12:14 patrik: ok
12:15 dj-death: and I'm failing tbf
12:15 dj-death: not sure wth is going on
12:15 dj-death: trying to rebase 16k patches...
12:16 ickle: give me a sec
12:18 dj-death: seems to involve some changes in drivers/gpu/drm/i915/Kconfig.debug
12:19 ickle: and bad ordering between topic-for-CI and gt-next
12:21 dolphin: right, need to fix that
12:22 ickle: patrik, dj-death: should be resolved
12:22 patrik: ickle, thanks
12:22 dj-death: ickle: thanks a bunch
12:55 kusma: Seems something's up with the radeonsi-stoney-* tests: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/7184238#L2461
13:00 emersion: ajax: does it sound reasonable to add a new EGLImage target to make llvmpipe render to an existing chunk of memory?
13:07 Peste_Bubonica: Hi folks. I've made a simple test today with BAR ON/OFF. System Spec: Ryzen 3700x // 32GB RAM 3200Mhz // 5700XT Red Devil // Gentoo Linux // Kernel 5.10.14 patched for FSYNC // Mobo X570 Aorus, with Agesa
13:08 Peste_Bubonica: I ran a World War Z Benchmark, a game running in Native Vulkan, and Wine.
13:09 Peste_Bubonica: Score with Bar off: Mesa 20.3.4: 8220 points //// Mesa 21.1.0 (bd7d8a77e9a767b81d73e7820c48c2325101ffac): 8412 points
13:10 Peste_Bubonica: Score with Bar ON: Mesa 20.3.4: 6874 points //// Mesa 21.1.0 (bd7d8a77e9a767b81d73e7820c48c2325101ffac): 5285 points
13:10 kusma: tomeu: Do you know anything about these failures? https://gitlab.freedesktop.org/mesa/mesa/-/jobs/7184238#L2461
13:10 Peste_Bubonica: Severe stutering with Bar ON
13:11 Peste_Bubonica: on my BIOS, i put this settings on: above 4g decoding (on) and Resizable Bar: "Auto" .. There is only auto and OFF
13:14 Peste_Bubonica: bnieuwenhuizen, sorry by yesterday, it was very late here, when you asked about software versions
13:15 Peste_Bubonica: Mesa 21.1.0 Bar ON: https://i.ibb.co/XD2wJ4K/mesa-21-1-0-BAR-ON.png
13:16 Peste_Bubonica: Mesa 21.1.0 Bar OFF: https://i.ibb.co/JqMXB74/mesa-21-1-0-BAR-OFF.png
13:25 karolherbst: anholt: do you have any kind of howto or something so I can setup a manually triggered single GPU runner at home? Will move my hardware this week and will probably be ready to start something next week or so
14:23 MrCooper: emersion: FWIW, jadahl was looking for something like that as well
14:24 emersion: ah, cool. jadahl, did you have different ideas for the new API?
14:25 jadahl: emersion: pixels = malloc() -> EGLImage -> texture -> fbo or something like that is what I want
14:25 emersion: same
14:25 jadahl: \o/
14:25 emersion: except s/malloc/shm_open/
14:25 jadahl: right
14:26 jadahl: malloc as in "give me CPU memory" I don't care where it lives
14:26 emersion: but a software rendering library shouldn't really care where the memory comes from
14:26 emersion: yup
14:26 jadahl: so I could render directly into a buffer allocated by pipewire more or less
14:26 emersion: ah, interesting
14:26 jadahl: that'd be a memfd backed memory
14:26 emersion: makes sense
14:27 jadahl: that's one of two use cases, the other is comparing two shadow buffers
14:27 emersion:wonders if now's the time for drafting a new EGL extension
14:28 jadahl: I was planning trying to convince ajax to do that :P
14:28 emersion: oh, comparing shadow buffers. is llvmpipe faster than… something else?
14:28 jadahl: emersion: only to minimize the amount of copy to a gpu buffer by first comparing fast-to-read cpu memory
14:29 jadahl: its something xorg does already, but the road block I'm at with mutter doing the same is not having to do glReadPixels() from an fbo
14:30 emersion: ah, maybe you want that main memory EGLImage to work with hardware renderers as well?
14:30 emersion: my use case is about software renderers only
14:31 jadahl: this is about sw rendering too
14:31 jadahl: but eventually there will be something ending up on a dumb buffer that will be scanned out
14:31 dj-death: isn't what gbm is for?
14:32 jadahl: and writing to that can be stupidly slow, so in order to minimize the amount of written blocks, a method is to first computing a minimized "what changed since last frame" by comparing two shadow buffers (both in CPU memory), then only blitting the parts that actually changed
14:32 krh: memfd + udmabuf + EGLImage import dma-buf?
14:32 emersion: my use-case is about systems without any render/primary nodes, dj-death
14:32 jadahl: krh: I found udmabuf, but that isn't even in linux proper is it?
14:32 krh: it is
14:32 jadahl: :o
14:32 emersion: there's also vgem
14:32 jadahl: i wonder if its in the rhel kernel
14:32 krh: but don't use vgem...
14:33 emersion: krh: why?
14:34 krh: I guess mainly it's annoying that it creates another /dev/dri/renderDxxx
14:34 emersion: well that's what i like about it
14:34 pq: that's no reason to not use vgem
14:34 krh: heh
14:34 emersion: makes it just work with my existing code
14:35 jadahl: krh: thanks for pointing out udmabuf, I had just found the github page so I assumed it was not really an option
14:35 emersion: hm, but i'm confused
14:35 emersion: udmabuf and u-dma-buf seem different
14:36 jadahl: ...
14:36 emersion: and https://github.com/ikwzm/udmabuf sounds like it's about u-dma-buf
14:36 emersion: > The predecessor of u-dma-buf is udmabuf.
14:36 krh: pq: depends on how many days of your life you end up wasting looking at the wrong /sys/kernel/debug/dri/0/state
14:36 pq: jadahl, maybe you found the other udmabuf which is not the udmabuf - there are at least two.
14:36 krh: vs /sys/kernel/debug/dri/1/state
14:36 emersion: i guess what you want is https://lwn.net/Articles/758903/
14:37 emersion: not that silly github page
14:37 pq: krh, I've never looked at those files.
14:37 jadahl: https://lwn.net/Articles/758903/ indeed
14:37 krh: https://github.com/torvalds/linux/blob/master/include/uapi/linux/udmabuf.h
14:38 krh: pq: they're very useful for seeing that kms actually thinks it's scanning out
14:38 jadahl: emersion: that github page did not look like something usable indeed which is why I assumed 'udmabuf' was not a thing :p too bad google ranks github higher than lwn :(
14:38 krh: pq: one of them is, that is
14:38 pq: krh, right, I guess I'm lucky in that I haven't needed to fight such issues in... ever?
14:38 emersion: krh: i prefer drm_info
14:38 krh: pq: how could you not? ;-)
14:39 pq: I work only on Weston!
14:39 krh: and weston never gets it wrong :)
14:39 pq: *I* have never needed to debug that - I didn't even know those files exist, really
14:40 krh: pq: it's useful for seeing what modifer a fb is using, for example, something that weston very much is involved in
14:40 bnieuwenhuizen: thx for the pointer
14:41 pq: krh, sometimes I need to find out why KMS ioctls error out, but succcess-no-picture has not been my issue
14:42 emersion: still handy when the output is garbage because someone messed up modifiers somewhere
14:42 bnieuwenhuizen: also useful to figure out if you're getting the modifier you expect
14:42 emersion: e.g. scanning out a buffer with a non-linear modifier on the cursor plane, and the driver not complaining
14:42 krh: oh, actually, udmabuf does have a bit of a problem - it's dmabuf ops don't implement the sync callbacks, so the sync ioctls don't work... which is a problem if you're using it with something that's not cache coherent
14:43 krh: bnieuwenhuizen: indeed, good for the "it can't possible work on the first try... huh, I guess it is using the right modifier..." cases
14:43 pq: how am I supposed to use /sys/kernel/debug/dri/0/state ? 'cat' as root just says Operation not permitted.
14:44 krh: but also "I wonder if it's using an overlay or compositing..."
14:44 emersion: pq: works here
14:44 pq: weston has the green tint and looots of debug prints to see what's composited or not and *why*
14:44 krh: pq: cat should work..
14:44 emersion: pq: fedora has this lockdown mode where it might disable debugfs…
14:45 emersion: pretty annoying
14:45 pq: I'm on debian buster
14:45 pq: root@eldfell ~ # cat /sys/kernel/debug/dri/0/state
14:45 pq: cat: /sys/kernel/debug/dri/0/state: Operation not permitted
14:45 krh: pq: setenforce 0 ?
14:46 pq: -bash: setenforce: command not found
14:46 krh: pq: maybe you're using debian busted?
14:46 pq: I'm not amused.
14:47 jadahl: hmm.. does udmabufs need a render node open to call the ioctls on?
14:47 emersion: maybe see if dmesg has something to say?
14:47 pq: emersion, I wonder, could drm_info pull out info about the used FBs too?
14:47 emersion: https://man7.org/linux/man-pages/man7/kernel_lockdown.7.html
14:47 emersion: pq: it does :P
14:48 krh: jadahl: /dev/udmabuf
14:48 emersion: under each FB_ID prop, it logs the FB metadata: format, modifier, planes, etc
14:48 jadahl: krh: ah, thanks
14:48 pq: emersion, like format, modifier and dimensions?
14:48 emersion: yeah, size/stride too
14:48 emersion: anything drmModeGetFB2 can give us
14:51 krh: pq: https://paste.debian.net/1184709/
14:51 pq: emersion, looks like I was behind in git. But after doing 'meson subprojects download', it still says Checking for function "drmModeGetFB2" with dependency libdrm: NO
14:52 emersion: ah, yes, it needs a new enough libdrm
14:52 pq: didn't I just pull it?
14:52 emersion: the subproject is just used for drm_fourcc.h definitions…
14:52 pq: ...
14:52 emersion: it still links to the system libdrm
14:53 pq: good thing I haven't had to debug kernel-side KMS problems :-P
14:53 emersion: lol
14:53 bnieuwenhuizen: that is all I do in display space :P
14:53 pq: weston atomic state dump and scenegraph analysis have been enough
15:06 jadahl: emersion: fwiw, fedora here could cat that file as root, and i don't have any setenforce 0 going on
15:06 pq: krh, https://paste.debian.net/1184714/
15:06 emersion: jadahl: hm, maybe something something secure boot
15:07 jadahl: maybe I have turned that off, can't remember
15:07 emersion: but i remember having to work around fedora lockdown
15:24 vsyrjala: danvet: heh. i think confusion is the status quo when it comes to drm_vblank. always takes me about a week to page most of it back in when i have to look at it
15:25 danvet: vsyrjala, yeah about a week sounds right :-/
15:26 danvet: while you have it paged in, I also cc'ed you on a doc/check patch so maybe next time around it's slightly faster
15:32 alyssa: imirkin: ERROR - dEQP error: Mesa 21.1.0-devel implementation error: Invalid state in _mesa_program_state_string
15:32 alyssa: ERROR - dEQP error: Please report at https://gitlab.freedesktop.org/mesa/mesa/-/issues
15:32 alyssa: Assuming this one is also my fault? 😅
15:32 alyssa: 😋
15:32 imirkin: alyssa: congratulations on achieving this error
15:32 imirkin: i don't think i've ever seen it
15:33 imirkin: so you know it must be good
15:33 alyssa: =D
15:33 imirkin: i'd have to dig into seeing what that's complaining about
15:51 jadahl: so sadly udmabuf + llvmpipe => assert(0), and with that commented out I get ?? () SIGBUS:es backtraces
15:52 emersion: hm
15:52 emersion: when is the assert(0)?
15:52 emersion: where*
15:52 jadahl: querying PIPE_RESOURCE_PARAM_HANDLE_TYPE_KMS on the texture
15:52 jadahl: in lp_texture.c
16:03 jadahl: i suspect it eventually gets confused that the dmabuf it was handed wasn't a real one maybe
16:04 jadahl: (testing this on nouveau with hwaccel turned on)
16:09 emersion: does LIBGL_ALWAYS_SOFTWARE=true help?
16:11 jadahl: no
16:11 jadahl: err, i wrote the wrong thing, this is with hwaccel turned *off*
16:12 jadahl: so it was llvmpipe to begin with
16:12 jadahl: and works with a plain old fbo + llvm
16:13 jadahl: but for some reason it tries to query a llvmpipe texture when creating a gbm_bo for the scanout surface
16:15 ajax: emersion: i thought egl already had that somewhere
16:15 ajax: (the "existing chunk of memory" bit)
16:16 emersion: ah, do you have any pointers?
16:17 ajax: (rimshot)
16:17 zmike:chuckles politely
16:17 mlankhorst_: I've pushed out drm-misc-next-fixes! With fixes cherry-picked from drm-misc-next. If you miss anything just cherry-pick them over please. :)
16:24 ajax: i think i was misremembering how eglCreatePbufferFromClientBuffer worked
16:26 emersion: EGLClientBuffer didn't seem very useful
16:28 ajax: presumably you'd add an extension to make one out of malloc'd memory and then pass that to eglCPFCB
16:28 jadahl: udmabuf could be useful if it just didn't abort() and actually worked
16:29 emersion: ajax: i'd prefer one to get an EGLImage, but there's a target arg in both cases
16:46 karolherbst: dcbaker: one meson question because it came up a few times: why does "meson setup" _and_ "meson configure" exist? couldn't that just be the same thing?
16:46 karolherbst: or treat meson setup as "meson configure" if the dir is already configured?
16:46 ccr: agreed on that.
16:47 karolherbst: that seems to get brought up quite a bit when discussing autotools vs meson usability
16:47 ccr:. o O ( at least it's not cmake )
16:52 dcbaker: karolherbst: that comes up a lot. I think it's mainly because jussi feels that it's an important distinction, say this point the difference between them is tiny
16:53 dcbaker: S/say/at
16:53 karolherbst: ehh
16:54 karolherbst: I don't see why it is important at it's mainly a bit annoying for users
16:54 karolherbst: (having to use two different commands for configuring)
16:54 orbea: what is setup for? I've only used configure with meson projects and it seems to all have worked out fine.
16:55 karolherbst: orbea: "meson" == "meson setup"
16:55 karolherbst: so initial creation of the build dir is "meson setup"
16:56 Lyude: pq: DCO?
16:58 vsyrjala: i just rm -rf ./build ; meson ... ./build. because i can never remember how to do anything else
17:00 alyssa: "We are a small team, so we can't play every game from beginning to end. (We'd love to, but then we won't have time for actual driver development.)"
17:00 alyssa: ❤️
17:00 LordKitsuna: Oh wow that phoronix article calling for testing just read it
17:01 LordKitsuna: I do have some games that have weird frametime spikes or just unstable frametimes in general but i never knew what to blame, mesa, dxvk, game. Guess i should try to collect info and report anyway i always figured it would be a bother
17:12 anholt: karolherbst: https://docs.mesa3d.org/ci/docker.html
17:14 karolherbst: thx
17:14 karolherbst: anholt: but that's for the CI stuff? the issue is that I don't have a lab so I don't plan on wiring up any time soon in automated CI
17:15 karolherbst: just want to have something which I can ran regulary without having to bother with the details all that much
17:15 anholt: karolherbst: that's the easy-setup mode for devices. and then you add an extends from test-manual so only people that opt in get exposed to your thing.
17:15 karolherbst: ahhh
17:15 karolherbst: cool
17:15 karolherbst: so I could potentially push it without annoying others?
17:16 anholt: yeah
17:17 anholt: radv's got this already, you can take a look at their yaml blocks for tests
17:17 anholt: (the manual stuff)
17:17 karolherbst: do I already need like two systems or could I just make sure my main system does work.. although with nouveau I think I prever two systems because of rebooting or so... mhhh
17:17 karolherbst: would have to think about what to do here
17:17 anholt: when it's manual, it's kind of up to you and whoever you work with that's sharing those systems
17:17 karolherbst: sure, but it's more about how I manage the machines I can plug into
17:18 anholt: well, to share you need to register your system with a shared runner token, which you would need to coordinate with me on. probably start with just personal.
17:18 karolherbst: I have a desktop which was supposed to be the "CI controller" and like 3 machines I could plug into it
17:18 karolherbst: laptops and an arm dev board
17:18 anholt: with the link I gave, everything runs on the test device
17:18 karolherbst: just wondering what would be a low effort thing which is still allowed to break without annoying others
17:19 karolherbst: and as I am workig from home, I can repair it quickly as long as I am home :D
17:19 anholt: which is the low-effort, higher-maintenance mode
17:19 karolherbst: mhhh
17:19 karolherbst: I think I kind of want to at least start with a controller which is able to reboot machines
17:20 karolherbst: otherwise I see me ending up rebooting the machine multiple times a day
17:20 karolherbst: at least that's my considerations here
17:20 karolherbst: I have the hw to do it properly.. just not really the time to care about setting up the software stack
17:20 anholt: ok. if you're looking at reboots, then you want something more like the bare-metal.html at that link
17:21 karolherbst: the controller also has two network cards to create a private network, etc..
17:21 karolherbst:wished some magic docker-compose file appreas to do it all for me :p
17:22 karolherbst: I even have a poe capable switch to power cycle the arm dev board I have
17:22 karolherbst: so kind of hoped to do a low maintanance lava setup with declared runners and power cycling via poe switch magic or intel ME or so
17:22 anholt: poe switch is what vc4 testing is using, you might be able to reuse some of their bits
17:23 karolherbst: and the config is all in some git and images are deployed automatically
17:23 MrCooper: ajax: thanks for pushing !4986 over the line!
17:23 karolherbst: anholt: bare metal or laval?
17:23 karolherbst: *lava
17:24 anholt: Personally, having done both, I would highly recommend the bare metal route
17:24 karolherbst: mhh, and how can you make sure the thing reboots?
17:24 karolherbst: or well... which bit does manage the runners
17:24 anholt: have you read the bare-metal.html?
17:25 karolherbst: nope
17:25 anholt: please do so, I did write it this down
17:25 anholt: (and if there are questions after that, I want to fix the docs1)
17:26 karolherbst: mhhh...
17:26 karolherbst: well, the laptops I have are UEFI based ones
17:27 pq: Lyude, https://developercertificate.org/ which is what a Signed-off-by means.
17:28 karolherbst: _but_ I already have docker files to spawn a dnsmasq + TFTP server to network boot uEFI machines
17:29 karolherbst: anholt: I guess the things I have to do would be to support hardware not supported by fastboot + servo and deal with that somehow
17:32 pq: Lyude, DCO = developer certificate of origin
17:32 Lyude: pq: just unsure how this was related to what I mentioned the other day (assuming you're talking about the google blog post I shared)
17:33 pq: Lyude, I'm talking about anonymity when contributing to projects that run with DCO, not about the google thing.
17:34 Lyude: oooh oops
17:34 pq: I didn't even read the google things.
17:34 Lyude: yeah I actually do DCO with a psuedonym
17:36 pq: Right, so the Linux doc says that's not allowed, but I would assume that is just the official position they *must* take to protect the maintainers and the project.
17:38 Lyude: pq: actually I think I've asked about it before and they've said that it's fine, and that's just kinda outdated info
17:38 Lyude: that was years ago that I asked though]
17:39 karolherbst: Lyude: no no, you were always using your real name of course :p
17:39 pq: oh? was that "official" or just practical advice?
17:39 karolherbst: Lyude: do you have something like an "artist name" in the US? :D
17:39 Lyude: pq: don't remember, like I said it was a long time ago :P. it was probably airlied that I poked though thinking aboutit
17:39 Lyude: karolherbst: we do but I don't know if that exists legally, probably though
17:40 karolherbst: so we have this thing in Germany where you can get an "artst" or "church" or whatever name added to your ID
17:40 imirkin: karolherbst: sure. plenty of actors use "fake" names, but i don't think it has any legal standing
17:40 pq: if maintainers do their reasonable diligence, blaming them for accepting false sign-offs would be hard, I guess
17:40 karolherbst: well.. in Germany you can register it and use it instead of your name :D
17:40 karolherbst: (for most things)
17:40 imirkin: for businesses, there's something known as a DBA (Doing Business As), but it doesn't exist for individuals afaik
17:40 pq: so I would assume that as long as no-one realizes you are using a pseudonym, it's ok :-D
17:41 karolherbst: :D
17:41 karolherbst: Lyude real name is Lyude, end of story :p
17:41 pq: indeed
17:42 ajax: at least in the us, your name is whatever you use. if you write something and put a name on it that isn't what's on your birth certificate, it's still yours.
17:43 ajax: now if only _all_ of the law understood that... but in the end a judge is not going to say you _don't_ own it because you put the wrong name on it
17:43 alyssa: ^^
17:44 karolherbst: ajax: yeah.. for contracts in Germany it doens't matter what name you put under it, you are still responsible :D (it matters in case you put someone else name, so the contract is still valid, just that you have to fullfill it)
17:44 karolherbst: a bit illegal, but.. so what
17:44 karolherbst: contracts are binding by intent
17:44 karolherbst: not by the name you put under it
17:44 pq: makes me wonder why the kernel doc still says no pseudonyms
17:45 karolherbst: I guess it makes legal fights easier
17:45 pq: maybe some country somewhere needs it
17:45 karolherbst: probably
17:45 imirkin: ajax: hm, interesting
17:45 imirkin: ajax: but there's a concept of your "legal name", which is what's on your passport/ID, and what you write in when filing taxes. i don't think you can put whatever you want there...
17:45 karolherbst: imirkin: well, your signature can be whatever crap you want it to be :p
17:45 Lyude: they should really fix that honestly, I didn't realize no pseudonyms was still even policy
17:45 alyssa: also, heuristically -- people are more likely to follow the law if they're signing off on their IRL name (whether it's their passport name or not) than if they're using a throwaway pseudonym
17:46 Lyude: or written as such anyway
17:46 karolherbst: alyssa: not really
17:46 imirkin: ajax: and if you get something notarized, that would be verified, which is likely to happen with a contract
17:46 karolherbst: there are enough studies that show that people behave roughly the same under pseudonym
17:46 ajax: imirkin: i haven't tried to fight that particular battle, but at some level the quantum of accounting there is the SSN not the legal name
17:46 ajax: excuse me, "taxpayer id number"
17:46 imirkin: hehe
17:47 ajax: which merely happens to be numerically identical to the number the social security administration uses for you, you see
17:47 alyssa: karolherbst: --retracted
17:47 imirkin: yeah, but if you get a signature notarized, the notary will (should) verify that the name under the signature matches the govt issued ID
17:47 karolherbst: :D
17:47 karolherbst: anyway, people should use whatever name they want to use
17:48 karolherbst: imirkin: notary stuff is a huge exception
17:48 karolherbst: which always has special and way more stricter lawas
17:48 karolherbst: *laws
17:48 karolherbst: in germany you also can't use copies if you do something witha notary, has to be the original paper thingy
17:48 karolherbst: but for everything else it really doesn't matter as again, the _intent_ is binding
17:48 karolherbst: not the stupid paper or contract
17:49 imirkin: the specifics of notary details vary
17:49 imirkin: from country to country
17:49 imirkin: but the idea is the same
17:49 karolherbst: sure
17:49 karolherbst: yeah
17:49 imirkin: "is the person who is signing who they claim they are"
17:49 karolherbst: yep
17:49 karolherbst: and there you just need to use your real name
17:49 karolherbst: well
17:49 karolherbst: official real name
17:49 imirkin: your legal name ;)
17:49 karolherbst: ehhh
17:49 karolherbst: whatever that is ;)
17:49 pq: Lyude, I'm happy this came up, because I'm going to change my behavior to not even think if someone offers a signed-off-by with a pseudonym (as long as it comes with an email address, so they can theoretically be contacted), I'll just accept it.
17:49 imirkin: i know some people whose name is too long to fit on an ID
17:49 imirkin: so this causes them a massive headache
17:50 karolherbst: ufff
17:50 Lyude: pq: cool! :)
17:50 karolherbst: we have people in Germany with like 15 names in total :p
17:50 imirkin: that's just cheating - lots of short names. this one person in particular i'm thinking of is just First Last :)
17:50 karolherbst: some fancy "Nobility" people who think they are still better humans
17:50 karolherbst: so they add fornames after fornames for stupid reasons
17:50 karolherbst: ahhh
17:51 karolherbst: pq: well, think about people called Max Miller with some random email.. are they easier to contact in case it comes up? :p
17:52 karolherbst: I bet there are like 1k+ people with the same name
17:52 karolherbst: a pseudonym is usually more unique ;)
17:52 karolherbst: (which I could assume is one way to argue pro pseudonyms)
17:54 pq: that's why the email address is there too
17:54 karolherbst: ehh.. max.miller@gmail.com
17:54 ajax: "excuse me, *i'm* john smith." "john smith 1882?" "my mistake!"
17:54 karolherbst: unused for 6 years
17:54 karolherbst: ahhh
17:54 karolherbst: john smith is I guess more common
17:55 karolherbst: johnsmith12353213421@whatever.com
18:04 kisak: As far as I'm concerned, it's a question of trust. If a potential contributor isn't willing to stand behind their suggested contribution, why should it be accepted? Where fake names are involved, where's the line? Is it okay to accept a contribution from an internet phantom with an unpronounceable emoji symbol as an alias?
18:06 alyssa: Sometimes there are reasons for pseudonyms that have little to do with a contribution in question.
18:07 orbea: requiring people to use their real names can open them up to online or irl harassment and abuse by third parties
18:10 Lyude: kisak: to that last question: yes, it is fine to accept emoji commits :). also, I'd honestly say unless you're going through every sob and having people send their identification to you to confirm, it's not a very secure system
18:17 ajax: kisak: probably the level of trust required there scales with the complexity of the contribution
18:17 daniels: kisak: atomsymbol has a reasonably long history of contributing to Mesa in good faith, so I'd put much more faith in their commits than I would someone called Freya Barnes who I've never heard of in my life but has a name which is lexically compatible with Latin birth-naming conventions
18:17 daniels: (ditto icecream95 vs. someone with a 'well-formed' name I've never seen before)
18:18 ajax: someone wants to call themselves 💩 when they submit a build fix, whatever. someone wants to drop a fully formed sgx driver on me, maybe that needs some higher threshold?
18:19 daniels: ajax: I'm pretty sure the person who publicly dropped the wildly illegal XGI driver did so under a name which appeared to be a legal name, from their XGI corporate email address
18:19 ajax: but that threshold is really more about continuity of identity than the name itself. i want to know _that person_ will be accountable for it
18:19 daniels: ++
18:19 Lyude: ajax: yeah-that's a usage of SoB that makes perfect sense to me
18:20 daniels: I mean, I don't think anyone here has actually met imirkin IRL? but whoever that person is has been around here for long enough that I totally trust him, even if I do disagree with him like 95% of the time
18:20 ajax: and like... my parents call me ajax more often than they call me adam, what exactly _is_ my name
18:20 imirkin: hehe
18:20 daniels: imirkin: <3
18:20 imirkin: daniels: i've met mupuf. and bwidawsk. and xexaxo1. i think that's the end of the list.
18:21 xexaxo1:waves
18:22 daniels: Debian's idea that identity can be purely validated by glancing at a bit of paper/plastic for a few seconds is imo one of the great time-wasting exercises of all time, unless you accept the predicate that open-source developers are all experts at identifying forged Belarusian passports
18:23 ajax: i mean, they're experts at everything else.
18:23 imirkin: daniels: we should just have verisign verify people's identities. that will work better.
18:24 ajax: i'll note here that the gpg key i used for signing xorg releases from roughly 2005 to 2015 was _never_ signed by any other person
18:24 ajax: the only thing demonstrating that it was always me using it was the fact that it also signed a bunch of emails that all sounded like the same person wrote them
18:25 imirkin: if someone came in here with my handle hating on autotools, you'd know it was an impostor ;)
18:26 imirkin: online identities sure are a thorny issue
18:26 daniels: imirkin: in a roundabout way, VeriSign is the entire reason I’m here today, so be careful what you wish for
18:26 alanc: since I never got my key signed either, I'd bet the majority of X.Org module releases are signed by unverified keys
18:29 HdkR: Meat space identities are as much of a mess as online identities. :P
18:31 karolherbst: kisak: pseudonyms are real :p
18:31 karolherbst: I have no problems with accepting contributions under pseudonyms
18:32 karolherbst: there are also sometimes reasons the contributor can't talk about why they choose a pseudonym
18:32 karolherbst: especially in the sec area it's common, although "contributions" are not always patches there
18:33 karolherbst: ajax: good idea, I just call myself 🐧 now
18:33 karolherbst: :D
18:33 HdkR: Happy pengu
18:33 karolherbst:still annoyed that IRC server don't support unicode nick names
18:33 karolherbst: IRC sucks
18:33 karolherbst: :p
18:33 imirkin:is so happy IRC doesn't support unicode nick names
18:34 karolherbst: heresy!
18:34 imirkin: that'd be super-annoying for typing someone's handle
18:34 karolherbst: well, that's your problem :p
18:34 karolherbst: although I would say they are only allowed to end with random unicode names
18:34 karolherbst: and the first 3 chars should be ascii
18:35 karolherbst: that's a middle ground I would agree too
18:35 karolherbst: *to
18:35 imirkin: good thing that daniels and danvet are the same person
18:35 HdkR: Emoji names, just as hard to type as a Japanese name
18:35 imirkin: so there won't be any confusion
18:35 imirkin: ;)
18:35 ajax: just hold down Tab until it cycles to the right name
18:35 karolherbst: just press tab twice
18:35 Lyude: imirkin: -actually-, seven ircd (freenode's ircd, I think that's what it's called iirc. it's a fork of charybdis) doesn't. but there are definitely ircds like inspircd that do
18:35 karolherbst: I already have the problem with jenatali and jekstrand
18:36 jekstrand: Yeah....
18:36 karolherbst: or tab just chooses randomly and you get a slot machine animation until you press enter
18:36 Lyude: also, this is what .Xcompose is good for (.XCompose?)
18:36 imirkin: Lyude: there are a lot more unicode code points than i can remember compose rules for
18:37 DrNick: that's why you mash ctrl-space to switch to the emoji IME and search by name
18:37 karolherbst: just use this fancy unicode input method software :p
18:37 Lyude: sure, but you're probably not using a lot of them most of the time other then a select few :P, anyway most of the time I just make them into words. like snowman
18:37 imirkin: i start forgetting right around linear-b script :)
18:37 karolherbst: which reminds me.. I need to set it up properly :D
18:37 ajax: imirkin: just keep adding compose rules to the db until you've covered all the ones you care about
18:38 karolherbst: DrNick: I always forget how the software is called doing this :D
18:38 DrNick: uniemoji?
18:38 karolherbst: no
18:38 DrNick: you can also customize uniemoji's dictionary, which is useful there's some non-emoji egyptian hieroglyphs that are useful
18:38 karolherbst: ibus
18:39 karolherbst: ibus is the name of this input helper software
18:39 karolherbst: but there was a second one
18:39 imirkin: fwiw i never managed to understand the whole emoji craze
18:39 karolherbst: fcitx
18:39 imirkin: 3 seems more than enough. :), :(, and =/
18:39 imirkin: what more can you want
18:39 ccr: ":D"
18:39 tichun: hi, how would you learn to debug the driver? books/tutorials/lectures/etc. are welcome. i want to locate affected component in bugs.
18:39 karolherbst: imirkin: well, some want to use letters of their native languages :p
18:40 imirkin: tichun: debugging is a pretty general skill. i don't think there's anything too particular to debugging drivers vs other software
18:40 karolherbst: luckily there are international layours for european languages
18:40 karolherbst: but if you are from asia? good luck
18:40 daniels: imirkin: in a win for nominative determinism, we're surprisingly similar - the primary differences being accent and height
18:40 imirkin: karolherbst: what languages don't have the punctuation i mentioned
18:40 karolherbst: the software stack is a mess
18:40 tichun: imirkin, thanks
18:40 daniels: (also he's much better looking than me, but that's neither here nor there)
18:41 imirkin: daniels: ha! i don't know that i've seen either of you ... maybe in some fosdem/xdc video, but i don't remember
18:41 Lyude: tichun: if it helps at all I mostly learned just from struggling on trying to fix a radeon bug or two for a few weeks :P, eventually you start to figure things out. also-everyone here has a pretty good knowledge of the stack, so you can ask questions here
18:42 karolherbst: daniels is the one always showing of with his food :p
18:42 karolherbst: uhm
18:42 karolherbst: danvet I mean
18:42 karolherbst: :D
18:42 daniels: karolherbst: I reserve the food for Instagram
18:42 karolherbst: more food pics as unicode emoticons!
18:43 karolherbst: 🍕
18:53 xexaxo1: sounds like for XDC2021 could have mildly fake IDs, with emoji spelling of our (nick)names as well as mugshot ;-)
18:53 xexaxo1:ducks before objects start flying his way
18:54 j4ni: mripard: mlankhorst_: drm-tip rebuild fails at drm-misc-next merge
18:54 ccr: "hello, I am <hamburger emoji>"
19:04 danvet: karolherbst, food were?
19:05 karolherbst: 🍝
19:25 danvet:caught up on the scrollback
19:26 danvet: imirkin, daniels has the much more magnificent beard
19:26 danvet: or at least on the last pic I've seen that was still the case
19:29 daniels: danvet: it got pretty outrageous around July, but these days my bubble's flatmate is a hairdresser, so now I can keep my hair at a manageable level, I do the same with my beard
19:29 danvet: still embracing the lockdown look over here
19:29 danvet: well beard's gone, to compensate a bit
19:30 imirkin: danvet: i imagine in quarantine, many new beards have been born
19:30 imirkin: a guy at my current work looking like he's off to the north pole
19:33 danvet: haha
19:33 danvet: we'll I'm going for surfer style waves in my hair
19:33 danvet: or well, my hair is doing that
19:43 daniels: this was my peak during first lockdown; almost made me feel like going back to working on X11 https://usercontent.irccloud-cdn.com/file/fZulMPfh/IMG_20200731_132820.JPG
19:44 emersion: missing long hair!
19:46 daniels: emersion: I’m not missing it at all tbh https://usercontent.irccloud-cdn.com/file/pbotzC8Z/PHOTO-2020-12-28-23-21-24.JPG
19:46 emersion: ahah, nice :P
19:47 emersion: by cutting your hair you lost your power to understand X11
19:47 dj-death: another thing he's not missing? ;)
19:47 imirkin: just like samson
19:48 karolherbst: oh no, now we have to close all X11 bugs as "-ECANTFIX"
19:49 karolherbst: (which is true for like 90% of the bugs anyway)
19:49 karolherbst: probably
19:49 kisak: -EBEARDTOOSHORT
19:49 karolherbst: atm we can still blame corona
19:53 daniels: emersion: s/understand/accept/
19:59 karolherbst: just kill it already, it's simply just suffering at this point :p
20:04 danvet: well I'm still waiting for MrCooper to celebrate the first xwayland-only release so I can do the "the king is dead, long live the king" tweet
20:05 danvet: or is X11 a queen
20:07 zmike: despot
20:13 ajax: i'm thinking the grail knight in last crusade
20:14 jekstrand: 'tis but a fleshwound!
20:15 imirkin: i still don't know what an anarcho-syndicalist commune is...
20:17 airlied: imirkin: x.orb
20:17 airlied: x.org
20:17 imirkin: lol
20:18 vsyrjala:picturing a cute white bunny... with its bloody incisors sharpened to resemble the X logo
20:18 ccr: "we're taking turns to act as a sort of executive-officer-for-the-week but all the decisions of that officer must be ratified at a special bi-weekly meeting .."
20:21 karolherbst: ccr: just schedule a meeting which is password protected but nobody knows the password
20:22 karolherbst: but everybody is also too embaressed to ask
20:22 zmike: offtopic: are there any constraints in gl about calling glDeleteFramebuffers in threads? i.e., does it need to be called from the same thread that created the framebuffer or is any thread fine?
20:23 HdkR: Needs to be deleted from the thread that owns the context that the object is bounded to
20:23 zmike: 👍 thanks
20:23 karolherbst: HdkR: can't you just make the context current on the thread?
20:23 HdkR: So can change threads, but only ever bounded to one thread at a time
20:23 karolherbst: ahh
20:24 karolherbst:surprised that GL even specifies this
20:24 HdkR: Just a byproduct of the ownership semantics really
20:25 karolherbst: I guess
20:25 karolherbst: I always thought GL specifies nothing and most of it is just common sense
20:25 karolherbst: :p
20:25 HdkR: Some terrible application could spin up a thousand threads, build a thousand objects by switching ownership of the context
20:25 karolherbst: uhm.. like the android emulator :p
20:25 HdkR: Yea, exactly that :D
20:26 karolherbst:does verify his nouveau threading fixes against the android emulator
20:26 karolherbst: without the patches my system just goes down
20:26 HdkR: There are some pretty nasty emulators that just MakeCurrent constantly to move GL work between threads...
20:26 karolherbst: ufff
20:26 HdkR: Too scared of shared contexts so they do that instead
20:26 zmike: dealing with one of those now
20:26 karolherbst: dolphin as well?
20:27 ajax: are they smart enough to use the flush control extension?
20:27 HdkR: Dolphin doesn't do that garbage
20:27 karolherbst: HdkR: of course not :p
20:27 karolherbst: how could I even ask
20:27 HdkR: There's a flush control extension?
20:28 HdkR:reads
20:29 ajax: https://www.khronos.org/registry/OpenGL/extensions/KHR/KHR_context_flush_control.txt
20:29 HdkR: I've not seen any emulator using that, They have the expectation of a flush happening by default
20:29 ajax: that seems footgunny
20:30 ajax: like, correct, sure, but _somewhat_ slow
20:31 HdkR: Ubiquitious answer from a lot of emulator devs is that it works fine on Nvidia blob :P
20:31 emersion: is makeCurrent not a no-op when the context is already current?
20:31 ajax: emersion: it's a no-op if it was already current in the calling thread (and the drawables didn't change)
20:32 ajax: moving it between threads means releasing from A and then taking in B, which will flush between
20:32 HdkR: Oh, the wording of the eglMakeCurrent explicitly calls out that it'll be a flush on rebind. So that's good
20:33 HdkR: Couldn't remember if that was implicit or not
20:33 emersion: i see
20:34 HdkR: Calling it a no-op usually isn't nice though. There's usually some state checking and mutex holding that you wouldn't really want :)
20:34 ajax: HdkR: i thought it was more like flush on release? i guess you could defer the flush to rebind if you wanted, i don't know why you'd want to.
20:35 HdkR: oh yes, wording is specific that it is flush on release
20:36 emersion: HdkR: i mean, is there a point in adding a `if (eglGetCurrentContext() != egl_context)` check before eglMakeCurrent?
20:38 HdkR:side eyes Android stack
20:38 HdkR: ...Maybe
20:41 ajax: it's probably measurable amounts of error checking overhead
20:41 ajax: linear in the number of times you're calling MakeCurrent though, which does seem like an easy problem to not have
20:45 HdkR: Sad that people just pay the cost rather than using a shared context
21:00 karolherbst: I guess they see segfaults and give up
21:08 Peste_Bubonica: HdkR, Dude, severe slow down here too, with BAR enabled
21:09 HdkR: :)
21:10 Peste_Bubonica: about 40% in a game that I can run a benchmark here
21:10 HdkR: This is probably why AMD only advertises it working on Zen3+RDNA2 configuration. Can't validate it as always being a win on older configurations
21:10 Peste_Bubonica: HdkR, even with mesa 20.3
21:10 Peste_Bubonica: but not so severe than mesa git 21.1
21:11 HdkR: Well that's good at least
21:38 daniels: HdkR: in the no-op case (i.e. new_ctx == cur_ctx), it's TLS rather than mutex
21:39 HdkR: Usually anyway :D
21:40 HdkR: Mesa it's at least just a TLS lookup for that one
22:41 mareko: I have 16-bit packed varyings for radeonsi, it works with separate shaders
22:46 imirkin: mareko: just curious - does amd have hw for 16-bit interp, or are those forced to 32-bit?
22:46 mareko: it has 16-bit interp
22:46 imirkin: neat
22:47 mareko: it's all 32-bit but the interp can choose whether to read low or high 16 bits
22:47 imirkin: oh, and you don't get auto-interpolated varyings in the shader
22:48 imirkin: you just get the ij?
22:48 mareko: we always get the ij
22:48 imirkin: right ok. that makes more sense.
23:00 jsarha: I bumbed into a conflict when pushing a single patch in tilcdc to drm-misc-next. There were several of conflicts but I think they were all quite trivial. Compiled alldefconfig for ARM amf amd64, no errors. Should I just push it? (if you want to take a look resolutin is in https://github.com/jsarha/linux.git drm-tip)
23:10 jsarha: BTW, none of the conflicts had anything to do with the commit I was pushing.
23:17 jsarha: airlied: I bumbed into a conflict when pushing a single patch in tilcdc to drm-misc-next. There were several of conflicts but I think they were all quite trivial. Compiled alldefconfig for ARM amf amd64, no errors. Should I just push it? If you want to take a look resolutin is in https://github.com/jsarha/linux.git drm-tip. BTW, none of the conflicts had anything to do with the commit I was pushing.
23:21 jsarha: ... need to go to sleep. I'll leave the drm-tip conflict as it is as it should not be my doing.