gpu/docs: Clarify what userspace means for gl

Commit Message

Daniel Vetter April 24, 2019, 1:46 p.m. UTC

Clear rules avoid arguing.

Note that this just aims to document current expectations. If that
shifts (e.g. because gl isn't the main api anymore, replaced by vk),
then we need to update this text.

I think it'd be good to have an equally solid list on the kms side.
But kms is much more meant to be a standard, and the list of userspace
projects we've accepted in the past is constantly shifting and
adjusting. So I figured I'll leave that as an exercise for later on.

v2: Try to clarify that we don't want a mesa driver just for mesa's
sake, and more clearly exclude anything that just doesn't make sense
technically.  Example would be a compute driver that makes sense to be
merged into drm (for kernel side code-sharing), but where the intended
use is some single-source CUDA-style compute without ever bothering
about any of the 3D/rendering side baggage that comes with gl/vk.

v3: Drop vulkan for now, the situation there isn't as obviously
clear-cut as on the gl side, and I don't want to tank this idea on a
hot discussion about vk and mesa. Plus I think once we have 1-2 more
vk drivers in mesa the situation on the vk side is clear-cut too, and
we can do a follow-up patch to add vk to the list where we expect the
userspace to be in upstream mesa. That's would give nice precedence to
make it clear that this isn't cast in stone, but meant to reflect
reality and should be adjusted as needed.

v4: Fix typo.

v5: Add a note to the commit message that this text needs to be
updated when the situation changes.

v6: Add a sentence why mesa will give the most meaningful review on gl
stuff - it's a very active project with lots of developers.

Acked-by: Dave Airlie <[e-mail]> (v4)
Acked-by: Eric Anholt <[e-mail]> (v4)
Acked-by: Alex Deucher <[e-mail]> (v5)
Acked-by: Sean Paul <[e-mail]> (v5)
Acked-by: Kenneth Graunke <[e-mail]> (v5)
Acked-by: Karol Herbst <[e-mail]> (v5)
Acked-by: Rob Clark <[e-mail]>
Acked-by: Jérôme Glisse <[e-mail]>
Acked-by: Bas Nieuwenhuizen <[e-mail]>
Acked-by: Ben Skeggs <[e-mail]>
Cc: Dave Airlie <[e-mail]>
Cc: Eric Anholt <[e-mail]>
Cc: Alex Deucher <[e-mail]>
Cc: Sean Paul <[e-mail]>
Cc: Kenneth Graunke <[e-mail]>
Cc: Karol Herbst <[e-mail]>
Cc: Rob Clark <[e-mail]>
Cc: Jérôme Glisse <[e-mail]>
Cc: Bas Nieuwenhuizen <[e-mail]>
Cc: Ben Skeggs <[e-mail]>
Signed-off-by: Daniel Vetter <[e-mail]>
---
I chatted with a pile of people in private, and there's clearly some
solid support for this. But there's also some big concerns brought up
by other people. The main one summed up is "what if everyone just
ships vk, with a generic gl-on-vk like ANGLE?", but there's other
concerns too.

So all together I think this doesn't clear the bar of (almost)
unanimous support which we need to make documentation actually help
with clarifying what's expected. And if/when someone comes up with a
more creative userspace approach for gl/vk we'll need to figure this
all out with the time honored tradition of having a few massive
threads on dri-devel :-)

Hence this is more fyi as a guidance I guess, not a strict&hard rule.
And I don't plan on merging this.

Cheers, Daniel
---
 Documentation/gpu/drm-uapi.rst | 25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)

Comments

Chunming Zhou April 24, 2019, 2:24 p.m. UTC | #1

Will linux be only mesa-linux? I thought linux is an  open linux.
Which will impact our opengl/amdvlk(MIT open source), not sure Rocm:
1. how to deal with one uapi that opengl/amdvlk needs but mesa dont need? reject?
2. one hw feature that opengl/amdvlk developers work on that but no mesa developers work on, cannot upstream as well?

I think above two would easily happen, because there are many employees working on company project with many customer kinds of reqiurements, but mesa not.

-David

-------- Original Message --------
Subject: [PATCH] gpu/docs: Clarify what userspace means for gl
From: Daniel Vetter
To: DRI Development ,Mesa Dev
CC: Jérôme Glisse ,Daniel Vetter ,Karol Herbst ,Kenneth Graunke ,Ben Skeggs ,Daniel Vetter ,Sean Paul

Clear rules avoid arguing.

