08:54 tzimmermann: jfalempe, hi! a question on https://patchwork.freedesktop.org/series/131977/ on connector polling. the issue with the idrac likely comes from the final patch, which enables the polling. i'd like to send the first 9 patches as new patchset for DDC refactoring. as we discussed, polling requires bmc support. that would be a separate patch. but i think about modelling the bmc as a bridge instead of a connector. the bmc
08:54 tzimmermann: connector depends on the real connector, while a bridge would sit within the regular encoder-to-connector chain. thoughts?
08:56 jfalempe: tzimmermann: sure you can re-send the first 9 patches, that shouldn't break the bmc use case.
08:56 tzimmermann: great.
08:57 jfalempe: for bridge vs connector, tbh I'm not sure what are the differences. I would still prefer something similar with AST.
09:00 tzimmermann: jfalempe, do you have thoughts on the brigde issue? the bmc connector's problem is that it depends on the hardware connector. for example, the DRM helpers have to do ->detect_ctx the hardware first, otherwise the bmc might return incorrect values. but there's no such guarantee in the helpers. it works because the hardware connector comes first in the list.
09:02 tzimmermann: with a bridge, we always test the hardware conenctor first. if it's disconnected, we'd refer to the bmc bridge
09:08 jfalempe: tzimmermann: if you think it will work better with a bridge, let's try it. We just need a way to configure the output even if the vga connector is disconnected.
09:10 jfalempe: tzimmermann: what will be the difference for userspace ? it will see only 1 connector, but if vga is disconnected, it will still report as "connected", but with "fake bmc" value ?
09:11 tzimmermann: yes, it's never diconnected
09:11 tzimmermann: but the reported modes might change
09:11 karolherbst: does anybody know what games/applications heavily rely on glMultiDraw* being low CPU overhead?
09:12 jfalempe: tzimmermann: ok, so it avoid the "bmc is connected only if vga is disconnected" trick, so that's good for me.
09:12 jfalempe: and it will also be easier for userspace, since it won't think it can display different thing on different connectors.
11:16 pq: looks like drm_format_info_min_pitch() is a little too optimistic? https://lists.freedesktop.org/archives/dri-devel/2024-May/453563.html
11:29 tzimmermann: jfalempe, i have to experiment first
13:10 jfalempe: tzimmermann: the mgag200 ioburst workaround works for some servers, but I have report that poweredge XR11 and XR5610 needs to completely disable Write Combine to achieve low latency. May I submit a new patch for that ? Should I revert the current ioburst workaround since we probably don't need two different workaround ?
13:15 tzimmermann: jfalempe, i have recently reworked the fbdev handling for many drivers. specifically, there's now fbdev-shmem, which does away with the additonal shadow buffer. it's now used by mgag200 on drm-misc-next. it would be interesting to first see how that affects the problem
13:15 tzimmermann: https://patchwork.freedesktop.org/patch/590322/?series=131037&rev=3
13:23 jfalempe: tzimmermann: sure I can test that, but I doubt it will have an impact, since memory-intensive application don't affect the latency.
13:25 tzimmermann: jfalempe, there's one buffer less in the console's output. i'm thinking that might affect caching (and by extension latency). not sure if anything comes from that
13:25 tzimmermann: as in 'fewer cache misses; higher locality'
13:25 tzimmermann: just an idea
14:41 zmike: eric_engestrom: ack https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29166 ?
14:42 zmike: eric_engestrom: pls just assign marge when you ack
14:50 polderan: First I'll discuss the data indexing, it works so that one bank is value+contiguous_index+2xlengthfrom_const*nrofcell+bank_ffset where contiguous_index and bank_offset is filled in at runtime, and bank_offset is in range of 1024 with same size steps to subsequent banks. 2xlengthfrom_const is distance to known smallest elimination value times two, so upon eliminating first element, you have
14:50 polderan: 1time distance for first element,two times distance for rest of elements, now you add bank times distances, it forms as 2times distance for first and three times the rest and banktimes-1 value+index, so you have to add banktimes value, that is gotten as allindexes+offset filled - allindexes+offset filled-alldistances the last which itself comes by filling in the offset and all indexes and
14:50 polderan: eliminating the constants by perbanktimes so we get 1time value+index and banktimes-1*2times value+index, so in other words after addition it combines as one times distance for first element and two times for second and other elements, removing all distances it's one elements distance missing, which removed from all the distances gets one a single distance, and this added to all values
14:50 polderan: allows to eliminate one value using an index on it too, and all values -allbutonevalue missing is the final operation accessing the value at index, the logics behind hence very simple arithmetic i.e simple linear algebra based derivative in integral computation but it is also expressed in logics as that resembles elimination based of mutual inclusion or exclusion. computation is simpler than
14:51 polderan: data access through compiling procedures. and what's also easy is encoding and decoding the powers to smaller and higher weights per power. result is super extreme performance machine when those accesses get mixed so data access to access instructions, and computation access through compiling for execution.
16:27 zmike: DavidHeidelberg: you are also welcome to ack ^
16:33 DavidHeidelberg: zmike: ack. Btw. why I need the bump? Some useful fixes?
16:33 zmike: yes
16:33 zmike: need to keep bumping
16:33 zmike: always
16:34 DavidHeidelberg: This would be interesting adept for the automated bumps then
16:34 zmike: yeah, doing a saturday bump every week (there's a guaranteed friday tag) would be nice
16:50 tonyk: we are going to have a DRM Microconference at Linux Plumbers this year: https://lore.kernel.org/dri-devel/92bacfe3-efac-4615-9d30-a6215f6bba29@igalia.com/
17:02 jasoneasydraw: so I launch my last warning to your bomber and assaulting networks with your trash stories, you die through our hands if you talk to me in public, assault me or trash me through calling whores my wife, she is a thieve, who was taken care of already, I gave her crank gangsters a last warning if they do not honor those, and keep talking to me about me or harass my hotel we spawn a hitman
17:02 jasoneasydraw: list against your shit scum. and what airlied talks about is a lie, they assaulted me with British trash before I ever threatened them, you keep doing it retarded worms and soon I come after you with my team. it's just I have a list of assaulters to treat an extensive one, they end up in either similar situation broken bones and no teeth as the whores who trashed me or maybe we kill
17:02 jasoneasydraw: them I am deciding over this, we have loads of guns to do it.
18:12 p0ch1ta: Hi
18:13 alyssa: mareko: sorry I missed the MR, but what's the motivation for "nir: validate src_type of store_output"?
18:14 p0ch1ta: I was interested in the DRM task : Remove driver dependency on FB_DEVICE. I was wondering how to get started with it
18:14 alyssa: it blows up asahi, which neither reads nor writes src type. easy to fix - my fault for being sloppy - but I'm not sure why we have src_type at all for store_output
18:18 alyssa: I don't really care - just took *checks clock* 5 minutes to deal with, faster than a ci pipeline would've been :p
18:18 alyssa: but also if we could just torch store_output's src_type, that would be cool
18:24 jenatali: alyssa: It's currently load-bearing for us, just FYI
18:24 alyssa: jenatali: Terrifying! :-D
18:25 jenatali: DXIL annotates loads/stores with function overloads, so i32 vs i16 vs f32 vs f16 are different functions to call
18:25 alyssa: ouch
19:41 mareko: alyssa: I guess there is some reason for src_type with mediump if NIR does the lowering
19:45 mareko: alyssa: radeonsi also uses src_type for something, but that could be eliminated
20:01 alyssa: hmm
22:15 Company: so, if I'm using GL and want to create an explicit sync object
22:16 Company: that I can later pass on with a dmabuf so that it can potentially be ued with wayland at some point
22:16 Company: how am I meant to do that?
22:17 Company: do I need to create it outside of GL and import it for signaling?
22:17 Company: or does GL have a way for me to create it and just export the fd?
22:18 Company:looking at the Mutter and wlroots MRs and they don't make sense yet
22:22 airlied: Company: is that https://registry.khronos.org/EGL/extensions/ANDROID/EGL_ANDROID_native_fence_sync.txt ?
22:22 daniels: yeah
22:22 daniels: as I said earlier
22:22 daniels: https://gitlab.freedesktop.org/wayland/weston/-/blob/main/libweston/renderer-gl/gl-renderer.c#L434-485
22:24 Company: how does that get the acquire and release points?
22:30 Company:thinks his mental model is still missing an indirection somewhere
22:40 mareko: alyssa: the motivation was that src_type didn't match bit_size when I was writing a shader in NIR, which broke radeonsi, which could have been caught by nir_validate
22:42 mareko: alyssa: we could make src_type indicate float/int/uint, but not the bit size, which is already in nir_def
23:11 alyssa: mareko: makes sense.
23:11 alyssa: I'm still not solid on why any backend other than DXIL and Zink care about the float/int/uint-ness, though
23:11 alyssa: but it's not a big deal