Hey, On Thu, 2019-05-09 at 11:16 +0200, Frantisek Rysanek wrote: > Dear gentlemen, > > I've noticed your debate - the topic is something simple enough for > me to superficially grasp and "blitting in the DRI/drmfb" is > something I've been wondering about for a while. > Thanks for sharing your insight. > > What actually prompted me to respond is this: > vaguely in the context of your debate, this is what Google has > revealed to my casual query on the topic: > > https://www.phoronix.com/scan.php?page=news_item&px=Intel-Mesa-Blitter > -RIP > > It's not a blow at the heart of the hypothetical "blitting API in > DRI", but given the market share of Intel, it does look like a splash > of cold water in the broader context, or does it? Not really actually. I agree that mesa is not the right place to handle 2D blitters, so it makes sense to kick them out of it :) As for DRI2, it seems that the interface is pretty much deprecated with Wayland and I think everyone wants to go towards that, so I don't plan on any DRI2 integration at this stage. This would typically be used in a Xorg DDX anyway (not by applications), so DRI2 wouldn't even be necessary, Note that DRI2 and DRM are two very distinct things and I'm only interested in the DRM side sofar. > If the "DRI blitting API" should go forward, could the Intel DRI > driver in the kernel maybe take inspiration from MESA's approach? The idea would be that the Intel DRM driver stays supported by mesa for the 3D rendering part and by DRM/KMS for the display part. If the hardware has fixed-pipeline 2D blocks, then these can be integrated with the new API I'm interested in bringing up, which would be a third distinct thing. > I know I know - Intel may be strongish in the desktop and general x86 > market, but apart from the Nvidia vs. AMD wars, Linux actually runs > on a number of non-x86 embedded SoCs that have a plethora of small > proprietary GPU's, the CPU horsepower and RAM bandwidth may be scarce > (though not as a rule), X11 is not mandatory and HW blitting may > actually matter... It sure does, indeed! The situation you are describing for non-x86 is exactly the problem I want to help tackle with this :) Cheers and thanks for your interest, Paul -- Paul Kocialkowski, Bootlin Embedded Linux and kernel engineering https://bootlin.com