Note that this just aims to document current expectations. If that
shifts (e.g. because gl isn't the main api anymore, replaced by vk),
then we need to update this text.

I think it'd be good to have an equally solid list on the kms side.
But kms is much more meant to be a standard, and the list of userspace
projects we've accepted in the past is constantly shifting and
adjusting. So I figured I'll leave that as an exercise for later on.

v2: Try to clarify that we don't want a mesa driver just for mesa's
sake, and more clearly exclude anything that just doesn't make sense
technically.  Example would be a compute driver that makes sense to be
merged into drm (for kernel side code-sharing), but where the intended
use is some single-source CUDA-style compute without ever bothering
about any of the 3D/rendering side baggage that comes with gl/vk.

v3: Drop vulkan for now, the situation there isn't as obviously
clear-cut as on the gl side, and I don't want to tank this idea on a
hot discussion about vk and mesa. Plus I think once we have 1-2 more
vk drivers in mesa the situation on the vk side is clear-cut too, and
we can do a follow-up patch to add vk to the list where we expect the
userspace to be in upstream mesa. That's would give nice precedence to
make it clear that this isn't cast in stone, but meant to reflect
reality and should be adjusted as needed.

v4: Fix typo.

v5: Add a note to the commit message that this text needs to be
updated when the situation changes.

v6: Add a sentence why mesa will give the most meaningful review on gl
stuff - it's a very active project with lots of developers.

Acked-by: Dave Airlie <[e-mail]> (v4)
Acked-by: Eric Anholt <[e-mail]> (v4)
Acked-by: Alex Deucher <[e-mail]> (v5)
Acked-by: Sean Paul <[e-mail]> (v5)
Acked-by: Kenneth Graunke <[e-mail]> (v5)
Acked-by: Karol Herbst <[e-mail]> (v5)
Acked-by: Rob Clark <[e-mail]>
Acked-by: Jérôme Glisse <[e-mail]>
Acked-by: Bas Nieuwenhuizen <[e-mail]>
Acked-by: Ben Skeggs <[e-mail]>
Cc: Dave Airlie <[e-mail]>
Cc: Eric Anholt <[e-mail]>
Cc: Alex Deucher <[e-mail]>
Cc: Sean Paul <[e-mail]>
Cc: Kenneth Graunke <[e-mail]>
Cc: Karol Herbst <[e-mail]>
Cc: Rob Clark <[e-mail]>
Cc: Jérôme Glisse <[e-mail]>
Cc: Bas Nieuwenhuizen <[e-mail]>
Cc: Ben Skeggs <[e-mail]>
Signed-off-by: Daniel Vetter <[e-mail]>
---
I chatted with a pile of people in private, and there's clearly some
solid support for this. But there's also some big concerns brought up
by other people. The main one summed up is "what if everyone just
ships vk, with a generic gl-on-vk like ANGLE?", but there's other
concerns too.

So all together I think this doesn't clear the bar of (almost)
unanimous support which we need to make documentation actually help
with clarifying what's expected. And if/when someone comes up with a
more creative userspace approach for gl/vk we'll need to figure this
all out with the time honored tradition of having a few massive
threads on dri-devel :-)

Hence this is more fyi as a guidance I guess, not a strict&hard rule.
And I don't plan on merging this.

Cheers, Daniel
---
 Documentation/gpu/drm-uapi.rst | 25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)

diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
index c9fd23efd957..0f767cfd5db6 100644
--- a/Documentation/gpu/drm-uapi.rst
+++ b/Documentation/gpu/drm-uapi.rst
@@ -105,6 +105,31 @@ is already rather painful for the DRM subsystem, with multiple different uAPIs
 for the same thing co-existing. If we add a few more complete mistakes into the
 mix every year it would be entirely unmanageable.

+Below some clarifications what this means for specific areas in DRM.
+
+Compute&Rendering Userspace
+---------------------------
+
+Userspace API for enabling compute and rendering blocks which are capable of at
+least supporting one of the OpenGL or OpenGL ES standards from Khronos need to
+be enabled in the upstream `Mesa3D project<https://www.mesa3d.org/>`.
+
+Mesa3D is the canonical upstream for these areas because it is a fully
+compliant, performant and cross-vendor implementation that supports all kernel
+drivers in DRM. It is also an active project with plenty of developers who
+can perform meaningful review. It is therefore the best platform to validate
+userspace API and especially make sure that cross-vendor interoperation is
+assured.
+
+Other userspace is only admissible if exposing a given feature through OpenGL or
+OpenGL ES would result in a technically unsound design, incomplete driver or
+an implementation which isn't useful in real world usage.
+
+Other areas, like media codec, which Mesa3D supports for just some drivers, but
+isn't the clear universal choice, are excluded from this policy. Driver teams
+are still encourage to aim for shared, cross-vendor infrastructure in userspace
+as much as possible.
+
 .. _drm_render_node:

 Render nodes
--
2.20.1

Daniel Vetter April 24, 2019, 2:28 p.m. UTC | #2

