00:01 airlied: we are a public project, if there are clicks to be mined from our discussions, someone will mine them
00:01 karolherbst: yeah and even if it would be a confidential issue, it would be open to like 200 people or so... and if somebody feels like posting about it, nothing we could do anyway
00:01 karolherbst: so yeah, so maybe just a public issue and just get it over with
00:04 daniels: please go for it
00:09 karolherbst: okay, thanks. I have an idea how to start it, so expect something soonish
01:59 macromorgan: so I have a DSI panel that doesn't need an init sequence (thinking panel-simple), but it does need the DSI commands to enter sleep/exit sleep/turn on/turn off. Would it be acceptable to add those to a panel in panel-simple, or do I need my own driver just to do those handful of DSI commands? Additional complication, I have no idea what controller chip they're using... the vendor is of little help in that regard.
02:06 karolherbst: as per the discussion above, I wrote up a draft: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40109
02:22 airlied: karolherbst: I think you are splitting it a bit fine, I'd drop the subprojects bit, because AI refactoring across the project shouldn't be blocked by a fiefdom
02:23 karolherbst: airlied: yeah.. maybe, but I think you can already draw this conclusion from the existing "rules"
02:23 karolherbst: "It is up to the maintainers of each specific part to decide what is acceptable for them and to direct the development of that part."
02:23 airlied: I don't think we need to call it out further though
02:24 karolherbst: so it felt natural to spell it out to either 1. accept it as a conclusion or 2. say that project wide refactorings are okay regardless
02:24 airlied: maintainers can maintain their projects, but the project has to be maintainable
02:25 karolherbst: right.. but I'm also kinda interested to hear how others think about that part
02:26 karolherbst: but I do agree that it could lead up to conflict and it's worth bringing up
02:30 airlied: cmarcelo, glehmann : having variable does make flexible dimensions handling a bit easier :-(
02:41 alyssa: I'm not going to weigh in on tonight's discussion and I think everyone knows what I'd say anyway but acknowledging I've read most of it.
02:41 tarceri: kisak: haha, well the madness pays the bills :P
02:42 airlied: cmarcelo, glehmann : might spend some time on a cleanup pass rather than going much further down the derefs chain
04:45 cmarcelo: airlied: ack
05:26 MoeIcenowy: mripard: well the document of struct drm_mode_create_dumb seems to declare dumb buffers are only for `linear framebuffer memory with single-plane RGB data`
06:18 MoeIcenowy: Could anyone take a look at https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39084 ? (which is just a trivial architecture-specific deassembler quirk
06:40 MoeIcenowy: MrCooper: unfortunately for drivers that do not do acceleration by themselves, providing a custom GEM ioctl sounds overkill
06:41 MoeIcenowy: I do agree with tzimmermann's DRM_IOCTL_MODE_CREATE_DUMB2 proposal
06:57 airlied: I've made some headway on flex dim with derefs, maybe I'll just keep trucking
08:06 MrCooper: MoeIcenowy: more like necessary than overkill
10:39 daniels: MoeIcenowy: there's also dma-heaps which exist to support memory allocation
11:43 emersion: +1
14:05 tzimmermann: mripard, Mrcooper, javierm, my understanding of 'dumb' has been that there's no guarantee about possible hardware rendering. only memcpy and scanout would be supported. a 'smart buffer' would also take hardware rendering into account. a dumb buffer might also do that, or not
14:07 tzimmermann: the toy interface of CREATE_DUMB is somewhat unrelated
15:31 eric_engestrom: catching up on last night's discussion, and I just want to say: thank you karolherbst ❤️
15:33 eric_engestrom: (and everyone else for chiming in, but special thanks to karol for pushing through and not accepting the until-now "lack of decision" as a "decision to not decide")
15:35 pac85: Thx karolherbst !
15:39 MoeIcenowy: MrCooper, daniels, javierm: I hope to make KMS interfaces not so fragmented, at least for drivers with well-known buffer formats and modifiers
15:40 MoeIcenowy: every piece of fragmentation here will be then burden in the Mesa KMSRO driver
15:40 MoeIcenowy: daniels: BTW do you still have any further opinions on the zink kmsro MR?
16:03 lynxeye: preferably we would get away from allocating via the abused dumb interface from the scanout driver for renderonly. I think there was some proposal to have a dma-buf heap linked from the scanout device. If your GPU side driver recognizes the modifier, it should know how to lay out the buffer and then it's mostly a matter of allocating a correctly sized buffer from a dma-buf heap matching the scanout constraints.
16:05 CounterPillow: "abused dumb interface" wow, don't pile on even more abuse on that poor interface :(
16:10 MoeIcenowy: poor CREATE_DUMB in the era of everyone tiling buffers to reduce bandwidth...
16:12 MrCooper: if anything it's poor for getting abused for things it wasn't intended for
17:07 S9: Anyone is around familiar with Raven Ridge PSP/RLC loading?
20:23 emersion: yup, thanks karolherbst