Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?

[Marek Olšák]

The first milestone:
- make src/compiler a standalone lib

is done: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4400

Marek

On Mon, Mar 30, 2020 at 11:40 AM Kristian Høgsberg 
wrote:

> On Mon, Mar 30, 2020, 7:59 AM Adam Jackson  wrote:
>
>> On Sun, 2020-03-29 at 09:45 -0700, Kristian Høgsberg wrote:
>>
>> > As for loading, doesn't glvnd solve that?
>>
>> It could. It does not. Right now there's not a (good) way for the DDX
>> driver to communicate a preferred implementation name to the GLX
>> client. xserver's glx just knows it needs an implementation named mesa,
>> and nvidia's glx, nvidia. Not a hard thing to wire up, and in fact you
>> can give multiple names and the client side will try them in sequence
>> so fallback stands a chance of working.
>>
>> Now, if we're doing that, we should maybe consider using glvnd's
>> libGLdispatch directly, as I think right now we have an ugly double-
>> indirection between glHamSandwichEXT and _mesa_HamSandwichEXT if you're
>> building for glvnd. The only thing in the world besides Mesa that cares
>> about glapi and what a DRI driver interface is is xserver, and that's a
>> detail I'd like to eliminate and the new EGL-backed GLX in Xwayland
>> gets really close to eliminating it. But if nobody else gets excited
>> that much about fixing GLX, I completely understand.
>>
>
> Yeah it would make sense to disable the double dispatch and it would be
> tempting to get rid of dri driver loading entirely then...
>
> - ajax
>>
>>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?

[Kristian Høgsberg]

On Mon, Mar 30, 2020, 7:59 AM Adam Jackson  wrote:

> On Sun, 2020-03-29 at 09:45 -0700, Kristian Høgsberg wrote:
>
> > As for loading, doesn't glvnd solve that?
>
> It could. It does not. Right now there's not a (good) way for the DDX
> driver to communicate a preferred implementation name to the GLX
> client. xserver's glx just knows it needs an implementation named mesa,
> and nvidia's glx, nvidia. Not a hard thing to wire up, and in fact you
> can give multiple names and the client side will try them in sequence
> so fallback stands a chance of working.
>
> Now, if we're doing that, we should maybe consider using glvnd's
> libGLdispatch directly, as I think right now we have an ugly double-
> indirection between glHamSandwichEXT and _mesa_HamSandwichEXT if you're
> building for glvnd. The only thing in the world besides Mesa that cares
> about glapi and what a DRI driver interface is is xserver, and that's a
> detail I'd like to eliminate and the new EGL-backed GLX in Xwayland
> gets really close to eliminating it. But if nobody else gets excited
> that much about fixing GLX, I completely understand.
>

Yeah it would make sense to disable the double dispatch and it would be
tempting to get rid of dri driver loading entirely then...

- ajax
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?

[Adam Jackson]

On Sun, 2020-03-29 at 09:45 -0700, Kristian Høgsberg wrote:

> As for loading, doesn't glvnd solve that?

It could. It does not. Right now there's not a (good) way for the DDX
driver to communicate a preferred implementation name to the GLX
client. xserver's glx just knows it needs an implementation named mesa,
and nvidia's glx, nvidia. Not a hard thing to wire up, and in fact you
can give multiple names and the client side will try them in sequence
so fallback stands a chance of working.

Now, if we're doing that, we should maybe consider using glvnd's
libGLdispatch directly, as I think right now we have an ugly double-
indirection between glHamSandwichEXT and _mesa_HamSandwichEXT if you're
building for glvnd. The only thing in the world besides Mesa that cares
about glapi and what a DRI driver interface is is xserver, and that's a
detail I'd like to eliminate and the new EGL-backed GLX in Xwayland
gets really close to eliminating it. But if nobody else gets excited
that much about fixing GLX, I completely understand.

- ajax

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?

[Kristian Høgsberg]

On Sun, Mar 29, 2020, 4:09 PM Jason Ekstrand  wrote:

> On Sun, Mar 29, 2020 at 6:06 PM Bas Nieuwenhuizen
>  wrote:
> >
> > On Sun, Mar 29, 2020 at 11:36 PM Eric Engestrom 
> wrote:
> > >
> > >
> > >
> > > On 2020-03-29 at 20:58, Jason Ekstrand  wrote:
> > > > On Sun, Mar 29, 2020 at 11:45 AM Kristian Høgsberg <
> hoegsb...@gmail.com> wrote:
> > > > >
> > > > > As for loading, doesn't glvnd solve that?
> > > >
> > > > Not really.  There are still problems if you have HW drivers from
> both
> > > > repos on the same system and someone has to decide which one to use.
> > > > We would either have to come up with a good solution to that problem
> > > > or we would have to delete/disable all of the drivers still in master
> > > > in the LTS branch.  In any case, there are real problems to solve
> > > > there.
> > >
> > > That's a simple packaging issue, and IMO it's ok to just say in the
> announcement
> > > email "this 'legacy drivers' branch also contains old versions of the
> new
> > > drivers. If you ship both these and a modern version of Mesa, make sure
> > > not to build the same drivers from both trees".
> > >
> > > Packagers will then pick the right `-D{dri,gallium,vulkan}-drivers=`
> lists
> > > to avoid collisions on their distros.
> >
> > Wouldn't this be much safer anyway with a small patch to remove those
> > "new" drivers from the meson options list?
>
> It may not be that simple.  If, for instance, we wanted to cut of Gen7
> Vulkan, we would somehow have to provide an option to limit which
> hardware generations are supported in the LTS branch.  Either that or
> just delete support for Gen8+ somehow.
>

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.

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.


> --Jason
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?

[Jason Ekstrand]

On Sun, Mar 29, 2020 at 6:06 PM Bas Nieuwenhuizen
 wrote:
>
> On Sun, Mar 29, 2020 at 11:36 PM Eric Engestrom  wrote:
> >
> >
> >
> > On 2020-03-29 at 20:58, Jason Ekstrand  wrote:
> > > On Sun, Mar 29, 2020 at 11:45 AM Kristian Høgsberg  
> > > wrote:
> > > >
> > > > As for loading, doesn't glvnd solve that?
> > >
> > > Not really.  There are still problems if you have HW drivers from both
> > > repos on the same system and someone has to decide which one to use.
> > > We would either have to come up with a good solution to that problem
> > > or we would have to delete/disable all of the drivers still in master
> > > in the LTS branch.  In any case, there are real problems to solve
> > > there.
> >
> > That's a simple packaging issue, and IMO it's ok to just say in the 
> > announcement
> > email "this 'legacy drivers' branch also contains old versions of the new
> > drivers. If you ship both these and a modern version of Mesa, make sure
> > not to build the same drivers from both trees".
> >
> > Packagers will then pick the right `-D{dri,gallium,vulkan}-drivers=` lists
> > to avoid collisions on their distros.
>
> Wouldn't this be much safer anyway with a small patch to remove those
> "new" drivers from the meson options list?

It may not be that simple.  If, for instance, we wanted to cut of Gen7
Vulkan, we would somehow have to provide an option to limit which
hardware generations are supported in the LTS branch.  Either that or
just delete support for Gen8+ somehow.

--Jason
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?

[Bas Nieuwenhuizen]

On Sun, Mar 29, 2020 at 11:36 PM Eric Engestrom  wrote:
>
>
>
> On 2020-03-29 at 20:58, Jason Ekstrand  wrote:
> > On Sun, Mar 29, 2020 at 11:45 AM Kristian Høgsberg  
> > wrote:
> > >
> > > As for loading, doesn't glvnd solve that?
> >
> > Not really.  There are still problems if you have HW drivers from both
> > repos on the same system and someone has to decide which one to use.
> > We would either have to come up with a good solution to that problem
> > or we would have to delete/disable all of the drivers still in master
> > in the LTS branch.  In any case, there are real problems to solve
> > there.
>
> That's a simple packaging issue, and IMO it's ok to just say in the 
> announcement
> email "this 'legacy drivers' branch also contains old versions of the new
> drivers. If you ship both these and a modern version of Mesa, make sure
> not to build the same drivers from both trees".
>
> Packagers will then pick the right `-D{dri,gallium,vulkan}-drivers=` lists
> to avoid collisions on their distros.

Wouldn't this be much safer anyway with a small patch to remove those
"new" drivers from the meson options list?

> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?

[Eric Engestrom]

On 2020-03-29 at 20:58, Jason Ekstrand  wrote:
> On Sun, Mar 29, 2020 at 11:45 AM Kristian Høgsberg  
> wrote:
> >
> > As for loading, doesn't glvnd solve that?
> 
> Not really.  There are still problems if you have HW drivers from both
> repos on the same system and someone has to decide which one to use.
> We would either have to come up with a good solution to that problem
> or we would have to delete/disable all of the drivers still in master
> in the LTS branch.  In any case, there are real problems to solve
> there.

That's a simple packaging issue, and IMO it's ok to just say in the announcement
email "this 'legacy drivers' branch also contains old versions of the new
drivers. If you ship both these and a modern version of Mesa, make sure
not to build the same drivers from both trees".

Packagers will then pick the right `-D{dri,gallium,vulkan}-drivers=` lists
to avoid collisions on their distros.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?

[Jason Ekstrand]

On Sun, Mar 29, 2020 at 11:45 AM Kristian Høgsberg  wrote:
>
> As for loading, doesn't glvnd solve that?

Not really.  There are still problems if you have HW drivers from both
repos on the same system and someone has to decide which one to use.
We would either have to come up with a good solution to that problem
or we would have to delete/disable all of the drivers still in master
in the LTS branch.  In any case, there are real problems to solve
there.

--Jason


