00:29HdkR: The Intel DG1 still hasn't shipped right? Got a special kind of bug that only repros on Iris/i965 and testing on Ice Lake isn't the nicest :P
00:32mareko: bnieuwenhuizen: will modifiers need to invoke addrlib and can they skip it entirely?
00:36bnieuwenhuizen: mareko: currently doing entirely my own thing for selecting swizzle and then just invoking addrlib
00:37bnieuwenhuizen: can skip entirely if we really want to
00:37bnieuwenhuizen: However, I thought this would be easier to make consistent with filling in all extra info fields possibly used in the driver
00:37airlied: HdkR: not shipped
00:37HdkR: It's a sad time
00:38bnieuwenhuizen: + doing the actual swizzling for the displayable DCC transposition is a pain
00:56mareko: bnieuwenhuizen: what swizzling?
00:56mareko: bnieuwenhuizen: the retile map is in the buffer, it doesn't have to be recomputed
00:58bnieuwenhuizen: mareko: the party that allocates the buffer still has to compute the retile map no?
00:58bnieuwenhuizen: wrt swizzling, meant the retile map
00:58mareko: bnieuwenhuizen: yes that's right
00:59mareko: I meant on import
00:59bnieuwenhuizen: so since modifiers also have a negotation component, even the allocating party will use the swizzle path
00:59bnieuwenhuizen: will use the modifier path*
05:40himanshujha19964: I see few DCS commands being implemented at `drivers/gpu/drm/drm_mipi_dsi.c` but couldn't find implementation of `write_memory_start/continue` DCS command ?
05:41himanshujha19964: Is there any reason ?
07:06HdkR: Alright, solved my i965/iris problem. I just had to suffer through Ice Lake compile problems instead of working on my Threadrippre :P
07:31Yuti: Does atomic functions in DRM subsystem execute in atomic context?
07:47emersion: Yuti: what do you mean by "atomic context"?
07:49Yuti: emersion: means it cannot be interrupted by any interrupt when executing. Like atomic variables.
07:49MrCooper: emersion: "atomic context" in the kernel usually refers to an execution context that cannot block, e.g. an IRQ handler
07:50MrCooper: or while holding a spinlock
07:52emersion: ah, ok
07:52emersion: Yuti: no
07:52emersion: atomic ioctls are just atomic from userspace pov
08:03MrCooper: yeah, "atomic" in the case of KMS refers to a transaction being applied completely or not at all
08:09pinchartl: sravn: would you mind picking up "[PATCH] drm/panel: simple: Set connector type for DSI panels" ?
08:20pq: emersion, Re: link-status doc; I think I'll see v3 before commenting again. I don't really have further input to v2.
08:22emersion: right, will do!
09:46linkmauve: Hi, since it’s unusably slow on Nouveau I’m going to exchange my Nvidia 1070 against a Radeon 580, anything I should be aware of before jumping from Intel to Intel+AMD on Mesa?
09:48emersion: i have a RX 580 as well, but with an amd cpu. works fine here
09:48linkmauve: Intel+Nouveau was pretty terrible at performances, much slower than Intel alone at least.
09:48linkmauve: Ok cool. :)
09:51linkmauve: I’m looking at https://drmdb.emersion.fr/devices/bf786ec197a1 and it doesn’t do any modifiers?
09:52emersion: amd doesn't do modfiiers
09:52linkmauve: Nor a bunch of useful plane properties. :/
09:52emersion: it's something being discussed rn though
09:53emersion: yeah just primary/cursor with the basic stuff and that's it
09:53emersion: though for a desktop power efficiency isn't as important
09:53linkmauve: I guess I can still use Intel for scanout in that case.
09:54emersion: but will the intel iGPU still be available?
09:54emersion: my iGPU gets disabled when i have an eGPU
09:54linkmauve: That’s what I did with the Nvidia, since Nouveau was too broken to let Weston output anything when using that card as the DRM node.
09:54emersion: maybe that's specific to my motherboard though
09:54linkmauve: At least when I plug the Nvidia card, the Intel one stays fully usable yeah.
09:55emersion: i wouldn't bet on render-on-amd scanout-on-intel being efficient
09:55emersion: even if amd doesn't have explicit modifiers, it sitll does implicit modifiers
10:01linkmauve: The previous owner apparently stopped using it due to: https://gitlab.freedesktop.org/mesa/mesa/-/issues/1370
10:02linkmauve: Well, s/previous/current/
10:03emersion: > I'm getting convinced that it's actually a temperature problem
10:03emersion: hm hm
10:03ccr: ye ancient kernel at least
10:05linkmauve: ccr, yeah, after that someone gave him a Nvidia card and he’s been somewhat happy since then.
10:06linkmauve: It’s this exact model: https://www.sapphiretech.com/en/consumer/pulse-rx-580-8g-g5
10:08emersion: ah, i think i have exactly this one
10:08linkmauve: Heh. ^^
10:30kusma: jekstrand: I'm seeing an assert in ANV when trying to use scalars from xfb... The problem seems to be that nir_lower_io_to_vectors duplicates a variable that has data.explicit_xfb_buffer set, but the original doesn't get removed from the outputs-array. This cause the sanity-checking code at the end of nir_gather_xfb_info_with_varyings assert, because there's now two overlapping outputs...
10:55kusma: jenatali: I submitted this, which makes the assert go away, but I kinda doubt it's the right fix: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5329
10:55kusma: jenatali: eh, sorry, that one was meant for jekstrand
13:49jekstrand: kusma: Uh... That sounds like a fun bug...
14:35kusma: jekstrand: heh, yeah...
14:37ccr: super happy fun bug time
14:38jekstrand: kusma: I kind-of wonder of we should just not vectorize things that are used for XFB.
14:38jekstrand: That seems like the obvious thing
14:38kusma: jekstrand: Yeah, perhaps.
14:38kusma: That would almost be to remove one line from my patch, I think :-P
14:39kusma: jekstrand: the other possiblity could be to clear the xfb-setting from the clone...
14:39jekstrand: kusma: Well, we could vectorize I/O as long as the XFB offsets match up
14:39kusma: jekstrand: Not sure what does the right thing, TBH. I mean, we still keep those vars around. But perhaps they're completely detached?
14:40kusma: jekstrand: So, this is a pure optimization, right?
14:40kusma: jekstrand: In other words, if we don't vectorize anything, does things still *work*?
14:40jekstrand: We could also vectorize, delete the XFB stuff from the vector one, and leave the non-vector one lying around for its XFB information.
14:40jekstrand: Yeah, vectorization is a pure optimization
14:41kusma: Yeah, then I think I would drop vectorizing as a first step, and see if oppurtunistic vectorization is a gain or not...
14:41jekstrand: From a HW perspective, we can compact and re-arrange and vectorize as much as we want so long as we keep the per-component XFB information intact.
14:41kusma: jekstrand: Aha...
14:42jekstrand: I just don't know how to do that with the current data structures
14:42kusma: Yeah, that's a different question
14:43kusma: I think I'll update my patch with a slightly bigger (and less incorrect) hammer, and leave optimization to someone who knows what they're doing here :-P
14:43jekstrand: That sounds fine
14:43jekstrand: I'm not *that* inclined to worry about optimizing XFB
16:47alyssa: besides legacy, is there a reason we still do general opts (const folding, etc) in GLSL?
16:47alyssa: (when glsl_to_nir is in use)
16:47krh: because last person to touch GLSL owns it
16:47alyssa: krh: Oof.
16:47imirkin_: iirc yes
16:47jekstrand: alyssa: Constant folding is required to properly support the GLSL language
16:47imirkin_: some things require the const folding
16:48jekstrand: Like you can specify an array size as a constant expression
16:48alyssa: but NIR chokes on that then?
16:48alyssa: Makes enough sense, I guess.
16:48jekstrand: NIR doesn't have a concept of array sizes that aren't immediates
16:48jekstrand: There may be a few other optimizations that are required for correctly implementing GLSL
16:49jekstrand: I'm not sure what they are off-hand though
16:50alyssa:is hacking on the if-constant-fp16 issue again but nyeeoof
16:54alyssa: Derefs turn my brain to guacamole
17:03MrCooper: I hope you like guacamole then (I don't :)
17:04imirkin_: i can't help but think of hannibal in this instance...
17:20alyssa: ...Yeah, I am really not making progress.
17:21alyssa: At first I thought we need to handle the if specially (due to boolean vs float types, differing precisions, etc.) so I added a find_lowerable_rvalues_vistor::visit_enter(ir_if *ir) that forced SHOULD_LOWER always
17:22alyssa: that gets a f162f instruction thrown in the if, but it's unclear how useful that is, because...
17:22alyssa: in this shader, it ends up working out as constants, so GLSL constant folding will turn it into just a regular 32-bit vec4 constant in the if.
17:22alyssa: so I disabled GLSL constant folding, so now we have the literal f2f16 in there piped into NIR
17:23alyssa: And for good measure disable opt_if and opt_peephole_select in mesa/st
17:23alyssa: but again, NIR's constant folding will end up with a load_const inside the if and nothing else
17:23alyssa: (a 32-bit constant)
17:23alyssa: which gets fed into a 32-bit phi node
17:23ngcortes: heads up: mesa_master results are being temporarily purged to commit a db change
17:23alyssa: so it's still 32-bit
17:24alyssa: so either way it really ends up being 32-bit, since the shader local is being backed as 32-bit (in load/store_deref's)
17:24alyssa: now -- maybe the problem is that the locals are 32-bit at all
17:24alyssa: but I'd point out *all* the locals are 32-bit here, despite *all* being mediump
17:25alyssa: it's just that in the non-conditional case, NIR optimization will chew through all the derefs and end up with f2f16(f2f32(..)) nested patterns which optimize out leaving only the 16-bit goodness
17:25alyssa: whereas with conditionals NIR can't see through that so even though the operation itself is done at 16-bit, the phi (or csel) is 32-bit
17:26alyssa: AFAIU, the options are either teaching NIR to pipe conversions through phi nodes -- something like ('f2fmp', ('phi', a, b)) to ('phi', ('f2fmp', a), ('f2fmp', b)) like I proposed for vectors
17:27alyssa: or lowering the variables themselves to be 16-bit, which I suppose is probably better but a pretty significant change in design from what we do now in lower_precision
17:27alyssa: (I think doing it that way would eliminate a lot of the conversions at any rate)
17:28alyssa: (The ones that ordinarily get optimized algebraically, if we had temps/locals as 16-bit they wouldn't be emitted at all, which might be "cleaner")
17:28alyssa: krh: mareko: Thoughts? ^^
18:28tango_: alyssa: there's a thread from 2018 (16-bit comparisons in NIR) that might be relevant to your interests
18:30tango_: alyssa: https://lists.freedesktop.org/archives/mesa-dev/2018-April/192751.html
18:33tango_: alyssa: IIRC that's where it was decided to make everything 32-bit
18:36tango_: (for conditionals)
18:44alyssa: tango_: NIR has 1-bit booleans nowadays, that part works okay so we can theoretically 16-bit in the backend
18:46alyssa: but thank you for the link
19:23hat|: got another GPU reset while playing, but not KSP this time: http://paste.awesom.eu/brn3
19:33hat|: should I create an issue on gitlab or similar?
19:51pepp: hat|: sounds similar to https://gitlab.freedesktop.org/drm/amd/-/issues/1119
20:09hat|: ah right same card indeed
20:09hat|: I should have picked up something else :(
20:25danvet: jstultz, nice article
20:28jstultz: danvet: thanks! still have to get part two through final editing.. I give Jon a lot of trouble with my poor writing skills. :)
21:07Lyude: did something just happen to https://patchwork.freedesktop.org
21:08Lyude: daniels: ^ ?
21:09daniels: I haven't done anything to it, no
21:09daniels: but it sure isn't responding here
21:10Lyude: oh-there it goes
22:57jekstrand: bnieuwenhuizen: The WSI synchronization saga continues..... I figured out #3039 and I don't see a way out. Not with the current kernel APIs, anyway.
23:01bnieuwenhuizen: jekstrand: everyone has their own issues :) we effectively don't have a way to not set the WRITE bit on AMD because of how the kernel driver deals with the BO fences ....
23:01airlied: do we get to wreite new kernel apis?
23:02bnieuwenhuizen: airlied: I think the kernel patch is already written :P
23:02bnieuwenhuizen: just means things depend on a new kernel version I guess
23:06bnieuwenhuizen: jekstrand: the other thing is in radv we assume that once we acquire the buffer it is completely idle from the windowing system perspective. Might be very hinky with compositors in play :P
23:11pcercuei: Quick question on the fbdev emulation
23:13pcercuei: I have a panel with a built-in controller and framebuffer. It does the refresh itself, I only need to DMA data when there is a new frame to display
23:14pcercuei: This works fine with regular apps, as I can trigger a DMA transfer when there's a new GEM buffer to upload
23:14pcercuei: It doesn't work with fbdev emulation, which seems to rely on the fact that the CRTC will constantly upload the fbdev data
23:16pcercuei: So I'm wondering if there's a built-in mechanism to force a periodic refresh of the same GEM buffer
23:36pcercuei:notices a file named drm_self_refresh_helper.c
23:47imirkin_: pcercuei: you're supposed to refetch the contents on every vblank
23:49pcercuei: Why though? It doesn't make sense to reupload the exact same frame if it didn't change
23:49imirkin_: because that's how most GPUs work
23:49imirkin_: they scan out the fb on every vblank
23:49pcercuei: well, I'm not working with "most GPUs"
23:49imirkin_: because they have to keep sending the same frame contents each time anyways
23:50imirkin_: i understand that, but it's the model behind the kms api
23:50imirkin_: i think there _is_ some kind of damage api
23:50imirkin_: but i'm not 100% sure on the details. and i'm sure fbdev doesn't make use of it. but it could.
23:50pcercuei: Note that sending the frame contents on each modeset works fine, *except* for the fbdev emulation
23:50imirkin_: or X
23:51imirkin_: or anything else which does frontbuffer rendering
23:51HdkR: imirkin_: Doesn't panel self-refresh destroy the ideal case of refetching framebuffer contents every vblank?
23:51imirkin_: HdkR: don't know the details, sorry
23:52HdkR: Like, that's the point of it. You don't have to burn resource refetching an unchanged frame
23:52HdkR: Which seems to be what pcercuei found just now in the drm files
23:53HdkR: The panel is still refreshing, just from its internal framebuffer data rather than new frames coming over the wire
23:54HdkR: Supposedly this is well supported on Windows+Intel configs. Makes sense that a bit of work could be done to get fbdev to support it
23:55anholt_: pcercuei: have you implemented the dirty callback in your framebuffer?
23:55pcercuei: I think a lot of DBI/DSI panels are self-refreshing
23:55pcercuei: anholt_: no, why?
23:55anholt_: pcercuei: sounds like the thing you're looking for
23:56pcercuei: isn't that a thing for the DRM client, not the DRM driver though?
23:56anholt_: pcercuei: check out mipi_dbi_fb_dirty as the upload path for similar hardware
23:57anholt_: core stuff handles "how do I know if fbdev updated my pixels"
23:59pcercuei: I'll look into it, thanks