On Wed, Apr 24, 2019 at 4:24 PM Zhou, David(ChunMing)
<[e-mail]> wrote:
> Will linux be only mesa-linux? I thought linux is an  open linux.
> Which will impact our opengl/amdvlk(MIT open source), not sure Rocm:
> 1. how to deal with one uapi that opengl/amdvlk needs but mesa dont need? reject?
> 2. one hw feature that opengl/amdvlk developers work on that but no mesa developers work on, cannot upstream as well?
>
> I think above two would easily happen, because there are many employees working on company project with many customer kinds of reqiurements, but mesa not.

Well those are the questions I tried to have a clear answer for, to
avoid confusion, but looks like the agreement isn't perfect. But
there's pretty clear favour towards cross vendor userspace that's
collaboratively and openly developed like mesa. So whenever one of the
above cases you bring up happen we'll get to have a big thread on
dri-devel I guess.
-Daniel


> -David
>
> -------- Original Message --------
> Subject: [PATCH] gpu/docs: Clarify what userspace means for gl
> From: Daniel Vetter
> To: DRI Development ,Mesa Dev
> CC: Jérôme Glisse ,Daniel Vetter ,Karol Herbst ,Kenneth Graunke ,Ben Skeggs ,Daniel Vetter ,Sean Paul
>
> Clear rules avoid arguing.
>
> Note that this just aims to document current expectations. If that
> shifts (e.g. because gl isn't the main api anymore, replaced by vk),
> then we need to update this text.
>
> I think it'd be good to have an equally solid list on the kms side.
> But kms is much more meant to be a standard, and the list of userspace
> projects we've accepted in the past is constantly shifting and
> adjusting. So I figured I'll leave that as an exercise for later on.
>
> v2: Try to clarify that we don't want a mesa driver just for mesa's
> sake, and more clearly exclude anything that just doesn't make sense
> technically.  Example would be a compute driver that makes sense to be
> merged into drm (for kernel side code-sharing), but where the intended
> use is some single-source CUDA-style compute without ever bothering
> about any of the 3D/rendering side baggage that comes with gl/vk.
>
> v3: Drop vulkan for now, the situation there isn't as obviously
> clear-cut as on the gl side, and I don't want to tank this idea on a
> hot discussion about vk and mesa. Plus I think once we have 1-2 more
> vk drivers in mesa the situation on the vk side is clear-cut too, and
> we can do a follow-up patch to add vk to the list where we expect the
> userspace to be in upstream mesa. That's would give nice precedence to
> make it clear that this isn't cast in stone, but meant to reflect
> reality and should be adjusted as needed.
>
> v4: Fix typo.
>
> v5: Add a note to the commit message that this text needs to be
> updated when the situation changes.
>
> v6: Add a sentence why mesa will give the most meaningful review on gl
> stuff - it's a very active project with lots of developers.
>
> Acked-by: Dave Airlie <[e-mail]> (v4)
> Acked-by: Eric Anholt <[e-mail]> (v4)
> Acked-by: Alex Deucher <[e-mail]> (v5)
> Acked-by: Sean Paul <[e-mail]> (v5)
> Acked-by: Kenneth Graunke <[e-mail]> (v5)
> Acked-by: Karol Herbst <[e-mail]> (v5)
> Acked-by: Rob Clark <[e-mail]>
> Acked-by: Jérôme Glisse <[e-mail]>
> Acked-by: Bas Nieuwenhuizen <[e-mail]>
> Acked-by: Ben Skeggs <[e-mail]>
> Cc: Dave Airlie <[e-mail]>
> Cc: Eric Anholt <[e-mail]>
> Cc: Alex Deucher <[e-mail]>
> Cc: Sean Paul <[e-mail]>
> Cc: Kenneth Graunke <[e-mail]>
> Cc: Karol Herbst <[e-mail]>
> Cc: Rob Clark <[e-mail]>
> Cc: Jérôme Glisse <[e-mail]>
> Cc: Bas Nieuwenhuizen <[e-mail]>
> Cc: Ben Skeggs <[e-mail]>
> Signed-off-by: Daniel Vetter <[e-mail]>
> ---
> I chatted with a pile of people in private, and there's clearly some
> solid support for this. But there's also some big concerns brought up
> by other people. The main one summed up is "what if everyone just
> ships vk, with a generic gl-on-vk like ANGLE?", but there's other
> concerns too.
>
> So all together I think this doesn't clear the bar of (almost)
> unanimous support which we need to make documentation actually help
> with clarifying what's expected. And if/when someone comes up with a
> more creative userspace approach for gl/vk we'll need to figure this
> all out with the time honored tradition of having a few massive
> threads on dri-devel :-)
>
> Hence this is more fyi as a guidance I guess, not a strict&hard rule.
> And I don't plan on merging this.
>
> Cheers, Daniel
> ---
>  Documentation/gpu/drm-uapi.rst | 25 +++++++++++++++++++++++++
>  1 file changed, 25 insertions(+)
>
> diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
> index c9fd23efd957..0f767cfd5db6 100644
> --- a/Documentation/gpu/drm-uapi.rst
> +++ b/Documentation/gpu/drm-uapi.rst
> @@ -105,6 +105,31 @@ is already rather painful for the DRM subsystem, with multiple different uAPIs
>  for the same thing co-existing. If we add a few more complete mistakes into the
>  mix every year it would be entirely unmanageable.
>
> +Below some clarifications what this means for specific areas in DRM.
> +
> +Compute&Rendering Userspace
> +---------------------------
> +
> +Userspace API for enabling compute and rendering blocks which are capable of at
> +least supporting one of the OpenGL or OpenGL ES standards from Khronos need to
> +be enabled in the upstream `Mesa3D project<https://www.mesa3d.org/>`.
> +
> +Mesa3D is the canonical upstream for these areas because it is a fully
> +compliant, performant and cross-vendor implementation that supports all kernel
> +drivers in DRM. It is also an active project with plenty of developers who
> +can perform meaningful review. It is therefore the best platform to validate
> +userspace API and especially make sure that cross-vendor interoperation is
> +assured.
> +
> +Other userspace is only admissible if exposing a given feature through OpenGL or
> +OpenGL ES would result in a technically unsound design, incomplete driver or
> +an implementation which isn't useful in real world usage.
> +
> +Other areas, like media codec, which Mesa3D supports for just some drivers, but
> +isn't the clear universal choice, are excluded from this policy. Driver teams
> +are still encourage to aim for shared, cross-vendor infrastructure in userspace
> +as much as possible.
> +
>  .. _drm_render_node:
>
>  Render nodes
> --
> 2.20.1
>
> _______________________________________________
> dri-devel mailing list
> [e-mail]
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