> On Sun, Mar 29, 2020, 1:19 AM Marek Olšák  wrote:
>>
>> If you want a complete fork or removal, that's fine with me. It's 
>> technically more challenging for driver loaders and packaging though.
>>
>> Marek
>>
>> On Sun., Mar. 29, 2020, 02:51 Jason Ekstrand,  wrote:
>>>
>>> On Sat, Mar 28, 2020 at 11:41 PM Marek Olšák  wrote:
>>> >
>>> > The #include spaghetti will be resolved before the split. I don't care 
>>> > about including gallium, but no code will include src/mesa outside of 
>>> > that.
>>>
>>> If we make sure that we modify the #include guards on every header in
>>> src/mesa_classic so that any accidental cross-includes lead to double
>>> definitions and therefore compile errors, that would probably help.
>>> It'd certainly give me a lot more confidence that we've done it right.
>>>
>>> > The biggest part is to make src/compiler completely independent and 
>>> > that's a worthy goal by itself.
>>>
>>> Yeah, I've wanted to see that happen since we started splitting stuff
>>> out to make Vulkan a possibility.
>>>
>>> > Milestones:
>>> > - make src/compiler a standalone lib
>>> > - don't include src/mesa in other places
>>> > - split classic drivers into src/mesa_classic
>>>
>>> If you're willing to do the work, I guess I'm not opposed for now.
>>>
>>> That said, I also have some somewhat selfish reasons for wanting to do
>>> a fork.  In particular, I'd like to freeze i965 and possibly Gen7
>>> Vulkan in time so that we can stop maintaining the i965 and the old
>>> vec4 back-end compiler.  Even though we're not adding features, I
>>> still find myself having to fix those up from time to time due to
>>> reworks elsewhere.  Maybe the answer is to copy and isolate them too
>>> but, at that point, why not just put them in a branch?
>>>
>>> --Jason
>>>
>>>
>>> > Marek
>>> >
>>> > On Sun., Mar. 29, 2020, 00:08 Jason Ekstrand,  
>>> > wrote:
>>> >>
>>> >> On Wed, Mar 25, 2020 at 6:32 PM Marek Olšák  wrote:
>>> >> >
>>> >> >
>>> >> >
>>> >> > On Thu, Dec 5, 2019 at 2:58 AM Kenneth Graunke  
>>> >> > wrote:
>>> >> >>
>>> >> >> On Tuesday, December 3, 2019 4:39:15 PM PST Marek Olšák wrote:
>>> >> >> > Hi,
>>> >> >> >
>>> >> >> > Here are 2 proposals to simplify and better optimize the GL->Gallium
>>> >> >> > translation.
>>> >> >> >
>>> >> >> > 1) Move classic drivers to a fork of Mesa, and remove them from 
>>> >> >> > master.
>>> >> >> > Classic drivers won't share any code with master. glvnd will load 
>>> >> >> > them, but
>>> >> >> > glvnd is not ready for this yet.
>>> >> >> >
>>> >> >> > 2) Keep classic drivers. Fork src/mesa for Gallium. I think only 
>>> >> >> > mesa/main,
>>> >> >> > mesa/vbo, mesa/program, and drivers/dri/common need to be forked and
>>> >> >> > mesa/state_tracker moved. src/gallium/state-trackers/gl/ can be the 
>>> >> >> > target
>>> >> >> > location.
>>> >> >> >
>>> >> >> > Option 2 is more acceptable to people who want to keep classic 
>>> >> >> > drivers in
>>> >> >> > the tree and it can be done right now.
>>> >> >> >
>>> >> >> > Opinions?
>>> >> >> >
>>> >> >> > Thanks,
>>> >> >> > Marek
>>> >> >>
>>> >> >> FWIW, I am not in favor of either plan for the time being.
>>> >> >>
>>> >> >> - I agree with Eric that we're finally starting to clean up and
>>> >> >>   de-duplicate things, and pay off technical debt we've put off for
>>> >> >>   a long time.  I think forking everything in-tree would just be a
>>> >> >>   giant mess.
>>> >> >>
>>> >> >> - I agree with Dave that this seems to be a giant hassle for our
>>> >> >>   downstreams with little benefit for them in the short term.
>>> >> >
>>> >> >
>>> >> > If classic drivers were moved to src/mesa_classic, nothing would 
>>> >> > change for downstream.
>>> >>
>>> >> I'm concerned that doing that is just asking for more maintenance
>>> >> problems than we have today.  One of the problems we currently have is
>>> >> that our #includes are still spaghetti.  We've got stuff in src/util
>>> >> which inclues stuff in gallium as well as stuff in mesa/main.  If we
>>> >> even have one cross-wired include, it could lead to bezar and nearly
>>> >> impossible to trace bugs due to ABI incompatibility between the two
>>> >> copies of src/mesa the moment we start changing structs or function
>>> >> prototypes.  The obvious answer to this is "we'll sort out the
>>> >> spaghetti mess".  However, that also means serious changes to
>>> >> src/compiler/glsl because it includes mtypes.h.  Do we clone that too?
>>> >>  I honestly think that this particular cure is likely far worse 

Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?

[Kristian Høgsberg]

As for loading, doesn't glvnd solve that?

On Sun, Mar 29, 2020, 1:19 AM Marek Olšák  wrote:

> If you want a complete fork or removal, that's fine with me. It's
> technically more challenging for driver loaders and packaging though.
>
> Marek
>
> On Sun., Mar. 29, 2020, 02:51 Jason Ekstrand, 
> wrote:
>
>> On Sat, Mar 28, 2020 at 11:41 PM Marek Olšák  wrote:
>> >
>> > The #include spaghetti will be resolved before the split. I don't care
>> about including gallium, but no code will include src/mesa outside of that.
>>
>> If we make sure that we modify the #include guards on every header in
>> src/mesa_classic so that any accidental cross-includes lead to double
>> definitions and therefore compile errors, that would probably help.
>> It'd certainly give me a lot more confidence that we've done it right.
>>
>> > The biggest part is to make src/compiler completely independent and
>> that's a worthy goal by itself.
>>
>> Yeah, I've wanted to see that happen since we started splitting stuff
>> out to make Vulkan a possibility.
>>
>> > Milestones:
>> > - make src/compiler a standalone lib
>> > - don't include src/mesa in other places
>> > - split classic drivers into src/mesa_classic
>>
>> If you're willing to do the work, I guess I'm not opposed for now.
>>
>> That said, I also have some somewhat selfish reasons for wanting to do
>> a fork.  In particular, I'd like to freeze i965 and possibly Gen7
>> Vulkan in time so that we can stop maintaining the i965 and the old
>> vec4 back-end compiler.  Even though we're not adding features, I
>> still find myself having to fix those up from time to time due to
>> reworks elsewhere.  Maybe the answer is to copy and isolate them too
>> but, at that point, why not just put them in a branch?
>>
>> --Jason
>>
>>
>> > Marek
>> >
>> > On Sun., Mar. 29, 2020, 00:08 Jason Ekstrand, 
>> wrote:
>> >>
>> >> On Wed, Mar 25, 2020 at 6:32 PM Marek Olšák  wrote:
>> >> >
>> >> >
>> >> >
>> >> > On Thu, Dec 5, 2019 at 2:58 AM Kenneth Graunke <
>> kenn...@whitecape.org> wrote:
>> >> >>
>> >> >> On Tuesday, December 3, 2019 4:39:15 PM PST Marek Olšák wrote:
>> >> >> > Hi,
>> >> >> >
>> >> >> > Here are 2 proposals to simplify and better optimize the
>> GL->Gallium
>> >> >> > translation.
>> >> >> >
>> >> >> > 1) Move classic drivers to a fork of Mesa, and remove them from
>> master.
>> >> >> > Classic drivers won't share any code with master. glvnd will load
>> them, but
>> >> >> > glvnd is not ready for this yet.
>> >> >> >
>> >> >> > 2) Keep classic drivers. Fork src/mesa for Gallium. I think only
>> mesa/main,
>> >> >> > mesa/vbo, mesa/program, and drivers/dri/common need to be forked
>> and
>> >> >> > mesa/state_tracker moved. src/gallium/state-trackers/gl/ can be
>> the target
>> >> >> > location.
>> >> >> >
>> >> >> > Option 2 is more acceptable to people who want to keep classic
>> drivers in
>> >> >> > the tree and it can be done right now.
>> >> >> >
>> >> >> > Opinions?
>> >> >> >
>> >> >> > Thanks,
>> >> >> > Marek
>> >> >>
>> >> >> FWIW, I am not in favor of either plan for the time being.
>> >> >>
>> >> >> - I agree with Eric that we're finally starting to clean up and
>> >> >>   de-duplicate things, and pay off technical debt we've put off for
>> >> >>   a long time.  I think forking everything in-tree would just be a
>> >> >>   giant mess.
>> >> >>
>> >> >> - I agree with Dave that this seems to be a giant hassle for our
>> >> >>   downstreams with little benefit for them in the short term.
>> >> >
>> >> >
>> >> > If classic drivers were moved to src/mesa_classic, nothing would
>> change for downstream.
>> >>
>> >> I'm concerned that doing that is just asking for more maintenance
>> >> problems than we have today.  One of the problems we currently have is
>> >> that our #includes are still spaghetti.  We've got stuff in src/util
>> >> which inclues stuff in gallium as well as stuff in mesa/main.  If we
>> >> even have one cross-wired include, it could lead to bezar and nearly
>> >> impossible to trace bugs due to ABI incompatibility between the two
>> >> copies of src/mesa the moment we start changing structs or function
>> >> prototypes.  The obvious answer to this is "we'll sort out the
>> >> spaghetti mess".  However, that also means serious changes to
>> >> src/compiler/glsl because it includes mtypes.h.  Do we clone that too?
>> >>  I honestly think that this particular cure is likely far worse than
>> >> the disease of having to do careful testing of src/mesa changes.
>> >>
>> >> IMO, a far better plan would be to give it one more year so that
>> >> distros and users get experience with iris and then fork off an LTS
>> >> branch and delete all the legacy stuff from master.  We can continue
>> >> to do maintenance in the LTS branch as needed but I honestly don't
>> >> expect much work to happen there.  The most difficult thing will be
>> >> deciding what to remove from master but I don't want to make that
>> >> decision today.  However, doing a clean fork means we 

Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?

[Marek Olšák]

If you want a complete fork or removal, that's fine with me. It's
technically more challenging for driver loaders and packaging though.

Marek

On Sun., Mar. 29, 2020, 02:51 Jason Ekstrand,  wrote:

> On Sat, Mar 28, 2020 at 11:41 PM Marek Olšák  wrote:
> >
> > The #include spaghetti will be resolved before the split. I don't care
> about including gallium, but no code will include src/mesa outside of that.
>
> If we make sure that we modify the #include guards on every header in
> src/mesa_classic so that any accidental cross-includes lead to double
> definitions and therefore compile errors, that would probably help.
> It'd certainly give me a lot more confidence that we've done it right.
>
> > The biggest part is to make src/compiler completely independent and
> that's a worthy goal by itself.
>
> Yeah, I've wanted to see that happen since we started splitting stuff
> out to make Vulkan a possibility.
>
> > Milestones:
> > - make src/compiler a standalone lib
> > - don't include src/mesa in other places
> > - split classic drivers into src/mesa_classic
>
> If you're willing to do the work, I guess I'm not opposed for now.
>
> That said, I also have some somewhat selfish reasons for wanting to do
> a fork.  In particular, I'd like to freeze i965 and possibly Gen7
> Vulkan in time so that we can stop maintaining the i965 and the old
> vec4 back-end compiler.  Even though we're not adding features, I
> still find myself having to fix those up from time to time due to
> reworks elsewhere.  Maybe the answer is to copy and isolate them too
> but, at that point, why not just put them in a branch?
>
> --Jason
>
>
> > Marek
> >
> > On Sun., Mar. 29, 2020, 00:08 Jason Ekstrand, 
> wrote:
> >>
> >> On Wed, Mar 25, 2020 at 6:32 PM Marek Olšák  wrote:
> >> >
> >> >
> >> >
> >> > On Thu, Dec 5, 2019 at 2:58 AM Kenneth Graunke 
> wrote:
> >> >>
> >> >> On Tuesday, December 3, 2019 4:39:15 PM PST Marek Olšák wrote:
> >> >> > Hi,
> >> >> >
> >> >> > Here are 2 proposals to simplify and better optimize the
> GL->Gallium
> >> >> > translation.
> >> >> >
> >> >> > 1) Move classic drivers to a fork of Mesa, and remove them from
> master.
> >> >> > Classic drivers won't share any code with master. glvnd will load
> them, but
> >> >> > glvnd is not ready for this yet.
> >> >> >
> >> >> > 2) Keep classic drivers. Fork src/mesa for Gallium. I think only
> mesa/main,
> >> >> > mesa/vbo, mesa/program, and drivers/dri/common need to be forked
> and
> >> >> > mesa/state_tracker moved. src/gallium/state-trackers/gl/ can be
> the target
> >> >> > location.
> >> >> >
> >> >> > Option 2 is more acceptable to people who want to keep classic
> drivers in
> >> >> > the tree and it can be done right now.
> >> >> >
> >> >> > Opinions?
> >> >> >
> >> >> > Thanks,
> >> >> > Marek
> >> >>
> >> >> FWIW, I am not in favor of either plan for the time being.
> >> >>
> >> >> - I agree with Eric that we're finally starting to clean up and
> >> >>   de-duplicate things, and pay off technical debt we've put off for
> >> >>   a long time.  I think forking everything in-tree would just be a
> >> >>   giant mess.
> >> >>
> >> >> - I agree with Dave that this seems to be a giant hassle for our
> >> >>   downstreams with little benefit for them in the short term.
> >> >
> >> >
> >> > If classic drivers were moved to src/mesa_classic, nothing would
> change for downstream.
> >>
> >> I'm concerned that doing that is just asking for more maintenance
> >> problems than we have today.  One of the problems we currently have is
> >> that our #includes are still spaghetti.  We've got stuff in src/util
> >> which inclues stuff in gallium as well as stuff in mesa/main.  If we
> >> even have one cross-wired include, it could lead to bezar and nearly
> >> impossible to trace bugs due to ABI incompatibility between the two
> >> copies of src/mesa the moment we start changing structs or function
> >> prototypes.  The obvious answer to this is "we'll sort out the
> >> spaghetti mess".  However, that also means serious changes to
> >> src/compiler/glsl because it includes mtypes.h.  Do we clone that too?
> >>  I honestly think that this particular cure is likely far worse than
> >> the disease of having to do careful testing of src/mesa changes.
> >>
> >> IMO, a far better plan would be to give it one more year so that
> >> distros and users get experience with iris and then fork off an LTS
> >> branch and delete all the legacy stuff from master.  We can continue
> >> to do maintenance in the LTS branch as needed but I honestly don't
> >> expect much work to happen there.  The most difficult thing will be
> >> deciding what to remove from master but I don't want to make that
> >> decision today.  However, doing a clean fork means we don't have to
> >> worry about cross-contamination in shared code causing weird issues
> >> because they're in separate branches.  We will have to figure out a
> >> few loader issues to ensure that the master drivers get preferred over
> >> 

Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?

