On 2019-06-21 5:44 p.m., Daniel Vetter wrote: > On Fri, Jun 21, 2019 at 05:15:22PM +0200, Michel Dänzer wrote: >> On 2019-06-21 1:50 p.m., Daniel Vetter wrote: >>> On Fri, Jun 21, 2019 at 1:37 PM Christian König >>> <ckoenig.leichtzumerken@xxxxxxxxx> wrote: >>>> Am 21.06.19 um 13:03 schrieb Daniel Vetter: >>>>> So if you want to depracate render functionality on primary nodes, you >>>>> _have_ to do that hiding in userspace. Or you'll break a lot of >>>>> compositors everywhere. Just testing -amdgpu doesn't really prove >>>>> anything here. So you won't move the larger ecosystem with this at >>>>> all, that ship sailed. >>>> >>>> So what else can we do? That sounds like you suggest we should >>>> completely drop render node functionality. >>>> >>>> I mean it's not my preferred option, but certainly something that >>>> everybody could do. >>>> >>>> My primary concern is that we somehow need to get rid of thinks like GEM >>>> flink and all that other crufty stuff we still have around on the >>>> primary node (we should probably make a list of that). >>>> >>>> Switching everything over to render nodes just sounded like the best >>>> alternative so far to archive that. >>> >>> tbh I do like that plan too, but it's a lot more work. And I think to >>> have any push whatsoever we probably need to roll it out in gbm as a >>> hack to keep things going. But probably not enough. >>> >>> I also think that at least some compositors will bother to do the >>> right thing, and actually bother with render nodes and all that >>> correctly. It's just that there's way more which dont. >> >> With amdgpu, we can make userspace always use render nodes for rendering >> with changes to libdrm_amdgpu/radeonsi/xf86-video-amdgpu (and maybe some >> amdgpu-pro components) only. No GBM/compositor changes needed. > > This is a very non-exhaustive list of userspace that runs on your driver > ... This wayland compositor thing, actually shipping now, and there's many :-) You don't seem to understand what I wrote. Everything will work at least as well as now, without any other changes. >>>>> Once we picked a color it's a simple technical matter of how to roll >>>>> it out, using Kconfig options, or only enabling on new hw, or "merge >>>>> and fix the regressions as they come" or any of the other well proven >>>>> paths forward. >>>> >>>> Yeah, the problem is I don't see an option which currently works for >>>> everyone. >>>> >>>> I absolutely need a grace time of multiple years until we can apply this >>>> to amdgpu/radeon. >>> >>> Yeah that's what I meant with "pick a color, pick a way to roll it >>> out". "enable for new hw, roll out years and years later" is one of >>> the options for roll out. >> >> One gotcha being that generic userspace such as the Xorg modesetting >> driver may still try to use phased out functionality such as DRI2 with >> new hardware. > > There's a lot more generic userspace than -modesetting. That is affected by phasing out DRI2 related functionality? (I thought that was the context of this sub-sub-thread) > That was the entire point of kms, and it succeed really well. That's > why I don't think amdgpu doing their own flavour pick is going to help > anyone here, Other drivers are welcome to emulate amdgpu's design making the above possible. :) > except maybe if all you care about is the amd stand-alone> stack only. > But then why do you bother with this upstream stuff at all> ... I'm afraid you've lost me here. -- Earthling Michel Dänzer | https://www.amd.com Libre software enthusiast | Mesa and X developer _______________________________________________ amd-gfx mailing list amd-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/amd-gfx