Daniel Vetter April 24, 2019, 2:36 p.m. UTC | #3

On Wed, Apr 24, 2019 at 4:28 PM Daniel Vetter <[e-mail]> wrote:
>
> On Wed, Apr 24, 2019 at 4:24 PM Zhou, David(ChunMing)
> <[e-mail]> wrote:
> > Will linux be only mesa-linux? I thought linux is an  open linux.
> > Which will impact our opengl/amdvlk(MIT open source), not sure Rocm:
> > 1. how to deal with one uapi that opengl/amdvlk needs but mesa dont need? reject?
> > 2. one hw feature that opengl/amdvlk developers work on that but no mesa developers work on, cannot upstream as well?
> >
> > I think above two would easily happen, because there are many employees working on company project with many customer kinds of reqiurements, but mesa not.
>
> Well those are the questions I tried to have a clear answer for, to
> avoid confusion, but looks like the agreement isn't perfect. But
> there's pretty clear favour towards cross vendor userspace that's
> collaboratively and openly developed like mesa. So whenever one of the
> above cases you bring up happen we'll get to have a big thread on
> dri-devel I guess.

Aside, I think there's a pretty huge difference between rocm and
amdvlk. rocm is developed openly and all that, the one nit there is is
that it's not cross vendor. But then, there is no other vendor really
(but amd still controls it all despite the usual "totally an open
standard" lipstick in the marketing material). amdvlk otoh is open
source in the narrowest legal sense only, and nothing else. And yes
intel has some equally bad projects on the openess metric too with
some of the more recent-ish changes in the userspace stack.
-Daniel

> -Daniel
>
>
> > -David
> >
> > -------- Original Message --------
> > Subject: [PATCH] gpu/docs: Clarify what userspace means for gl
> > From: Daniel Vetter
> > To: DRI Development ,Mesa Dev
> > CC: Jérôme Glisse ,Daniel Vetter ,Karol Herbst ,Kenneth Graunke ,Ben Skeggs ,Daniel Vetter ,Sean Paul
> >
> > Clear rules avoid arguing.
> >
> > Note that this just aims to document current expectations. If that
> > shifts (e.g. because gl isn't the main api anymore, replaced by vk),
> > then we need to update this text.
> >
> > I think it'd be good to have an equally solid list on the kms side.
> > But kms is much more meant to be a standard, and the list of userspace
> > projects we've accepted in the past is constantly shifting and
> > adjusting. So I figured I'll leave that as an exercise for later on.
> >
> > v2: Try to clarify that we don't want a mesa driver just for mesa's
> > sake, and more clearly exclude anything that just doesn't make sense
> > technically.  Example would be a compute driver that makes sense to be
> > merged into drm (for kernel side code-sharing), but where the intended
> > use is some single-source CUDA-style compute without ever bothering
> > about any of the 3D/rendering side baggage that comes with gl/vk.
> >
> > v3: Drop vulkan for now, the situation there isn't as obviously
> > clear-cut as on the gl side, and I don't want to tank this idea on a
> > hot discussion about vk and mesa. Plus I think once we have 1-2 more
> > vk drivers in mesa the situation on the vk side is clear-cut too, and
> > we can do a follow-up patch to add vk to the list where we expect the
> > userspace to be in upstream mesa. That's would give nice precedence to
> > make it clear that this isn't cast in stone, but meant to reflect
> > reality and should be adjusted as needed.
> >
> > v4: Fix typo.
> >
> > v5: Add a note to the commit message that this text needs to be
> > updated when the situation changes.
> >
> > v6: Add a sentence why mesa will give the most meaningful review on gl
> > stuff - it's a very active project with lots of developers.
> >
> > Acked-by: Dave Airlie <[e-mail]> (v4)
> > Acked-by: Eric Anholt <[e-mail]> (v4)
> > Acked-by: Alex Deucher <[e-mail]> (v5)
> > Acked-by: Sean Paul <[e-mail]> (v5)
> > Acked-by: Kenneth Graunke <[e-mail]> (v5)
> > Acked-by: Karol Herbst <[e-mail]> (v5)
> > Acked-by: Rob Clark <[e-mail]>
> > Acked-by: Jérôme Glisse <[e-mail]>
> > Acked-by: Bas Nieuwenhuizen <[e-mail]>
> > Acked-by: Ben Skeggs <[e-mail]>
> > Cc: Dave Airlie <[e-mail]>
> > Cc: Eric Anholt <[e-mail]>
> > Cc: Alex Deucher <[e-mail]>
> > Cc: Sean Paul <[e-mail]>
> > Cc: Kenneth Graunke <[e-mail]>
> > Cc: Karol Herbst <[e-mail]>
> > Cc: Rob Clark <[e-mail]>
> > Cc: Jérôme Glisse <[e-mail]>
> > Cc: Bas Nieuwenhuizen <[e-mail]>
> > Cc: Ben Skeggs <[e-mail]>
> > Signed-off-by: Daniel Vetter <[e-mail]>
> > ---
> > I chatted with a pile of people in private, and there's clearly some
> > solid support for this. But there's also some big concerns brought up
> > by other people. The main one summed up is "what if everyone just
> > ships vk, with a generic gl-on-vk like ANGLE?", but there's other
> > concerns too.
> >
> > So all together I think this doesn't clear the bar of (almost)
> > unanimous support which we need to make documentation actually help
> > with clarifying what's expected. And if/when someone comes up with a
> > more creative userspace approach for gl/vk we'll need to figure this
> > all out with the time honored tradition of having a few massive
> > threads on dri-devel :-)
> >
> > Hence this is more fyi as a guidance I guess, not a strict&hard rule.
> > And I don't plan on merging this.
> >
> > Cheers, Daniel
> > ---
> >  Documentation/gpu/drm-uapi.rst | 25 +++++++++++++++++++++++++
> >  1 file changed, 25 insertions(+)
> >
> > diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
> > index c9fd23efd957..0f767cfd5db6 100644
> > --- a/Documentation/gpu/drm-uapi.rst
> > +++ b/Documentation/gpu/drm-uapi.rst
> > @@ -105,6 +105,31 @@ is already rather painful for the DRM subsystem, with multiple different uAPIs
> >  for the same thing co-existing. If we add a few more complete mistakes into the
> >  mix every year it would be entirely unmanageable.
> >
> > +Below some clarifications what this means for specific areas in DRM.
> > +
> > +Compute&Rendering Userspace
> > +---------------------------
> > +
> > +Userspace API for enabling compute and rendering blocks which are capable of at
> > +least supporting one of the OpenGL or OpenGL ES standards from Khronos need to
> > +be enabled in the upstream `Mesa3D project<https://www.mesa3d.org/>`.
> > +
> > +Mesa3D is the canonical upstream for these areas because it is a fully
> > +compliant, performant and cross-vendor implementation that supports all kernel
> > +drivers in DRM. It is also an active project with plenty of developers who
> > +can perform meaningful review. It is therefore the best platform to validate
> > +userspace API and especially make sure that cross-vendor interoperation is
> > +assured.
> > +
> > +Other userspace is only admissible if exposing a given feature through OpenGL or
> > +OpenGL ES would result in a technically unsound design, incomplete driver or
> > +an implementation which isn't useful in real world usage.
> > +
> > +Other areas, like media codec, which Mesa3D supports for just some drivers, but
> > +isn't the clear universal choice, are excluded from this policy. Driver teams
> > +are still encourage to aim for shared, cross-vendor infrastructure in userspace
> > +as much as possible.
> > +
> >  .. _drm_render_node:
> >
> >  Render nodes
> > --
> > 2.20.1
> >
> > _______________________________________________
> > dri-devel mailing list
> > [e-mail]
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> [phone] - http://blog.ffwll.ch

Chunming Zhou April 24, 2019, 2:57 p.m. UTC | #4

在 2019/4/24 22:36, Daniel Vetter 写道:
> On Wed, Apr 24, 2019 at 4:28 PM Daniel Vetter <[e-mail]> wrote:
>> On Wed, Apr 24, 2019 at 4:24 PM Zhou, David(ChunMing)
>> <[e-mail]> wrote:
>>> Will linux be only mesa-linux? I thought linux is an  open linux.
>>> Which will impact our opengl/amdvlk(MIT open source), not sure Rocm:
>>> 1. how to deal with one uapi that opengl/amdvlk needs but mesa dont need? reject?
>>> 2. one hw feature that opengl/amdvlk developers work on that but no mesa developers work on, cannot upstream as well?
>>>
>>> I think above two would easily happen, because there are many employees working on company project with many customer kinds of reqiurements, but mesa not.
>> Well those are the questions I tried to have a clear answer for, to
>> avoid confusion, but looks like the agreement isn't perfect. But
>> there's pretty clear favour towards cross vendor userspace that's
>> collaboratively and openly developed like mesa. So whenever one of the
>> above cases you bring up happen we'll get to have a big thread on
>> dri-devel I guess.
> Aside, I think there's a pretty huge difference between rocm and
> amdvlk. rocm is developed openly and all that, the one nit there is is
> that it's not cross vendor. But then, there is no other vendor really
> (but amd still controls it all despite the usual "totally an open
> standard" lipstick in the marketing material). amdvlk otoh is open
> source in the narrowest legal sense only, and nothing else.

Do you mean if amdvlk is developed openly like Rocm does, amdvlk will be 
able to drive uapi without mesa admissable?


-David

>   And yes
> intel has some equally bad projects on the openess metric too with
> some of the more recent-ish changes in the userspace stack.
> -Daniel
>
>> -Daniel
>>
>>
>>> -David
>>>
>>> -------- Original Message --------
>>> Subject: [PATCH] gpu/docs: Clarify what userspace means for gl
>>> From: Daniel Vetter
>>> To: DRI Development ,Mesa Dev
>>> CC: Jérôme Glisse ,Daniel Vetter ,Karol Herbst ,Kenneth Graunke ,Ben Skeggs ,Daniel Vetter ,Sean Paul
>>>
>>> Clear rules avoid arguing.
>>>
>>> Note that this just aims to document current expectations. If that
>>> shifts (e.g. because gl isn't the main api anymore, replaced by vk),
>>> then we need to update this text.
>>>
>>> I think it'd be good to have an equally solid list on the kms side.
>>> But kms is much more meant to be a standard, and the list of userspace
>>> projects we've accepted in the past is constantly shifting and
>>> adjusting. So I figured I'll leave that as an exercise for later on.
>>>
>>> v2: Try to clarify that we don't want a mesa driver just for mesa's
>>> sake, and more clearly exclude anything that just doesn't make sense
>>> technically.  Example would be a compute driver that makes sense to be
>>> merged into drm (for kernel side code-sharing), but where the intended
>>> use is some single-source CUDA-style compute without ever bothering
>>> about any of the 3D/rendering side baggage that comes with gl/vk.
>>>
>>> v3: Drop vulkan for now, the situation there isn't as obviously
>>> clear-cut as on the gl side, and I don't want to tank this idea on a
>>> hot discussion about vk and mesa. Plus I think once we have 1-2 more
>>> vk drivers in mesa the situation on the vk side is clear-cut too, and
>>> we can do a follow-up patch to add vk to the list where we expect the
>>> userspace to be in upstream mesa. That's would give nice precedence to
>>> make it clear that this isn't cast in stone, but meant to reflect
>>> reality and should be adjusted as needed.
>>>
>>> v4: Fix typo.
>>>
>>> v5: Add a note to the commit message that this text needs to be
>>> updated when the situation changes.
>>>
>>> v6: Add a sentence why mesa will give the most meaningful review on gl
>>> stuff - it's a very active project with lots of developers.
>>>
>>> Acked-by: Dave Airlie <[e-mail]> (v4)
>>> Acked-by: Eric Anholt <[e-mail]> (v4)
>>> Acked-by: Alex Deucher <[e-mail]> (v5)
>>> Acked-by: Sean Paul <[e-mail]> (v5)
>>> Acked-by: Kenneth Graunke <[e-mail]> (v5)
>>> Acked-by: Karol Herbst <[e-mail]> (v5)
>>> Acked-by: Rob Clark <[e-mail]>
>>> Acked-by: Jérôme Glisse <[e-mail]>
>>> Acked-by: Bas Nieuwenhuizen <[e-mail]>
>>> Acked-by: Ben Skeggs <[e-mail]>
>>> Cc: Dave Airlie <[e-mail]>
>>> Cc: Eric Anholt <[e-mail]>
>>> Cc: Alex Deucher <[e-mail]>
>>> Cc: Sean Paul <[e-mail]>
>>> Cc: Kenneth Graunke <[e-mail]>
>>> Cc: Karol Herbst <[e-mail]>
>>> Cc: Rob Clark <[e-mail]>
>>> Cc: Jérôme Glisse <[e-mail]>
>>> Cc: Bas Nieuwenhuizen <[e-mail]>
>>> Cc: Ben Skeggs <[e-mail]>
>>> Signed-off-by: Daniel Vetter <[e-mail]>
>>> ---
>>> I chatted with a pile of people in private, and there's clearly some
>>> solid support for this. But there's also some big concerns brought up
>>> by other people. The main one summed up is "what if everyone just
>>> ships vk, with a generic gl-on-vk like ANGLE?", but there's other
>>> concerns too.
>>>
>>> So all together I think this doesn't clear the bar of (almost)
>>> unanimous support which we need to make documentation actually help
>>> with clarifying what's expected. And if/when someone comes up with a
>>> more creative userspace approach for gl/vk we'll need to figure this
>>> all out with the time honored tradition of having a few massive
>>> threads on dri-devel :-)
>>>
>>> Hence this is more fyi as a guidance I guess, not a strict&hard rule.
>>> And I don't plan on merging this.
>>>
>>> Cheers, Daniel
>>> ---
>>>   Documentation/gpu/drm-uapi.rst | 25 +++++++++++++++++++++++++
>>>   1 file changed, 25 insertions(+)
>>>
>>> diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
>>> index c9fd23efd957..0f767cfd5db6 100644
>>> --- a/Documentation/gpu/drm-uapi.rst
>>> +++ b/Documentation/gpu/drm-uapi.rst
>>> @@ -105,6 +105,31 @@ is already rather painful for the DRM subsystem, with multiple different uAPIs
>>>   for the same thing co-existing. If we add a few more complete mistakes into the
>>>   mix every year it would be entirely unmanageable.
>>>
>>> +Below some clarifications what this means for specific areas in DRM.
>>> +
>>> +Compute&Rendering Userspace
>>> +---------------------------
>>> +
>>> +Userspace API for enabling compute and rendering blocks which are capable of at
>>> +least supporting one of the OpenGL or OpenGL ES standards from Khronos need to
>>> +be enabled in the upstream `Mesa3D project<https://www.mesa3d.org/>`.
>>> +
>>> +Mesa3D is the canonical upstream for these areas because it is a fully
>>> +compliant, performant and cross-vendor implementation that supports all kernel
>>> +drivers in DRM. It is also an active project with plenty of developers who
>>> +can perform meaningful review. It is therefore the best platform to validate
>>> +userspace API and especially make sure that cross-vendor interoperation is
>>> +assured.
>>> +
>>> +Other userspace is only admissible if exposing a given feature through OpenGL or
>>> +OpenGL ES would result in a technically unsound design, incomplete driver or
>>> +an implementation which isn't useful in real world usage.
>>> +
>>> +Other areas, like media codec, which Mesa3D supports for just some drivers, but
>>> +isn't the clear universal choice, are excluded from this policy. Driver teams
>>> +are still encourage to aim for shared, cross-vendor infrastructure in userspace
>>> +as much as possible.
>>> +
>>>   .. _drm_render_node:
>>>
>>>   Render nodes
>>> --
>>> 2.20.1
>>>
>>> _______________________________________________
>>> dri-devel mailing list
>>> [e-mail]
>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>>
>> --
>> Daniel Vetter
>> Software Engineer, Intel Corporation
>> [phone] - http://blog.ffwll.ch
>
>

Eric Anholt April 24, 2019, 7:22 p.m. UTC | #5

"Zhou, David(ChunMing)" <[e-mail]> writes:

> Will linux be only mesa-linux? I thought linux is an  open linux.
> Which will impact our opengl/amdvlk(MIT open source), not sure Rocm:
> 1. how to deal with one uapi that opengl/amdvlk needs but mesa dont need? reject?
> 2. one hw feature that opengl/amdvlk developers work on that but no mesa
> developers work on, cannot upstream as well?

I believe these questions are already covered by

"+Other userspace is only admissible if exposing a given feature through OpenGL
or
+OpenGL ES would result in a technically unsound design, incomplete driver or
+an implementation which isn't useful in real world usage."

If OpenGL needs the interface, then you need a Mesa implementation.
It's time for you to work with the community to build that or get it
built.  Or, in AMD's case, work with the Mesa developers that you
already employ.

If OpenGL doesn't need it, but Vulkan needs it, then we don't have a
clear policy in place, and this patch doesn't change that.  I would
personally say that AMDVLK doesn't qualify given that as far as I know
there is not open review of proposed patches to the project as they're
being developed.

Chunming Zhou April 25, 2019, 3:28 a.m. UTC | #6

On 2019年04月25日 03:22, Eric Anholt wrote:
> "Zhou, David(ChunMing)" <[e-mail]> writes:
>
>> Will linux be only mesa-linux? I thought linux is an  open linux.
>> Which will impact our opengl/amdvlk(MIT open source), not sure Rocm:
>> 1. how to deal with one uapi that opengl/amdvlk needs but mesa dont need? reject?
>> 2. one hw feature that opengl/amdvlk developers work on that but no mesa
>> developers work on, cannot upstream as well?
> I believe these questions are already covered by
>
> "+Other userspace is only admissible if exposing a given feature through OpenGL
> or
> +OpenGL ES would result in a technically unsound design, incomplete driver or
> +an implementation which isn't useful in real world usage."
>
> If OpenGL needs the interface, then you need a Mesa implementation.
> It's time for you to work with the community to build that or get it
> built.  Or, in AMD's case, work with the Mesa developers that you
> already employ.
>
> If OpenGL doesn't need it, but Vulkan needs it, then we don't have a
> clear policy in place, and this patch doesn't change that.  I would
> personally say that AMDVLK doesn't qualify given that as far as I know
> there is not open review of proposed patches to the project as they're
> being developed.
Can I understand what you mean is, as soon as the stack is openly 
developed, then which will be able to drive new UAPI?

-David

Daniel Vetter April 25, 2019, 7:43 a.m. UTC | #7

On Thu, Apr 25, 2019 at 11:28:40AM +0800, zhoucm1 wrote:
> 
> 
> On 2019年04月25日 03:22, Eric Anholt wrote:
> > "Zhou, David(ChunMing)" <[e-mail]> writes:
> > 
> > > Will linux be only mesa-linux? I thought linux is an  open linux.
> > > Which will impact our opengl/amdvlk(MIT open source), not sure Rocm:
> > > 1. how to deal with one uapi that opengl/amdvlk needs but mesa dont need? reject?
> > > 2. one hw feature that opengl/amdvlk developers work on that but no mesa
> > > developers work on, cannot upstream as well?
> > I believe these questions are already covered by
> > 
> > "+Other userspace is only admissible if exposing a given feature through OpenGL
> > or
> > +OpenGL ES would result in a technically unsound design, incomplete driver or
> > +an implementation which isn't useful in real world usage."
> > 
> > If OpenGL needs the interface, then you need a Mesa implementation.
> > It's time for you to work with the community to build that or get it
> > built.  Or, in AMD's case, work with the Mesa developers that you
> > already employ.
> > 
> > If OpenGL doesn't need it, but Vulkan needs it, then we don't have a
> > clear policy in place, and this patch doesn't change that.  I would
> > personally say that AMDVLK doesn't qualify given that as far as I know
> > there is not open review of proposed patches to the project as they're
> > being developed.
> Can I understand what you mean is, as soon as the stack is openly developed,
> then which will be able to drive new UAPI?

I think the only clear thing here is that the answer is complicated, and
need to be decided on a case by case basis. That's what I tried to clarify
with my patch, but I think there's not enough clearly defined common
ground. So it'll stay complicated.
-Daniel

Patch

diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
index c9fd23efd957..0f767cfd5db6 100644
--- a/Documentation/gpu/drm-uapi.rst
+++ b/Documentation/gpu/drm-uapi.rst
@@ -105,6 +105,31 @@  is already rather painful for the DRM subsystem, with multiple different uAPIs
 for the same thing co-existing. If we add a few more complete mistakes into the
 mix every year it would be entirely unmanageable.
 
+Below some clarifications what this means for specific areas in DRM.
+
+Compute&Rendering Userspace
+---------------------------
+
+Userspace API for enabling compute and rendering blocks which are capable of at
+least supporting one of the OpenGL or OpenGL ES standards from Khronos need to
+be enabled in the upstream `Mesa3D project<https://www.mesa3d.org/>`.
+
+Mesa3D is the canonical upstream for these areas because it is a fully
+compliant, performant and cross-vendor implementation that supports all kernel
+drivers in DRM. It is also an active project with plenty of developers who
+can perform meaningful review. It is therefore the best platform to validate
+userspace API and especially make sure that cross-vendor interoperation is
+assured.
+
+Other userspace is only admissible if exposing a given feature through OpenGL or
+OpenGL ES would result in a technically unsound design, incomplete driver or
+an implementation which isn't useful in real world usage.
+
+Other areas, like media codec, which Mesa3D supports for just some drivers, but
+isn't the clear universal choice, are excluded from this policy. Driver teams
+are still encourage to aim for shared, cross-vendor infrastructure in userspace
+as much as possible.
+
 .. _drm_render_node:
 
 Render nodes