[Jason Ekstrand]

On Sat, Mar 28, 2020 at 11:41 PM Marek Olšák  wrote:
>
> The #include spaghetti will be resolved before the split. I don't care about 
> including gallium, but no code will include src/mesa outside of that.

If we make sure that we modify the #include guards on every header in
src/mesa_classic so that any accidental cross-includes lead to double
definitions and therefore compile errors, that would probably help.
It'd certainly give me a lot more confidence that we've done it right.

> The biggest part is to make src/compiler completely independent and that's a 
> worthy goal by itself.

Yeah, I've wanted to see that happen since we started splitting stuff
out to make Vulkan a possibility.

> Milestones:
> - make src/compiler a standalone lib
> - don't include src/mesa in other places
> - split classic drivers into src/mesa_classic

If you're willing to do the work, I guess I'm not opposed for now.

That said, I also have some somewhat selfish reasons for wanting to do
a fork.  In particular, I'd like to freeze i965 and possibly Gen7
Vulkan in time so that we can stop maintaining the i965 and the old
vec4 back-end compiler.  Even though we're not adding features, I
still find myself having to fix those up from time to time due to
reworks elsewhere.  Maybe the answer is to copy and isolate them too
but, at that point, why not just put them in a branch?

--Jason


> Marek
>
> On Sun., Mar. 29, 2020, 00:08 Jason Ekstrand,  wrote:
>>
>> On Wed, Mar 25, 2020 at 6:32 PM Marek Olšák  wrote:
>> >
>> >
>> >
>> > On Thu, Dec 5, 2019 at 2:58 AM Kenneth Graunke  
>> > wrote:
>> >>
>> >> On Tuesday, December 3, 2019 4:39:15 PM PST Marek Olšák wrote:
>> >> > Hi,
>> >> >
>> >> > Here are 2 proposals to simplify and better optimize the GL->Gallium
>> >> > translation.
>> >> >
>> >> > 1) Move classic drivers to a fork of Mesa, and remove them from master.
>> >> > Classic drivers won't share any code with master. glvnd will load them, 
>> >> > but
>> >> > glvnd is not ready for this yet.
>> >> >
>> >> > 2) Keep classic drivers. Fork src/mesa for Gallium. I think only 
>> >> > mesa/main,
>> >> > mesa/vbo, mesa/program, and drivers/dri/common need to be forked and
>> >> > mesa/state_tracker moved. src/gallium/state-trackers/gl/ can be the 
>> >> > target
>> >> > location.
>> >> >
>> >> > Option 2 is more acceptable to people who want to keep classic drivers 
>> >> > in
>> >> > the tree and it can be done right now.
>> >> >
>> >> > Opinions?
>> >> >
>> >> > Thanks,
>> >> > Marek
>> >>
>> >> FWIW, I am not in favor of either plan for the time being.
>> >>
>> >> - I agree with Eric that we're finally starting to clean up and
>> >>   de-duplicate things, and pay off technical debt we've put off for
>> >>   a long time.  I think forking everything in-tree would just be a
>> >>   giant mess.
>> >>
>> >> - I agree with Dave that this seems to be a giant hassle for our
>> >>   downstreams with little benefit for them in the short term.
>> >
>> >
>> > If classic drivers were moved to src/mesa_classic, nothing would change 
>> > for downstream.
>>
>> I'm concerned that doing that is just asking for more maintenance
>> problems than we have today.  One of the problems we currently have is
>> that our #includes are still spaghetti.  We've got stuff in src/util
>> which inclues stuff in gallium as well as stuff in mesa/main.  If we
>> even have one cross-wired include, it could lead to bezar and nearly
>> impossible to trace bugs due to ABI incompatibility between the two
>> copies of src/mesa the moment we start changing structs or function
>> prototypes.  The obvious answer to this is "we'll sort out the
>> spaghetti mess".  However, that also means serious changes to
>> src/compiler/glsl because it includes mtypes.h.  Do we clone that too?
>>  I honestly think that this particular cure is likely far worse than
>> the disease of having to do careful testing of src/mesa changes.
>>
>> IMO, a far better plan would be to give it one more year so that
>> distros and users get experience with iris and then fork off an LTS
>> branch and delete all the legacy stuff from master.  We can continue
>> to do maintenance in the LTS branch as needed but I honestly don't
>> expect much work to happen there.  The most difficult thing will be
>> deciding what to remove from master but I don't want to make that
>> decision today.  However, doing a clean fork means we don't have to
>> worry about cross-contamination in shared code causing weird issues
>> because they're in separate branches.  We will have to figure out a
>> few loader issues to ensure that the master drivers get preferred over
>> the LTS ones or somehow disable all master drivers in the LTS branch.
>>
>> --Jason
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?

[Marek Olšák]

The #include spaghetti will be resolved before the split. I don't care
about including gallium, but no code will include src/mesa outside of that.
The biggest part is to make src/compiler completely independent and that's
a worthy goal by itself.

Milestones:
- make src/compiler a standalone lib
- don't include src/mesa in other places
- split classic drivers into src/mesa_classic

Marek

On Sun., Mar. 29, 2020, 00:08 Jason Ekstrand,  wrote:

> On Wed, Mar 25, 2020 at 6:32 PM Marek Olšák  wrote:
> >
> >
> >
> > On Thu, Dec 5, 2019 at 2:58 AM Kenneth Graunke 
> wrote:
> >>
> >> On Tuesday, December 3, 2019 4:39:15 PM PST Marek Olšák wrote:
> >> > Hi,
> >> >
> >> > Here are 2 proposals to simplify and better optimize the GL->Gallium
> >> > translation.
> >> >
> >> > 1) Move classic drivers to a fork of Mesa, and remove them from
> master.
> >> > Classic drivers won't share any code with master. glvnd will load
> them, but
> >> > glvnd is not ready for this yet.
> >> >
> >> > 2) Keep classic drivers. Fork src/mesa for Gallium. I think only
> mesa/main,
> >> > mesa/vbo, mesa/program, and drivers/dri/common need to be forked and
> >> > mesa/state_tracker moved. src/gallium/state-trackers/gl/ can be the
> target
> >> > location.
> >> >
> >> > Option 2 is more acceptable to people who want to keep classic
> drivers in
> >> > the tree and it can be done right now.
> >> >
> >> > Opinions?
> >> >
> >> > Thanks,
> >> > Marek
> >>
> >> FWIW, I am not in favor of either plan for the time being.
> >>
> >> - I agree with Eric that we're finally starting to clean up and
> >>   de-duplicate things, and pay off technical debt we've put off for
> >>   a long time.  I think forking everything in-tree would just be a
> >>   giant mess.
> >>
> >> - I agree with Dave that this seems to be a giant hassle for our
> >>   downstreams with little benefit for them in the short term.
> >
> >
> > If classic drivers were moved to src/mesa_classic, nothing would change
> for downstream.
>
> I'm concerned that doing that is just asking for more maintenance
> problems than we have today.  One of the problems we currently have is
> that our #includes are still spaghetti.  We've got stuff in src/util
> which inclues stuff in gallium as well as stuff in mesa/main.  If we
> even have one cross-wired include, it could lead to bezar and nearly
> impossible to trace bugs due to ABI incompatibility between the two
> copies of src/mesa the moment we start changing structs or function
> prototypes.  The obvious answer to this is "we'll sort out the
> spaghetti mess".  However, that also means serious changes to
> src/compiler/glsl because it includes mtypes.h.  Do we clone that too?
>  I honestly think that this particular cure is likely far worse than
> the disease of having to do careful testing of src/mesa changes.
>
> IMO, a far better plan would be to give it one more year so that
> distros and users get experience with iris and then fork off an LTS
> branch and delete all the legacy stuff from master.  We can continue
> to do maintenance in the LTS branch as needed but I honestly don't
> expect much work to happen there.  The most difficult thing will be
> deciding what to remove from master but I don't want to make that
> decision today.  However, doing a clean fork means we don't have to
> worry about cross-contamination in shared code causing weird issues
> because they're in separate branches.  We will have to figure out a
> few loader issues to ensure that the master drivers get preferred over
> the LTS ones or somehow disable all master drivers in the LTS branch.
>
> --Jason
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?

[Jason Ekstrand]

On Wed, Mar 25, 2020 at 6:32 PM Marek Olšák  wrote:
>
>
>
> On Thu, Dec 5, 2019 at 2:58 AM Kenneth Graunke  wrote:
>>
>> On Tuesday, December 3, 2019 4:39:15 PM PST Marek Olšák wrote:
>> > Hi,
>> >
>> > Here are 2 proposals to simplify and better optimize the GL->Gallium
>> > translation.
>> >
>> > 1) Move classic drivers to a fork of Mesa, and remove them from master.
>> > Classic drivers won't share any code with master. glvnd will load them, but
>> > glvnd is not ready for this yet.
>> >
>> > 2) Keep classic drivers. Fork src/mesa for Gallium. I think only mesa/main,
>> > mesa/vbo, mesa/program, and drivers/dri/common need to be forked and
>> > mesa/state_tracker moved. src/gallium/state-trackers/gl/ can be the target
>> > location.
>> >
>> > Option 2 is more acceptable to people who want to keep classic drivers in
>> > the tree and it can be done right now.
>> >
>> > Opinions?
>> >
>> > Thanks,
>> > Marek
>>
>> FWIW, I am not in favor of either plan for the time being.
>>
>> - I agree with Eric that we're finally starting to clean up and
>>   de-duplicate things, and pay off technical debt we've put off for
>>   a long time.  I think forking everything in-tree would just be a
>>   giant mess.
>>
>> - I agree with Dave that this seems to be a giant hassle for our
>>   downstreams with little benefit for them in the short term.
>
>
> If classic drivers were moved to src/mesa_classic, nothing would change for 
> downstream.

I'm concerned that doing that is just asking for more maintenance
problems than we have today.  One of the problems we currently have is
that our #includes are still spaghetti.  We've got stuff in src/util
which inclues stuff in gallium as well as stuff in mesa/main.  If we
even have one cross-wired include, it could lead to bezar and nearly
impossible to trace bugs due to ABI incompatibility between the two
copies of src/mesa the moment we start changing structs or function
prototypes.  The obvious answer to this is "we'll sort out the
spaghetti mess".  However, that also means serious changes to
src/compiler/glsl because it includes mtypes.h.  Do we clone that too?
 I honestly think that this particular cure is likely far worse than
the disease of having to do careful testing of src/mesa changes.

IMO, a far better plan would be to give it one more year so that
distros and users get experience with iris and then fork off an LTS
branch and delete all the legacy stuff from master.  We can continue
to do maintenance in the LTS branch as needed but I honestly don't
expect much work to happen there.  The most difficult thing will be
deciding what to remove from master but I don't want to make that
decision today.  However, doing a clean fork means we don't have to
worry about cross-contamination in shared code causing weird issues
because they're in separate branches.  We will have to figure out a
few loader issues to ensure that the master drivers get preferred over
the LTS ones or somehow disable all master drivers in the LTS branch.

--Jason
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?

[Marek Olšák]

On Thu, Dec 5, 2019 at 2:58 AM Kenneth Graunke 
wrote:

