01:45 <digetx> maxim[m]: DavidHeidelberg: thank you

02:49 <digetx> DavidHeidelberg: the extra compilers will be good to use, but only if it's easy to do

09:14 <digetx> tagr: could you please start giving feedback to https://docs.google.com/document/d/1yRYJTqqwwsaAv_EdN2MzxkGpRMuTOxxQMj6JGxa4jyE/edit#

09:23 <digetx> the incremental updates are not a problem at all; the problem is that I need to convey to you all the problems that we have now, theirs solutions and new ideas, so that we could agree on it all, and you're not talking each time I try to do that

09:36 <cyndis> digetx: I will make a todo list, and can review plans. Regarding viability of the present UAPI, I have tried to take into account any future changes we might do under the hood, and am not aware of anything in the UAPI that could block e.g. introduction of software scheduling, considering the overall design limits. the UAPI is also still in staging, so we can even change things backwards-incompatibly

09:36 <cyndis> if needed.

09:38 <cyndis> considering the above, I really have not wanted to go too deep into any further design work before the basis has been confirmed. too great risk of that work being left on the table.

09:43 <cyndis> GR2D and GR3D also seem to work fine as is; is the mesa driver submitting work that would deadlock if the kernel doesn't reorder it before submitting to hardware?

09:52 <digetx> the driver doesn't work at all in a certain kernel configurations because DMA API isn't implemented properly, it's ~x2 slower than the grate's experimental driver (yes! half of the time is spent in the job submission path even with the DMA-sync bypass hacks that we have!), there is no implicit fencing and so on

09:54 <digetx> these all are the basics

09:58 <digetx> it's great that we now have basic support of the newer SoCs, but newer SoCs aren't the biggest problem we have

10:07 <digetx> these all are very solvable problems, but they need to be discussed to get us on the same page

10:08 <digetx> some of the problems may require radical changes

10:09 <digetx> that's why I'm not very happy seeing that the old code is getting extended

10:15 <digetx> it's okay to start with enabling newer hardware, I understand that it's a priority for you, but then please take a pause and let's fix those core problems

10:15 <cyndis> if you have any writeup on those problems, e.g. if you think there is some specific part that causes it to be slow, what part of DMA API isn't implemented properly, etc. that would be a useful baseline

10:16 <cyndis> I'm not opposed to radical changes and I think we will have some but they should be done in an incremental manner

10:18 <cyndis> I agree with fixing the core problems, I just think doing that while keeping the legacy UAPI alive at the same time is unnecessarily difficult or impossible

10:18 <cyndis> or would direct things in the wrong direction

10:42 <digetx> I'll document all the current problems

10:43 <digetx> the incremental updates are fine, but you need to have a full picture in order to define the steps

10:51 <digetx> it also requires to have maintainer on the same page, otherwise you're risking to waste a lot of time and energy on reviews or get frustrated waiting for any replies at all

13:51 <jenneron[m]> Add suport for HDMI audio on Microsoft Surface RT.

13:51 <jenneron[m]> Error: WARNING: 'suport' may be misspelled - perhaps 'support'?

13:51 <jenneron[m]> it's smart

16:54 <DavidHeidelberg> jenneron next step would be Kernel Copilot "# write me a i2c device driver for light sensor" Copilot: yes sir, I'm on it! :D

16:56 <DavidHeidelberg> just thinking... we could learn AI on downstream kernels drivers converted to mainline and then just make it automatically convert stuff :D

17:11 <p2-mate> :)