On Thu, 24 Jan 2019 at 16:22, Rob Herring <r...@kernel.org> wrote: > > On Thu, Jan 24, 2019 at 9:14 AM Emil Velikov <emil.l.veli...@gmail.com> wrote: > > > > Hi all, > > > > Fwiw I'm ok with the idea, as pointed out in 2/2 as-is this is a > > partial solution. > > Never the less is some solution for the problem we have. > > > > With that said the series is: > > Acked-by: Emil Velikov <emil.veli...@collabora.com> > > > > On Wed, 23 Jan 2019 at 23:42, Alyssa Rosenzweig <aly...@rosenzweig.io> > > wrote: > > > > > > > I've started looking at the lima and panfrost drivers. The many > > > > combinations of Mali GPUs and DC isn't going to scale. The lima and > > > > panfrost trees can't even co-exist as both define a rockchip winsys > > > > which load different GPU drivers. The same will be true for meson, > > > > hisilicon, allwinner, etc. i.MX is about to be in the same boat > > > > needing to support both etnaviv and freedreno. > > > > > > As Rob stated, Mali being used by basically everyone at one point or > > > another has led to a nightmare in the winsys. I agree that dealing with > > > the loader can happen later, but honestly, just having the centralised > > > kmsro winsys (that all of pl111/rockchip/meson/sunxi/etc point to) that > > > tries all of vc4/v3d/panfrost/lima/etc would be a marked improvement on > > > the present situation. > > > > > > There are a lot of DRM drivers out there, sure, and it _is_ better to > > > handle something generically in the loader. But for the much more > > > immediate goal of letting both Lima and Panfrost coexist on > > > Rockchip/Meson, this is a good start. > > > > AFAICT for a comprehensive solution, that handles the above usescases, > > we would need: > > > > - a form or drm driver name to kms_ro mapping > > Personally I'm leaning towards a drirc style file. Thus no patching or > > rebuilding of mesa is needed and no more symlinks. > > That would be nice. Based on the discussion on patch 2, I'm not really > clear on where all the support for this needs to go. That's just my > lack of X11 details. > > > - a form of KMSRO to GPU device mapping > > Thus we can use that instead of the hardcoded vc4 in the proposed KMSRO. > > Ideally they would live alongside the previous mappings, to avoid > > patching/rebuilding. >
> I don't think we have any cases of 2 different embedded GPUs in one > system (but SoC vendors have done crazier things) and the number of > GPUs is not a huge set. > Multiple devices is another concern and as you pointed out not that pressing. > Also, if we require some config file to tell us what GPU, then we > still have to update that config file for each and every new system. > I'd rather see things work by default and we only need a config file > for the special cases. > Something that picks a driver from a known list sounds like a good enough default. Aka your drmOpenWithType() patch, if I understood you correctly. Obviously we can polish that when needed. -Emil _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