> On Tuesday, December 3, 2019 4:39:15 PM PST Marek Olšák wrote:
> > Hi,
> >
> > Here are 2 proposals to simplify and better optimize the GL->Gallium
> > translation.
> >
> > 1) Move classic drivers to a fork of Mesa, and remove them from master.
> > Classic drivers won't share any code with master. glvnd will load them,
> but
> > glvnd is not ready for this yet.
> >
> > 2) Keep classic drivers. Fork src/mesa for Gallium. I think only
> mesa/main,
> > mesa/vbo, mesa/program, and drivers/dri/common need to be forked and
> > mesa/state_tracker moved. src/gallium/state-trackers/gl/ can be the
> target
> > location.
> >
> > Option 2 is more acceptable to people who want to keep classic drivers in
> > the tree and it can be done right now.
> >
> > Opinions?
> >
> > Thanks,
> > Marek
>
> FWIW, I am not in favor of either plan for the time being.
>
> - I agree with Eric that we're finally starting to clean up and
>   de-duplicate things, and pay off technical debt we've put off for
>   a long time.  I think forking everything in-tree would just be a
>   giant mess.
>
> - I agree with Dave that this seems to be a giant hassle for our
>   downstreams with little benefit for them in the short term.
>

If classic drivers were moved to src/mesa_classic, nothing would change for
downstream.


>
> - Shuffling r100/r200/i915/nouveau_vieux off to a legacy fork seems
>   like a fine plan.  They're ancient hardware that can't (or barely
>   can) do GL 2.x.  Nothing much has happened with them in years,
>   and I'm not sure all of them even really have maintainers.
>
>   The main blocker here I think would be ironing out all the glvnd
>   issues and making sure that is working solidly for everyone.
>   (FWIW, glvnd is not even enabled by default in our build system!)
>
> - Shuffling i965 off to legacy is really premature I think.  Iris
>   isn't even shipping in distros yet (hopefully soon!), and even
>   then, we have a _ton_ of Haswell users.  Check the Phoronix
>   comments if you want to see how pissed off people are about even
>   bringing up this topic.  (Or better yet, don't...basic human
>   decency toward others seems to be lacking.  Hooray, internet...)
>
> - Writing a Gallium driver for Intel Gen4-7.5 would be interesting.
>
>   I've been thinking about this some, and it might be possible to
>   retain some of the niceties of the iris memory model even on older
>   hardware, by relying on a modern kernel and possibly making some
>   (hopefully minor) improvements.  Even if we didn't, going back to
>   the i965 model wouldn't be the worst thing.  The new driver would
>   almost certainly be faster than i965, if not as good as iris.
>
>   ajax and I were planning to call it crocus, if I wrote one.  I don't
>   think it would take nearly as long.  But it's still a bunch of time
>   that I don't think I can justify spending.  The new hardware can do
>   so much more, and is so much faster, and much lower power.  I think
>   it would be better for me to spend my time on Gen11+.
>

There is also "ilo", which supports gen6-7, but not GL 4.x and NIR, and
probably isn't as fast as i965 (that might be fixable with NIR):
https://cgit.freedesktop.org/mesa/mesa/commit/?id=38794259175852084532499a09dec85b6c6a4321


>
> - Vulkan has really taken off, and OpenGL feels increasingly like a
>   dead end.  DXVK has brought more games than we had with native ports.
>   Feral is even reworking some native OpenGL ports to use Vulkan.  New
>   graphics features are happening in the Vulkan space.
>

There are markets like workstation where OpenGL is the main API. OpenGL is
also still relevant in some other markets. New games have transitioned to
Vulkan but not good old games.

I don't think Zink can outperform an optimized Gallium driver across all
legacy features, so it will only be useful in a small subset of use cases.

Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?

[Rob Clark]

On Wed, Dec 4, 2019 at 11:58 PM Kenneth Graunke  wrote:
>
> On Tuesday, December 3, 2019 4:39:15 PM PST Marek Olšák wrote:
> > Hi,
> >
> > Here are 2 proposals to simplify and better optimize the GL->Gallium
> > translation.
> >
> > 1) Move classic drivers to a fork of Mesa, and remove them from master.
> > Classic drivers won't share any code with master. glvnd will load them, but
> > glvnd is not ready for this yet.
> >
> > 2) Keep classic drivers. Fork src/mesa for Gallium. I think only mesa/main,
> > mesa/vbo, mesa/program, and drivers/dri/common need to be forked and
> > mesa/state_tracker moved. src/gallium/state-trackers/gl/ can be the target
> > location.
> >
> > Option 2 is more acceptable to people who want to keep classic drivers in
> > the tree and it can be done right now.
> >
> > Opinions?
> >
> > Thanks,
> > Marek
>
> FWIW, I am not in favor of either plan for the time being.
>
> - I agree with Eric that we're finally starting to clean up and
>   de-duplicate things, and pay off technical debt we've put off for
>   a long time.  I think forking everything in-tree would just be a
>   giant mess.
>
> - I agree with Dave that this seems to be a giant hassle for our
>   downstreams with little benefit for them in the short term.
>
> - Shuffling r100/r200/i915/nouveau_vieux off to a legacy fork seems
>   like a fine plan.  They're ancient hardware that can't (or barely
>   can) do GL 2.x.  Nothing much has happened with them in years,
>   and I'm not sure all of them even really have maintainers.
>
>   The main blocker here I think would be ironing out all the glvnd
>   issues and making sure that is working solidly for everyone.
>   (FWIW, glvnd is not even enabled by default in our build system!)
>
> - Shuffling i965 off to legacy is really premature I think.  Iris
>   isn't even shipping in distros yet (hopefully soon!), and even
>   then, we have a _ton_ of Haswell users.  Check the Phoronix
>   comments if you want to see how pissed off people are about even
>   bringing up this topic.  (Or better yet, don't...basic human
>   decency toward others seems to be lacking.  Hooray, internet...)
>
> - Writing a Gallium driver for Intel Gen4-7.5 would be interesting.
>
>   I've been thinking about this some, and it might be possible to
>   retain some of the niceties of the iris memory model even on older
>   hardware, by relying on a modern kernel and possibly making some
>   (hopefully minor) improvements.  Even if we didn't, going back to
>   the i965 model wouldn't be the worst thing.  The new driver would
>   almost certainly be faster than i965, if not as good as iris.
>
>   ajax and I were planning to call it crocus, if I wrote one.  I don't
>   think it would take nearly as long.  But it's still a bunch of time
>   that I don't think I can justify spending.  The new hardware can do
>   so much more, and is so much faster, and much lower power.  I think
>   it would be better for me to spend my time on Gen11+.
>
> - Vulkan has really taken off, and OpenGL feels increasingly like a
>   dead end.  DXVK has brought more games than we had with native ports.
>   Feral is even reworking some native OpenGL ports to use Vulkan.  New
>   graphics features are happening in the Vulkan space.
>
>   So, I kind of wonder whether it's worth our time to go through and
>   massively clean up and rearchitecture the OpenGL drivers at this
>   point.  By the time we're finished, will anyone care?

maybe years in the future, when zink is the only remaining gallium
driver, we have v2 of this discussion (ie. forking the other gallium
drivers into an LTS branch) :-P

BR,
-R

>
> - Are there concrete things that are prohibitively expensive with
>   classic around?  Otherwise, Eric's suggestion of "so go do that!"
>   sounds like a good idea.  We've started finally merging a bunch
>   of code and I think this is a positive direction.
>
> I'd say let's shelve this for now and think about it again later.
> I suspect in a year or so the calculus will look fairly different.
>
> --Ken
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?

[apinheiro]

On 5/12/19 8:48, Kenneth Graunke wrote:

On Tuesday, December 3, 2019 4:39:15 PM PST Marek Olšák wrote:

Hi,

Here are 2 proposals to simplify and better optimize the GL->Gallium
translation.

1) Move classic drivers to a fork of Mesa, and remove them from master.
Classic drivers won't share any code with master. glvnd will load them, but
glvnd is not ready for this yet.

2) Keep classic drivers. Fork src/mesa for Gallium. I think only mesa/main,
mesa/vbo, mesa/program, and drivers/dri/common need to be forked and
mesa/state_tracker moved. src/gallium/state-trackers/gl/ can be the target
location.

Option 2 is more acceptable to people who want to keep classic drivers in
the tree and it can be done right now.

Opinions?

Thanks,
Marek

FWIW, I am not in favor of either plan for the time being.

- I agree with Eric that we're finally starting to clean up and
   de-duplicate things, and pay off technical debt we've put off for
   a long time.  I think forking everything in-tree would just be a
   giant mess.

- I agree with Dave that this seems to be a giant hassle for our
   downstreams with little benefit for them in the short term.

- Shuffling r100/r200/i915/nouveau_vieux off to a legacy fork seems
   like a fine plan.  They're ancient hardware that can't (or barely
   can) do GL 2.x.  Nothing much has happened with them in years,
   and I'm not sure all of them even really have maintainers.

   The main blocker here I think would be ironing out all the glvnd
   issues and making sure that is working solidly for everyone.
   (FWIW, glvnd is not even enabled by default in our build system!)

- Shuffling i965 off to legacy is really premature I think.  Iris
   isn't even shipping in distros yet (hopefully soon!), and even
   then, we have a _ton_ of Haswell users.  Check the Phoronix
   comments if you want to see how pissed off people are about even
   bringing up this topic.  (Or better yet, don't...basic human
   decency toward others seems to be lacking.  Hooray, internet...)

- Writing a Gallium driver for Intel Gen4-7.5 would be interesting.

   I've been thinking about this some, and it might be possible to
   retain some of the niceties of the iris memory model even on older
   hardware, by relying on a modern kernel and possibly making some
   (hopefully minor) improvements.  Even if we didn't, going back to
   the i965 model wouldn't be the worst thing.  The new driver would
   almost certainly be faster than i965, if not as good as iris.

   ajax and I were planning to call it crocus, if I wrote one.  I don't
   think it would take nearly as long.  But it's still a bunch of time
   that I don't think I can justify spending.  The new hardware can do
   so much more, and is so much faster, and much lower power.  I think
   it would be better for me to spend my time on Gen11+.

- Vulkan has really taken off, and OpenGL feels increasingly like a
   dead end.  DXVK has brought more games than we had with native ports.
   Feral is even reworking some native OpenGL ports to use Vulkan.  New
   graphics features are happening in the Vulkan space.

   So, I kind of wonder whether it's worth our time to go through and
   massively clean up and rearchitecture the OpenGL drivers at this
   point.  By the time we're finished, will anyone care?

- Are there concrete things that are prohibitively expensive with
   classic around?  Otherwise, Eric's suggestion of "so go do that!"
   sounds like a good idea.  We've started finally merging a bunch
   of code and I think this is a positive direction.

I'd say let's shelve this for now and think about it again later.
I suspect in a year or so the calculus will look fairly different.



Although I think that it is somewhat early to think that OpenGL is 
nearly a dead end, FWIW, I agree in general with Kenneth analysis and 
suggestions here.


BR

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?

[Kenneth Graunke]

On Tuesday, December 3, 2019 4:39:15 PM PST Marek Olšák wrote:
> Hi,
> 
> Here are 2 proposals to simplify and better optimize the GL->Gallium
> translation.
> 
> 1) Move classic drivers to a fork of Mesa, and remove them from master.
> Classic drivers won't share any code with master. glvnd will load them, but
> glvnd is not ready for this yet.
> 
> 2) Keep classic drivers. Fork src/mesa for Gallium. I think only mesa/main,
> mesa/vbo, mesa/program, and drivers/dri/common need to be forked and
> mesa/state_tracker moved. src/gallium/state-trackers/gl/ can be the target
> location.
> 
> Option 2 is more acceptable to people who want to keep classic drivers in
> the tree and it can be done right now.
> 
> Opinions?
> 
> Thanks,
> Marek

FWIW, I am not in favor of either plan for the time being.

- I agree with Eric that we're finally starting to clean up and
  de-duplicate things, and pay off technical debt we've put off for
  a long time.  I think forking everything in-tree would just be a
  giant mess.

- I agree with Dave that this seems to be a giant hassle for our
  downstreams with little benefit for them in the short term.

