<div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Mar 29, 2020, 4:09 PM Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sun, Mar 29, 2020 at 6:06 PM Bas Nieuwenhuizen<br>
<<a href="mailto:bas@basnieuwenhuizen.nl" target="_blank" rel="noreferrer">bas@basnieuwenhuizen.nl</a>> wrote:<br>
><br>
> On Sun, Mar 29, 2020 at 11:36 PM Eric Engestrom <<a href="mailto:eric@engestrom.ch" target="_blank" rel="noreferrer">eric@engestrom.ch</a>> wrote:<br>
> ><br>
> ><br>
> ><br>
> > On 2020-03-29 at 20:58, Jason Ekstrand <<a href="mailto:jason@jlekstrand.net" target="_blank" rel="noreferrer">jason@jlekstrand.net</a>> wrote:<br>
> > > On Sun, Mar 29, 2020 at 11:45 AM Kristian Høgsberg <<a href="mailto:hoegsberg@gmail.com" target="_blank" rel="noreferrer">hoegsberg@gmail.com</a>> wrote:<br>
> > > ><br>
> > > > As for loading, doesn't glvnd solve that?<br>
> > ><br>
> > > Not really.  There are still problems if you have HW drivers from both<br>
> > > repos on the same system and someone has to decide which one to use.<br>
> > > We would either have to come up with a good solution to that problem<br>
> > > or we would have to delete/disable all of the drivers still in master<br>
> > > in the LTS branch.  In any case, there are real problems to solve<br>
> > > there.<br>
> ><br>
> > That's a simple packaging issue, and IMO it's ok to just say in the announcement<br>
> > email "this 'legacy drivers' branch also contains old versions of the new<br>
> > drivers. If you ship both these and a modern version of Mesa, make sure<br>
> > not to build the same drivers from both trees".<br>
> ><br>
> > Packagers will then pick the right `-D{dri,gallium,vulkan}-drivers=` lists<br>
> > to avoid collisions on their distros.<br>
><br>
> Wouldn't this be much safer anyway with a small patch to remove those<br>
> "new" drivers from the meson options list?<br>
<br>
It may not be that simple.  If, for instance, we wanted to cut of Gen7<br>
Vulkan, we would somehow have to provide an option to limit which<br>
hardware generations are supported in the LTS branch.  Either that or<br>
just delete support for Gen8+ somehow.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">The "loader problem" that I was thinking of is the while the dri driver interface is theoretically a stable API nobody tests mixing loaders from one mesa release with drivers from another. glvnd does solve that problem and deciding which Intel gens should be supported by i965 or iris *is* a simple packaging problem.</div><div dir="auto"><br></div><div dir="auto">As for anv splitting out gen7 support that's orthogonal, local to anv and less relevant to the decision about dropping legacy dri drivers and go all gallium. I know it's close to your heart, of course, but since vulkan had a standard loader interface since day 1, it seems like something you can decide on independently. </div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
--Jason<br>
</blockquote></div></div></div>