- Shuffling r100/r200/i915/nouveau_vieux off to a legacy fork seems
  like a fine plan.  They're ancient hardware that can't (or barely
  can) do GL 2.x.  Nothing much has happened with them in years,
  and I'm not sure all of them even really have maintainers.

  The main blocker here I think would be ironing out all the glvnd
  issues and making sure that is working solidly for everyone.
  (FWIW, glvnd is not even enabled by default in our build system!)

- Shuffling i965 off to legacy is really premature I think.  Iris
  isn't even shipping in distros yet (hopefully soon!), and even
  then, we have a _ton_ of Haswell users.  Check the Phoronix
  comments if you want to see how pissed off people are about even
  bringing up this topic.  (Or better yet, don't...basic human
  decency toward others seems to be lacking.  Hooray, internet...)

- Writing a Gallium driver for Intel Gen4-7.5 would be interesting.

  I've been thinking about this some, and it might be possible to
  retain some of the niceties of the iris memory model even on older
  hardware, by relying on a modern kernel and possibly making some
  (hopefully minor) improvements.  Even if we didn't, going back to
  the i965 model wouldn't be the worst thing.  The new driver would
  almost certainly be faster than i965, if not as good as iris.

  ajax and I were planning to call it crocus, if I wrote one.  I don't
  think it would take nearly as long.  But it's still a bunch of time
  that I don't think I can justify spending.  The new hardware can do
  so much more, and is so much faster, and much lower power.  I think
  it would be better for me to spend my time on Gen11+.

- Vulkan has really taken off, and OpenGL feels increasingly like a
  dead end.  DXVK has brought more games than we had with native ports.
  Feral is even reworking some native OpenGL ports to use Vulkan.  New
  graphics features are happening in the Vulkan space.

  So, I kind of wonder whether it's worth our time to go through and
  massively clean up and rearchitecture the OpenGL drivers at this
  point.  By the time we're finished, will anyone care?

- Are there concrete things that are prohibitively expensive with
  classic around?  Otherwise, Eric's suggestion of "so go do that!"
  sounds like a good idea.  We've started finally merging a bunch
  of code and I think this is a positive direction.

I'd say let's shelve this for now and think about it again later.
I suspect in a year or so the calculus will look fairly different.

--Ken


signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?

[Ian Romanick]

On 12/3/19 10:48 PM, Marek Olšák wrote:
> On Wed., Dec. 4, 2019, 01:20 Tapani Pälli,  > wrote:
> 
> Hi;
> 
> On 12/4/19 2:39 AM, Marek Olšák wrote:
> > Hi,
> >
> > Here are 2 proposals to simplify and better optimize the GL->Gallium
> > translation.
> >
> > 1) Move classic drivers to a fork of Mesa, and remove them from
> master.
> > Classic drivers won't share any code with master. glvnd will load
> them,
> > but glvnd is not ready for this yet.
> >
> > 2) Keep classic drivers. Fork src/mesa for Gallium. I think only
> > mesa/main, mesa/vbo, mesa/program, and drivers/dri/common need to be
> > forked and mesa/state_tracker moved.
> src/gallium/state-trackers/gl/ can
> > be the target location.
> >
> > Option 2 is more acceptable to people who want to keep classic
> drivers
> > in the tree and it can be done right now.
> >
> > Opinions?
> >
> 
> I'm still quite newbie with gallium side of things and I'd like to know
> more about the possible simplifications and optimizations that could be
> done if this happened. Is this more about 'cleaning up the tree' or are
> there also some performance opportunities we are missing right now with
> current state?
> 
> 
> It's possible to reduce CPU overhead even more by moving state
> translation from st_validate_state to GL functions. This is possible
> already, but at the cost of effectively adding dead code to classic
> drivers. In theory we could do slightly better without classic drivers,
> but we don't know for sure.

If someone wants to start on this, I would be more than happy to help
with the work on the old, poorly maintained drivers.  I have almost all
of the necessary hardware installed in (mostly) functioning systems.
The "big CPU system" I have in my house has a PCI Radeon 9000 installed,
and I use it fairly regularly.

> If we had nir_to_tgsi, we could remove TGSI support from st/mesa. Option
> 1 would leave st/mesa as the only consumer of Mesa IR and GLSL IR, so
> both IRs could be eliminated in favor of NIR more easily. Although I
> guess a simpler option is not to touch anything.
> 
> Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?

[Eric Engestrom]

On 2019-12-04 at 18:54, Dylan Baker  wrote:
> Quoting Kristian Høgsberg (2019-12-04 10:43:46)
> > On Wed, Dec 4, 2019 at 10:31 AM Rob Clark  wrote:
> > >
> > > On Wed, Dec 4, 2019 at 9:48 AM Eric Anholt  wrote:
> > > >
> > > > On Tue, Dec 3, 2019 at 4:39 PM Marek Olšák  wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > Here are 2 proposals to simplify and better optimize the GL->Gallium 
> > > > > translation.
> > > > >
> > > > > 1) Move classic drivers to a fork of Mesa, and remove them from 
> > > > > master. Classic drivers won't share any code with master. glvnd will 
> > > > > load them, but glvnd is not ready for this yet.
> > > > >
> > > > > 2) Keep classic drivers. Fork src/mesa for Gallium. I think only 
> > > > > mesa/main, mesa/vbo, mesa/program, and drivers/dri/common need to be 
> > > > > forked and mesa/state_tracker moved. src/gallium/state-trackers/gl/ 
> > > > > can be the target location.
> > > > >
> > > > > Option 2 is more acceptable to people who want to keep classic 
> > > > > drivers in the tree and it can be done right now.
> > > >
> > > > (resending reply-all)
> > > >
> > > > I object to both of these. They increase work for Mesa folks like me
> > > > who do tree-wide work.
> > > >
> > > > I feel like we're finally (formats, util/ helpers, etc.) paying down
> > > > the technical debt that we built with gallium copying so much of
> > > > src/mesa/main, and saying "let's go duplicate more code so we can do
> > > > some unspecified optimization work" gets me really upset.
> > >
> > > tbf option #1 would be a copy of the code.. but a copy that we'd
> > > (hopefully) ignore from the perspective of tree-wide cleanup/refactor.
> > > If we started refactoring the legacy fork, that would strongly defeat
> > > the purpose of having it!
> > >
> > > Given that we don't have most of the classic drivers (other than i965)
> > > in CI, and presumably not many folks who are tracking master test the
> > > old classic drivers, moving them off to a fork seems to me to
> > > significantly reduce the risk of refactorings (whether it be for perf
> > > or for cleanup).
> > 
> > Another option would be to do a LTS-kind of release of mesa and then
> > drop the non-gallium drivers. It could even be limited in scope to the
> > non-gallium drivers, in the sense that we'd only do releases for fixes
> > to those drivers. It's basically option 1), but saying that we still
> > care about maintaining the drivers, but they wont receive new
> > features. With i965 being at GL 4.6, I don't think that's an
> > unreasonable stance (contrast with years ago when i965 feature level
> > was lagging the hw capability and spec).
> 
> This is what I was trying to propose when I proposed this, basically just
> security fixes, major bugs, and build breakages. And the release would 
> straight
> up disable gallium drivers and vulkan drivers (unless Jason wanted to drop <
> gen8 from anv at the same time?) This isn't really all that different than 
> what
> we did in mesa 7 with the dri1 drivers, just using glvnd as the loader instead
> of the mesa loader.

Yes, this as the last release before we delete the classic drivers is the best 
option IMO 

> 
> I really had thought of this as a something to do toward the end of next year 
> or
> early 2021, not something to do immediately. Given another 6-18 months Haswell
> will have gone from pretty old to really old, and hopefully less interesting 
> to
> people.
> 
> Dylan
> 
> > 
> > At the end of the day, it will impact the Intel team the most and I
> > think it's largely their call.
> > 
> > Kristian
> > 
> > >
> > > BR,
> > > -R
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?

[Dylan Baker]

Quoting Kristian Høgsberg (2019-12-04 10:43:46)
> On Wed, Dec 4, 2019 at 10:31 AM Rob Clark  wrote:
> >
> > On Wed, Dec 4, 2019 at 9:48 AM Eric Anholt  wrote:
> > >
> > > On Tue, Dec 3, 2019 at 4:39 PM Marek Olšák  wrote:
> > > >
> > > > Hi,
> > > >
> > > > Here are 2 proposals to simplify and better optimize the GL->Gallium 
> > > > translation.
> > > >
> > > > 1) Move classic drivers to a fork of Mesa, and remove them from master. 
> > > > Classic drivers won't share any code with master. glvnd will load them, 
> > > > but glvnd is not ready for this yet.
> > > >
> > > > 2) Keep classic drivers. Fork src/mesa for Gallium. I think only 
> > > > mesa/main, mesa/vbo, mesa/program, and drivers/dri/common need to be 
> > > > forked and mesa/state_tracker moved. src/gallium/state-trackers/gl/ can 
> > > > be the target location.
> > > >
> > > > Option 2 is more acceptable to people who want to keep classic drivers 
> > > > in the tree and it can be done right now.
> > >
> > > (resending reply-all)
> > >
> > > I object to both of these.  They increase work for Mesa folks like me
> > > who do tree-wide work.
> > >
> > > I feel like we're finally (formats, util/ helpers, etc.) paying down
> > > the technical debt that we built with gallium copying so much of
> > > src/mesa/main, and saying "let's go duplicate more code so we can do
> > > some unspecified optimization work" gets me really upset.
> >
> > tbf option #1 would be a copy of the code.. but a copy that we'd
> > (hopefully) ignore from the perspective of tree-wide cleanup/refactor.
> > If we started refactoring the legacy fork, that would strongly defeat
> > the purpose of having it!
> >
> > Given that we don't have most of the classic drivers (other than i965)
> > in CI, and presumably not many folks who are tracking master test the
> > old classic drivers, moving them off to a fork seems to me to
> > significantly reduce the risk of refactorings (whether it be for perf
> > or for cleanup).
> 
> Another option would be to do a LTS-kind of release of mesa and then
> drop the non-gallium drivers. It could even be limited in scope to the
> non-gallium drivers, in the sense that we'd only do releases for fixes
> to those drivers. It's basically option 1), but saying that we still
> care about maintaining the drivers, but they wont receive new
> features. With i965 being at GL 4.6, I don't think that's an
> unreasonable stance (contrast with years ago when i965 feature level
> was lagging the hw capability and spec).

This is what I was trying to propose when I proposed this, basically just
security fixes, major bugs, and build breakages. And the release would straight
up disable gallium drivers and vulkan drivers (unless Jason wanted to drop <
gen8 from anv at the same time?) This isn't really all that different than what
we did in mesa 7 with the dri1 drivers, just using glvnd as the loader instead
of the mesa loader.

I really had thought of this as a something to do toward the end of next year or
early 2021, not something to do immediately. Given another 6-18 months Haswell
will have gone from pretty old to really old, and hopefully less interesting to
people.

Dylan

> 
> At the end of the day, it will impact the Intel team the most and I
> think it's largely their call.
> 
> Kristian
> 
> >
> > BR,
> > -R


signature.asc
Description: signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?

[Eric Engestrom]

On Wednesday, 2019-12-04 09:48:28 -0800, Eric Anholt wrote:
> On Tue, Dec 3, 2019 at 4:39 PM Marek Olšák  wrote:
> >
> > Hi,
> >
> > Here are 2 proposals to simplify and better optimize the GL->Gallium 
> > translation.
> >
> > 1) Move classic drivers to a fork of Mesa, and remove them from master. 
> > Classic drivers won't share any code with master. glvnd will load them, but 
> > glvnd is not ready for this yet.
> >
> > 2) Keep classic drivers. Fork src/mesa for Gallium. I think only mesa/main, 
> > mesa/vbo, mesa/program, and drivers/dri/common need to be forked and 
> > mesa/state_tracker moved. src/gallium/state-trackers/gl/ can be the target 
> > location.
> >
> > Option 2 is more acceptable to people who want to keep classic drivers in 
> > the tree and it can be done right now.
> 
> (resending reply-all)
> 
> I object to both of these.  They increase work for Mesa folks like me
> who do tree-wide work.
> 
> I feel like we're finally (formats, util/ helpers, etc.) paying down
> the technical debt that we built with gallium copying so much of
> src/mesa/main, and saying "let's go duplicate more code so we can do
> some unspecified optimization work" gets me really upset.

I have to agree there, I don't really see the benefit that could offset
the huge cost of forking the repo or duplicating the folders.

I've had extensive experience at $PREV_JOB with people just duplicating
everything "for the new generation" or "to better organise the code",
and the end result was absolutely unmaintainable and is costing everyone
working on it a seriously large multiplying factor on their work as they
had to copy their changes across and deal with all the changes that
hadn't been copied across by other devs.

They are now wasting huge amount of effort to de-duplicate everything so
that they can get to a point where they can maintain it again.

Let's not make the same mistake :)


I think if we really want to get rid of classic drivers, we should just
delete them from master and not support them at all anymore.
I don't think we're ready for that yet, especially not with i965, but in
a year or so I think that's the best move.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?

[Kristian Høgsberg]

On Wed, Dec 4, 2019 at 10:31 AM Rob Clark  wrote:
>
> On Wed, Dec 4, 2019 at 9:48 AM Eric Anholt  wrote:
> >
> > On Tue, Dec 3, 2019 at 4:39 PM Marek Olšák  wrote:
> > >
> > > Hi,
> > >
> > > Here are 2 proposals to simplify and better optimize the GL->Gallium 
> > > translation.
> > >
> > > 1) Move classic drivers to a fork of Mesa, and remove them from master. 
> > > Classic drivers won't share any code with master. glvnd will load them, 
> > > but glvnd is not ready for this yet.
> > >
> > > 2) Keep classic drivers. Fork src/mesa for Gallium. I think only 
> > > mesa/main, mesa/vbo, mesa/program, and drivers/dri/common need to be 
> > > forked and mesa/state_tracker moved. src/gallium/state-trackers/gl/ can 
> > > be the target location.
> > >
> > > Option 2 is more acceptable to people who want to keep classic drivers in 
> > > the tree and it can be done right now.
> >
> > (resending reply-all)
> >
> > I object to both of these.  They increase work for Mesa folks like me
> > who do tree-wide work.
> >
> > I feel like we're finally (formats, util/ helpers, etc.) paying down
> > the technical debt that we built with gallium copying so much of
> > src/mesa/main, and saying "let's go duplicate more code so we can do
> > some unspecified optimization work" gets me really upset.
>
> tbf option #1 would be a copy of the code.. but a copy that we'd
> (hopefully) ignore from the perspective of tree-wide cleanup/refactor.
> If we started refactoring the legacy fork, that would strongly defeat
> the purpose of having it!
>
> Given that we don't have most of the classic drivers (other than i965)
> in CI, and presumably not many folks who are tracking master test the
> old classic drivers, moving them off to a fork seems to me to
> significantly reduce the risk of refactorings (whether it be for perf
> or for cleanup).

Another option would be to do a LTS-kind of release of mesa and then
drop the non-gallium drivers. It could even be limited in scope to the
non-gallium drivers, in the sense that we'd only do releases for fixes
to those drivers. It's basically option 1), but saying that we still
care about maintaining the drivers, but they wont receive new
features. With i965 being at GL 4.6, I don't think that's an
unreasonable stance (contrast with years ago when i965 feature level
was lagging the hw capability and spec).

At the end of the day, it will impact the Intel team the most and I
think it's largely their call.

Kristian

>
> BR,
> -R
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?

[Rob Clark]

On Wed, Dec 4, 2019 at 9:48 AM Eric Anholt  wrote:
>
> On Tue, Dec 3, 2019 at 4:39 PM Marek Olšák  wrote:
> >
> > Hi,
> >
> > Here are 2 proposals to simplify and better optimize the GL->Gallium 
> > translation.
> >
> > 1) Move classic drivers to a fork of Mesa, and remove them from master. 
> > Classic drivers won't share any code with master. glvnd will load them, but 
> > glvnd is not ready for this yet.
> >
> > 2) Keep classic drivers. Fork src/mesa for Gallium. I think only mesa/main, 
> > mesa/vbo, mesa/program, and drivers/dri/common need to be forked and 
> > mesa/state_tracker moved. src/gallium/state-trackers/gl/ can be the target 
> > location.
> >
> > Option 2 is more acceptable to people who want to keep classic drivers in 
> > the tree and it can be done right now.
>
> (resending reply-all)
>
> I object to both of these.  They increase work for Mesa folks like me
> who do tree-wide work.
>
> I feel like we're finally (formats, util/ helpers, etc.) paying down
> the technical debt that we built with gallium copying so much of
> src/mesa/main, and saying "let's go duplicate more code so we can do
> some unspecified optimization work" gets me really upset.

tbf option #1 would be a copy of the code.. but a copy that we'd
(hopefully) ignore from the perspective of tree-wide cleanup/refactor.
If we started refactoring the legacy fork, that would strongly defeat
the purpose of having it!

Given that we don't have most of the classic drivers (other than i965)
in CI, and presumably not many folks who are tracking master test the
old classic drivers, moving them off to a fork seems to me to
significantly reduce the risk of refactorings (whether it be for perf
or for cleanup).

BR,
-R
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?

[Eric Anholt]

On Tue, Dec 3, 2019 at 4:39 PM Marek Olšák  wrote:
>
> Hi,
>
> Here are 2 proposals to simplify and better optimize the GL->Gallium 
> translation.
>
> 1) Move classic drivers to a fork of Mesa, and remove them from master. 
> Classic drivers won't share any code with master. glvnd will load them, but 
> glvnd is not ready for this yet.
>
> 2) Keep classic drivers. Fork src/mesa for Gallium. I think only mesa/main, 
> mesa/vbo, mesa/program, and drivers/dri/common need to be forked and 
> mesa/state_tracker moved. src/gallium/state-trackers/gl/ can be the target 
> location.
>
> Option 2 is more acceptable to people who want to keep classic drivers in the 
> tree and it can be done right now.

(resending reply-all)

I object to both of these.  They increase work for Mesa folks like me
who do tree-wide work.

I feel like we're finally (formats, util/ helpers, etc.) paying down
the technical debt that we built with gallium copying so much of
src/mesa/main, and saying "let's go duplicate more code so we can do
some unspecified optimization work" gets me really upset.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?

[Eric Anholt]

On Tue, Dec 3, 2019 at 10:48 PM Marek Olšák  wrote:
>
> On Wed., Dec. 4, 2019, 01:20 Tapani Pälli,  wrote:
>>
>> Hi;
>>
>> On 12/4/19 2:39 AM, Marek Olšák wrote:
>> > Hi,
>> >
>> > Here are 2 proposals to simplify and better optimize the GL->Gallium
>> > translation.
>> >
>> > 1) Move classic drivers to a fork of Mesa, and remove them from master.
>> > Classic drivers won't share any code with master. glvnd will load them,
>> > but glvnd is not ready for this yet.
>> >
>> > 2) Keep classic drivers. Fork src/mesa for Gallium. I think only
>> > mesa/main, mesa/vbo, mesa/program, and drivers/dri/common need to be
>> > forked and mesa/state_tracker moved. src/gallium/state-trackers/gl/ can
>> > be the target location.
>> >
>> > Option 2 is more acceptable to people who want to keep classic drivers
>> > in the tree and it can be done right now.
>> >
>> > Opinions?
>> >
>>
>> I'm still quite newbie with gallium side of things and I'd like to know
>> more about the possible simplifications and optimizations that could be
>> done if this happened. Is this more about 'cleaning up the tree' or are
>> there also some performance opportunities we are missing right now with
>> current state?
>
>
> It's possible to reduce CPU overhead even more by moving state translation 
> from st_validate_state to GL functions. This is possible already, but at the 
> cost of effectively adding dead code to classic drivers. In theory we could 
> do slightly better without classic drivers, but we don't know for sure.

So just go do that!  Seriously, just stuff the state structs in the
Mesa context and maintain them as we go, the overhead for classic will
be low enough.  We're going to want to track the raw-style state
anyway for glGet() and all our validation, so it's not like we're
going to be garbage collecting a ton of stuff by forking out classic
drivers.

> If we had nir_to_tgsi, we could remove TGSI support from st/mesa. Option 1 
> would leave st/mesa as the only consumer of Mesa IR and GLSL IR, so both IRs 
> could be eliminated in favor of NIR more easily. Although I guess a simpler 
> option is not to touch anything.

I would love to see someone pick up my nir-to-tgsi branch (now 5 years
old?) and run with it.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?

[Jason Ekstrand]

On Wed, Dec 4, 2019 at 5:51 AM Timothy Arceri  wrote:

>
>
> On 4/12/19 3:45 pm, Jason Ekstrand wrote:
> > On Tue, Dec 3, 2019 at 8:19 PM Dave Airlie  > > wrote:
> >
> > On Wed, 4 Dec 2019 at 10:39, Marek Olšák  > > wrote:
> >  >
> >  > Hi,
> >  >
> >  > Here are 2 proposals to simplify and better optimize the
> > GL->Gallium translation.
> >  >
> >  > 1) Move classic drivers to a fork of Mesa, and remove them from
> > master. Classic drivers won't share any code with master. glvnd will
> > load them, but glvnd is not ready for this yet.
> >
> >
> > I'm usually the first person to tell people to stop mucking about with
> > old hardware and I fear even I think this would be a bit premature.
> > We've not turned iris on by default yet and I'd really like it to bake
> > as the default distro driver for a while (maybe a year) before we put
> > i965 on life-support.  If we were having this discussion in another
> > year's time, I might be in favor of this but, as it currently stands,
> > I'm not sure this is a good idea.
> >
> >  > 2) Keep classic drivers. Fork src/mesa for Gallium. I think only
> > mesa/main, mesa/vbo, mesa/program, and drivers/dri/common need to be
> > forked and mesa/state_tracker moved. src/gallium/state-trackers/gl/
> > can be the target location.
> >
> >
> > I really don't like this option.  For one thing, this means two copies
> > of code that will get out-of-sync.  If we had the classic drivers in
> > their own branch, we could at least cherry-pick bugfixes back to the
> > classic branch.  However, if we have two copies of everything, our
> > version control tool can't help us.
> >
> > The bigger problem is headers.  Currently, the GLSL compiler includes
> > mtypes.h so we would need to somehow separate the GLSL compiler out from
> > src/mesa/main because we'll have two mtypes.h files.  Unfortunately,
> > GLSL isn't the only thing that includes stuff from src/mesa/main.  Our
> > header situation has been a disaster for years and I'm afraid it hasn't
> > gotten any better with the addition of src/util.  Most people who move
> > stuff don't actually do due diligence to keep the includes clean and the
> > result is that I'm pretty sure even the Vulkan drivers are including
> > src/mesa/main/imports.h.  If we have two copies of src/mesa/main and the
> > headers begin to diverge, it's going to be a total disaster.  I would
> > love to see someone clean this all up properly and I think Mesa would be
> > better for it.  However, it is a LOT of work.
> >
> > If we did the above cleaning, would I be ok with this approach?
> > Possibly.  However, I suspect it'd end up being the worst of both
> > worlds.  We still have maintenance of effectively two branches and
> > bugfixes have to be ported.  At the same time, we'd still have core
> > changes to things like the GLSL compiler breaking old drivers so we
> > wouldn't lighten any of the maintenance burden.
> >
> >  > Option 2 is more acceptable to people who want to keep classic
> > drivers in the tree and it can be done right now.
> >
> > These both seem pretty horrible to me right now. Like i965 still
> > supports a lot of hardware that exists right now even if we move to
> > iris.
> >
> >
> > I'm less concerned about the support burden.  When it comes to bugfixes,
> > I feel like most of the bugs on gen7 and earlier hardware at this point
> > are due to churn in the core and if it lives in a maintenance branch,
> > we'll stop breaking it.  The biggest thing we'd loose would be
> > additional features that we might get thanks to core changes.  The major
> > ones that come to mind are:
> >
> >   - GL_ARB_gl_spirv (It could be enabled on gen7 in theory but we
> > haven't due to a lack of testing) >   - GL_EXT_direct_state_access
> (still underway last I knew)
>
> Is already done and enabled for compat profile.
>

Nice!  I thought there was still work left to do there.


> >   - GL_EXT_gpu_shader4
>
> Core mesa parts are done for this also.
>

Nice!  Somehow we didn't notice this happen.  I've pushed a MR for Gen6+ on
i965: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2963


> >   - Compat context support
>
> radeonsi, nouveau and iris all fully enable this. At this point its just
> a driver/classic issue to add support. So as with the two other features
> above options 1 or 2 will not change the fate of this support.
>

Yeah, it's mostly debug work not core mesa work.  So maybe not a blocker.


> >
> > All four of those are more-or-less software-only features that older
> > intel drivers could pick up as the core advances.  Compat support likely
> > requires a bit of driver work but it should be doable.
> >
> > The real question is, "How much do we care?"  I can't say I like the
> > idea of leaving Gen4-7 out in the cold.  Again, in a year's time, we
> > might have most of the above implemented and then it'd 

Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?

[Dylan Baker]

Quoting Dave Airlie (2019-12-03 18:18:55)
> On Wed, 4 Dec 2019 at 10:39, Marek Olšák  wrote:
> >
> > Hi,
> >
> > Here are 2 proposals to simplify and better optimize the GL->Gallium 
> > translation.
> >
> > 1) Move classic drivers to a fork of Mesa, and remove them from master. 
> > Classic drivers won't share any code with master. glvnd will load them, but 
> > glvnd is not ready for this yet.
> >
> > 2) Keep classic drivers. Fork src/mesa for Gallium. I think only mesa/main, 
> > mesa/vbo, mesa/program, and drivers/dri/common need to be forked and 
> > mesa/state_tracker moved. src/gallium/state-trackers/gl/ can be the target 
> > location.
> >
> > Option 2 is more acceptable to people who want to keep classic drivers in 
> > the tree and it can be done right now.
> 
> These both seem pretty horrible to me right now. Like i965 still
> supports a lot of hardware that exists right now even if we move to
> iris.
> 
> I sorta feel there should be a
> 3) make life harder for classic drivers and optimise things more for
> gallium add more dd.h entrypoints, force the classic drivers to jump
> through hoops to degallium.

Maybe I'm misunderstanding what you mean, but what I'm hearing you say is
"modify src/mesa so that every single classic driver will have to be churned
significantly or stop working", which sounds much worse than options 1 or 2,
because the main problem with classic is that i965 is the only classic driver
that's really being maintained.

> I don't like forking src/mesa/main/* because really 99% of it is just
> a GL frontend implementation, most bugs in it will be in a fork and
> vice-versa, I'd rather refine the abstraction between mesa and
> backends if possible to reduce the overheads.
> 
> I'm probably not convinced that any benefit is worth accepting 1 or 2
> above, but hey I've been persuaded before to do crazy things.
> 
> Dave.
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


signature.asc
Description: signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?

[Dylan Baker]

Quoting Marek Olšák (2019-12-03 16:39:15)
> Hi,
> 
> Here are 2 proposals to simplify and better optimize the GL->Gallium
> translation.
> 
> 1) Move classic drivers to a fork of Mesa, and remove them from master. 
> Classic
> drivers won't share any code with master. glvnd will load them, but glvnd is
> not ready for this yet.

I think glvnd 1.3.0 will be able to do what we want, and that should happen in
the near future. Matt has been helping that work from the distro point of view,
so maybe he can confirm that.

> 2) Keep classic drivers. Fork src/mesa for Gallium. I think only mesa/main,
> mesa/vbo, mesa/program, and drivers/dri/common need to be forked and mesa/
> state_tracker moved. src/gallium/state-trackers/gl/ can be the target 
> location.
> 
> Option 2 is more acceptable to people who want to keep classic drivers in the
> tree and it can be done right now.
> 
> Opinions?
> 
> Thanks,
> Marek


signature.asc
Description: signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?

[Dylan Baker]

Quoting Jason Ekstrand (2019-12-03 20:45:33)
> On Tue, Dec 3, 2019 at 8:19 PM Dave Airlie  wrote:
> 
> On Wed, 4 Dec 2019 at 10:39, Marek Olšák  wrote:
> >
> > Hi,
> >
> > Here are 2 proposals to simplify and better optimize the GL->Gallium
> translation.
> >
> > 1) Move classic drivers to a fork of Mesa, and remove them from master.
> Classic drivers won't share any code with master. glvnd will load them, 
> but
> glvnd is not ready for this yet.
> 
> 
> I'm usually the first person to tell people to stop mucking about with old
> hardware and I fear even I think this would be a bit premature.  We've not
> turned iris on by default yet and I'd really like it to bake as the default
> distro driver for a while (maybe a year) before we put i965 on life-support. 
> If we were having this discussion in another year's time, I might be in favor
> of this but, as it currently stands, I'm not sure this is a good idea.
>  
> 
> > 2) Keep classic drivers. Fork src/mesa for Gallium. I think only mesa/
> main, mesa/vbo, mesa/program, and drivers/dri/common need to be forked and
> mesa/state_tracker moved. src/gallium/state-trackers/gl/ can be the target
> location.
> 
> 
> I really don't like this option.  For one thing, this means two copies of code
> that will get out-of-sync.  If we had the classic drivers in their own branch,
> we could at least cherry-pick bugfixes back to the classic branch.  However, 
> if
> we have two copies of everything, our version control tool can't help us.
> 
> The bigger problem is headers.  Currently, the GLSL compiler includes mtypes.h
> so we would need to somehow separate the GLSL compiler out from src/mesa/main
> because we'll have two mtypes.h files.  Unfortunately, GLSL isn't the only
> thing that includes stuff from src/mesa/main.  Our header situation has been a
> disaster for years and I'm afraid it hasn't gotten any better with the 
> addition
> of src/util.  Most people who move stuff don't actually do due diligence to
> keep the includes clean and the result is that I'm pretty sure even the Vulkan
> drivers are including src/mesa/main/imports.h.  If we have two copies of src/
> mesa/main and the headers begin to diverge, it's going to be a total 
> disaster. 
> I would love to see someone clean this all up properly and I think Mesa would
> be better for it.  However, it is a LOT of work.

I have an MR that's been sitting on the list for over a year that remove
imports.h completely. I can rebase that today.

> 
> If we did the above cleaning, would I be ok with this approach?  Possibly. 
> However, I suspect it'd end up being the worst of both worlds.  We still have
> maintenance of effectively two branches and bugfixes have to be ported.  At 
> the
> same time, we'd still have core changes to things like the GLSL compiler
> breaking old drivers so we wouldn't lighten any of the maintenance burden.
>  
> 
> > Option 2 is more acceptable to people who want to keep classic drivers 
> in
> the tree and it can be done right now.
> 
> These both seem pretty horrible to me right now. Like i965 still
> supports a lot of hardware that exists right now even if we move to
> iris.
> 
> 
> I'm less concerned about the support burden.  When it comes to bugfixes, I 
> feel
> like most of the bugs on gen7 and earlier hardware at this point are due to
> churn in the core and if it lives in a maintenance branch, we'll stop breaking
> it.  The biggest thing we'd loose would be additional features that we might
> get thanks to core changes.  The major ones that come to mind are:
> 
>  - GL_ARB_gl_spirv (It could be enabled on gen7 in theory but we haven't due 
> to
> a lack of testing)
>  - GL_EXT_direct_state_access (still underway last I knew)
>  - GL_EXT_gpu_shader4
>  - Compat context support
> 
> All four of those are more-or-less software-only features that older intel
> drivers could pick up as the core advances.  Compat support likely requires a
> bit of driver work but it should be doable.
> 
> The real question is, "How much do we care?"  I can't say I like the idea of
> leaving Gen4-7 out in the cold.  Again, in a year's time, we might have most 
> of
> the above implemented and then it'd be less of a concern.
>  
> 
> I sorta feel there should be a
> 3) make life harder for classic drivers and optimise things more for
> gallium add more dd.h entrypoints, force the classic drivers to jump
> through hoops to degallium.
> 
> 
> I'd be interested to see what that would look like.  I'm not actually 
> convinced
> that it would work if I'm honest.  Part of gluing them together in my mind is
> deleting dd.h entirely and making the GL state tracker just call gallium 
> stuff.
> 
> There may be a 4th option here: Write a gallium driver for Intel Gen4-7. 
> Unfortunately, it would be a really hard sell to convince anyone (myself
> included) that this is worth anyone's time.  Sure, it might be a fun 

Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?

[Timothy Arceri]

On 4/12/19 3:45 pm, Jason Ekstrand wrote:
On Tue, Dec 3, 2019 at 8:19 PM Dave Airlie > wrote:


On Wed, 4 Dec 2019 at 10:39, Marek Olšák mailto:mar...@gmail.com>> wrote:
 >
 > Hi,
 >
 > Here are 2 proposals to simplify and better optimize the
GL->Gallium translation.
 >
 > 1) Move classic drivers to a fork of Mesa, and remove them from
master. Classic drivers won't share any code with master. glvnd will
load them, but glvnd is not ready for this yet.


I'm usually the first person to tell people to stop mucking about with 
old hardware and I fear even I think this would be a bit premature.  
We've not turned iris on by default yet and I'd really like it to bake 
as the default distro driver for a while (maybe a year) before we put 
i965 on life-support.  If we were having this discussion in another 
year's time, I might be in favor of this but, as it currently stands, 
I'm not sure this is a good idea.


 > 2) Keep classic drivers. Fork src/mesa for Gallium. I think only
mesa/main, mesa/vbo, mesa/program, and drivers/dri/common need to be
forked and mesa/state_tracker moved. src/gallium/state-trackers/gl/
can be the target location.


I really don't like this option.  For one thing, this means two copies 
of code that will get out-of-sync.  If we had the classic drivers in 
their own branch, we could at least cherry-pick bugfixes back to the 
classic branch.  However, if we have two copies of everything, our 
version control tool can't help us.


The bigger problem is headers.  Currently, the GLSL compiler includes 
mtypes.h so we would need to somehow separate the GLSL compiler out from 
src/mesa/main because we'll have two mtypes.h files.  Unfortunately, 
GLSL isn't the only thing that includes stuff from src/mesa/main.  Our 
header situation has been a disaster for years and I'm afraid it hasn't 
gotten any better with the addition of src/util.  Most people who move 
stuff don't actually do due diligence to keep the includes clean and the 
result is that I'm pretty sure even the Vulkan drivers are including 
src/mesa/main/imports.h.  If we have two copies of src/mesa/main and the 
headers begin to diverge, it's going to be a total disaster.  I would 
love to see someone clean this all up properly and I think Mesa would be 
better for it.  However, it is a LOT of work.


If we did the above cleaning, would I be ok with this approach?  
Possibly.  However, I suspect it'd end up being the worst of both 
worlds.  We still have maintenance of effectively two branches and 
bugfixes have to be ported.  At the same time, we'd still have core 
changes to things like the GLSL compiler breaking old drivers so we 
wouldn't lighten any of the maintenance burden.


 > Option 2 is more acceptable to people who want to keep classic
drivers in the tree and it can be done right now.

These both seem pretty horrible to me right now. Like i965 still
supports a lot of hardware that exists right now even if we move to
iris.


I'm less concerned about the support burden.  When it comes to bugfixes, 
I feel like most of the bugs on gen7 and earlier hardware at this point 
are due to churn in the core and if it lives in a maintenance branch, 
we'll stop breaking it.  The biggest thing we'd loose would be 
additional features that we might get thanks to core changes.  The major 
ones that come to mind are:


  - GL_ARB_gl_spirv (It could be enabled on gen7 in theory but we 
haven't due to a lack of testing) >   - GL_EXT_direct_state_access (still underway last I knew)


Is already done and enabled for compat profile.


  - GL_EXT_gpu_shader4


Core mesa parts are done for this also.


  - Compat context support


radeonsi, nouveau and iris all fully enable this. At this point its just 
a driver/classic issue to add support. So as with the two other features 
above options 1 or 2 will not change the fate of this support.




All four of those are more-or-less software-only features that older 
intel drivers could pick up as the core advances.  Compat support likely 
requires a bit of driver work but it should be doable.


The real question is, "How much do we care?"  I can't say I like the 
idea of leaving Gen4-7 out in the cold.  Again, in a year's time, we 
might have most of the above implemented and then it'd be less of a concern.


As per above its only GL_ARB_gl_spirv that would maybe be impacted by 
any fork, but that doesn't change between now and a year so delaying a 
decision for a year based on this is doesn't seem necessary.




I sorta feel there should be a
3) make life harder for classic drivers and optimise things more for
gallium add more dd.h entrypoints, force the classic drivers to jump
through hoops to degallium.


I'd be interested to see what that would look like.  I'm not actually 
convinced that it would work if I'm honest.  Part of gluing them 
together in my mind is deleting dd.h 

Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?

[Erik Faye-Lund]

On Wed, 2019-12-04 at 01:48 -0500, Marek Olšák wrote:
> On Wed., Dec. 4, 2019, 01:20 Tapani Pälli, 
> wrote:
> > Hi;
> > 
> > On 12/4/19 2:39 AM, Marek Olšák wrote:
> > > Hi,
> > > 
> > > Here are 2 proposals to simplify and better optimize the GL-
> > >Gallium 
> > > translation.
> > > 
> > > 1) Move classic drivers to a fork of Mesa, and remove them from
> > master. 
> > > Classic drivers won't share any code with master. glvnd will load
> > them, 
> > > but glvnd is not ready for this yet.
> > > 
> > > 2) Keep classic drivers. Fork src/mesa for Gallium. I think only 
> > > mesa/main, mesa/vbo, mesa/program, and drivers/dri/common need to
> > be 
> > > forked and mesa/state_tracker moved. src/gallium/state-
> > trackers/gl/ can 
> > > be the target location.
> > > 
> > > Option 2 is more acceptable to people who want to keep classic
> > drivers 
> > > in the tree and it can be done right now.
> > > 
> > > Opinions?
> > > 
> > 
> > I'm still quite newbie with gallium side of things and I'd like to
> > know 
> > more about the possible simplifications and optimizations that
> > could be 
> > done if this happened. Is this more about 'cleaning up the tree' or
> > are 
> > there also some performance opportunities we are missing right now
> > with 
> > current state?
> 
> It's possible to reduce CPU overhead even more by moving state
> translation from st_validate_state to GL functions. This is possible
> already, but at the cost of effectively adding dead code to classic
> drivers. In theory we could do slightly better without classic
> drivers, but we don't know for sure.
> 
> If we had nir_to_tgsi, we could remove TGSI support from st/mesa.
> Option 1 would leave st/mesa as the only consumer of Mesa IR and GLSL
> IR, so both IRs could be eliminated in favor of NIR more easily. 

Implementing nir_to_tgsi is something I've considered several times
while working on VirGL; there's a lot of useful lowering-code in NIR
that sometimes has to be re-implemented in TGSI, and writing new
lowering code targetting NIR is just so much nicer than when targetting
TGSI.

For both SVGA and VirGL, TGSI can't be completely eliminated without
breaking compatibility, because TGSI is part of their protocols. And I
believe in both cases, it's a slightly divergent variation of TGSI.

So yeah, just wanted to say: +1 on this part :)

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?

[Marek Olšák]

On Wed., Dec. 4, 2019, 01:20 Tapani Pälli,  wrote:

> Hi;
>
> On 12/4/19 2:39 AM, Marek Olšák wrote:
> > Hi,
> >
> > Here are 2 proposals to simplify and better optimize the GL->Gallium
> > translation.
> >
> > 1) Move classic drivers to a fork of Mesa, and remove them from master.
> > Classic drivers won't share any code with master. glvnd will load them,
> > but glvnd is not ready for this yet.
> >
> > 2) Keep classic drivers. Fork src/mesa for Gallium. I think only
> > mesa/main, mesa/vbo, mesa/program, and drivers/dri/common need to be
> > forked and mesa/state_tracker moved. src/gallium/state-trackers/gl/ can
> > be the target location.
> >
> > Option 2 is more acceptable to people who want to keep classic drivers
> > in the tree and it can be done right now.
> >
> > Opinions?
> >
>
> I'm still quite newbie with gallium side of things and I'd like to know
> more about the possible simplifications and optimizations that could be
> done if this happened. Is this more about 'cleaning up the tree' or are
> there also some performance opportunities we are missing right now with
> current state?


It's possible to reduce CPU overhead even more by moving state translation
from st_validate_state to GL functions. This is possible already, but at
the cost of effectively adding dead code to classic drivers. In theory we
could do slightly better without classic drivers, but we don't know for
sure.

If we had nir_to_tgsi, we could remove TGSI support from st/mesa. Option 1
would leave st/mesa as the only consumer of Mesa IR and GLSL IR, so both
IRs could be eliminated in favor of NIR more easily. Although I guess a
simpler option is not to touch anything.

Marek

Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?

[Tapani Pälli]

Hi;

On 12/4/19 2:39 AM, Marek Olšák wrote:

Hi,

Here are 2 proposals to simplify and better optimize the GL->Gallium 
translation.


1) Move classic drivers to a fork of Mesa, and remove them from master. 
Classic drivers won't share any code with master. glvnd will load them, 
but glvnd is not ready for this yet.


2) Keep classic drivers. Fork src/mesa for Gallium. I think only 
mesa/main, mesa/vbo, mesa/program, and drivers/dri/common need to be 
forked and mesa/state_tracker moved. src/gallium/state-trackers/gl/ can 
be the target location.


Option 2 is more acceptable to people who want to keep classic drivers 
in the tree and it can be done right now.


Opinions?



I'm still quite newbie with gallium side of things and I'd like to know 
more about the possible simplifications and optimizations that could be 
done if this happened. Is this more about 'cleaning up the tree' or are 
there also some performance opportunities we are missing right now with 
current state?


Thanks;

// Tapani
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?

[Jason Ekstrand]

On Tue, Dec 3, 2019 at 8:19 PM Dave Airlie  wrote:

> On Wed, 4 Dec 2019 at 10:39, Marek Olšák  wrote:
> >
> > Hi,
> >
> > Here are 2 proposals to simplify and better optimize the GL->Gallium
> translation.
> >
> > 1) Move classic drivers to a fork of Mesa, and remove them from master.
> Classic drivers won't share any code with master. glvnd will load them, but
> glvnd is not ready for this yet.
>

I'm usually the first person to tell people to stop mucking about with old
hardware and I fear even I think this would be a bit premature.  We've not
turned iris on by default yet and I'd really like it to bake as the default
distro driver for a while (maybe a year) before we put i965 on
life-support.  If we were having this discussion in another year's time, I
might be in favor of this but, as it currently stands, I'm not sure this is
a good idea.


> > 2) Keep classic drivers. Fork src/mesa for Gallium. I think only
> mesa/main, mesa/vbo, mesa/program, and drivers/dri/common need to be forked
> and mesa/state_tracker moved. src/gallium/state-trackers/gl/ can be the
> target location.
>

I really don't like this option.  For one thing, this means two copies of
code that will get out-of-sync.  If we had the classic drivers in their own
branch, we could at least cherry-pick bugfixes back to the classic branch.
However, if we have two copies of everything, our version control tool
can't help us.

The bigger problem is headers.  Currently, the GLSL compiler includes
mtypes.h so we would need to somehow separate the GLSL compiler out from
src/mesa/main because we'll have two mtypes.h files.  Unfortunately, GLSL
isn't the only thing that includes stuff from src/mesa/main.  Our header
situation has been a disaster for years and I'm afraid it hasn't gotten any
better with the addition of src/util.  Most people who move stuff don't
actually do due diligence to keep the includes clean and the result is that
I'm pretty sure even the Vulkan drivers are including
src/mesa/main/imports.h.  If we have two copies of src/mesa/main and the
headers begin to diverge, it's going to be a total disaster.  I would love
to see someone clean this all up properly and I think Mesa would be better
for it.  However, it is a LOT of work.

If we did the above cleaning, would I be ok with this approach?  Possibly.
However, I suspect it'd end up being the worst of both worlds.  We still
have maintenance of effectively two branches and bugfixes have to be
ported.  At the same time, we'd still have core changes to things like the
GLSL compiler breaking old drivers so we wouldn't lighten any of the
maintenance burden.


> > Option 2 is more acceptable to people who want to keep classic drivers
> in the tree and it can be done right now.
>
> These both seem pretty horrible to me right now. Like i965 still
> supports a lot of hardware that exists right now even if we move to
> iris.
>

I'm less concerned about the support burden.  When it comes to bugfixes, I
feel like most of the bugs on gen7 and earlier hardware at this point are
due to churn in the core and if it lives in a maintenance branch, we'll
stop breaking it.  The biggest thing we'd loose would be additional
features that we might get thanks to core changes.  The major ones that
come to mind are:

 - GL_ARB_gl_spirv (It could be enabled on gen7 in theory but we haven't
due to a lack of testing)
 - GL_EXT_direct_state_access (still underway last I knew)
 - GL_EXT_gpu_shader4
 - Compat context support

All four of those are more-or-less software-only features that older intel
drivers could pick up as the core advances.  Compat support likely requires
a bit of driver work but it should be doable.

The real question is, "How much do we care?"  I can't say I like the idea
of leaving Gen4-7 out in the cold.  Again, in a year's time, we might have
most of the above implemented and then it'd be less of a concern.


> I sorta feel there should be a
> 3) make life harder for classic drivers and optimise things more for
> gallium add more dd.h entrypoints, force the classic drivers to jump
> through hoops to degallium.
>

I'd be interested to see what that would look like.  I'm not actually
convinced that it would work if I'm honest.  Part of gluing them together
in my mind is deleting dd.h entirely and making the GL state tracker just
call gallium stuff.

There may be a 4th option here: Write a gallium driver for Intel Gen4-7.
Unfortunately, it would be a really hard sell to convince anyone (myself
included) that this is worth anyone's time.  Sure, it might be a fun
project, but the engineering effort required to get it to be as good as
i965 is very non-trivial.  I think it's tractable and someone who knows
what they're doing would probably be able to get something working in less
than a year if they steal heavily from i965 and iris.  However, getting it
to the point where performance is no worse may take longer.  While it'd
probably be a fun project for someone, I can't in good conscience say 

Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?

[Dave Airlie]

On Wed, 4 Dec 2019 at 10:39, Marek Olšák  wrote:
>
> Hi,
>
> Here are 2 proposals to simplify and better optimize the GL->Gallium 
> translation.
>
> 1) Move classic drivers to a fork of Mesa, and remove them from master. 
> Classic drivers won't share any code with master. glvnd will load them, but 
> glvnd is not ready for this yet.
>
> 2) Keep classic drivers. Fork src/mesa for Gallium. I think only mesa/main, 
> mesa/vbo, mesa/program, and drivers/dri/common need to be forked and 
> mesa/state_tracker moved. src/gallium/state-trackers/gl/ can be the target 
> location.
>
> Option 2 is more acceptable to people who want to keep classic drivers in the 
> tree and it can be done right now.

These both seem pretty horrible to me right now. Like i965 still
supports a lot of hardware that exists right now even if we move to
iris.

I sorta feel there should be a
3) make life harder for classic drivers and optimise things more for
gallium add more dd.h entrypoints, force the classic drivers to jump
through hoops to degallium.

I don't like forking src/mesa/main/* because really 99% of it is just
a GL frontend implementation, most bugs in it will be in a fork and
vice-versa, I'd rather refine the abstraction between mesa and
backends if possible to reduce the overheads.

I'm probably not convinced that any benefit is worth accepting 1 or 2
above, but hey I've been persuaded before to do crazy things.

Dave.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev