[Shouldn't send mails before coffee kicks in, some things got lost below] On Fri, Feb 15, 2019 at 10:20 AM Daniel Vetter <daniel@xxxxxxxx> wrote: > > On Thu, Feb 14, 2019 at 05:47:06PM -0500, Rob Clark wrote: > > On Thu, Feb 14, 2019 at 4:00 AM Daniel Vetter <daniel.vetter@xxxxxxxx> wrote: > > > > > > Clear rules avoid arguing. > > > > > > 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. > > > > > > Signed-off-by: Daniel Vetter <daniel.vetter@xxxxxxxxx> > > > --- > > > Hi all, > > > > > > I discussed this a bit with a few people over the past few months (I > > > think), to get a feel for where the consensus might be. Goal here isn't > > > anything aspirational (like with the recent igt patch), but just > > > documented current expectations, so that there's no confusion or companies > > > with failed projects that had no reason to fail. Same reasons really like > > > for the patch to document open source userspace requirements a few years > > > ago, that one is still extremely useful. > > > > > > For obvious reasons needs solid support from both mesa and kernel people, > > > or it won't land. > > > > > > Thoughts, hot takes, comments, also acks all very much welcome. > > > > > > Thanks, Daniel > > > --- > > > Documentation/gpu/drm-uapi.rst | 23 +++++++++++++++++++++++ > > > 1 file changed, 23 insertions(+) > > > > > > diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst > > > index c9fd23efd957..79f78c3fa458 100644 > > > --- a/Documentation/gpu/drm-uapi.rst > > > +++ b/Documentation/gpu/drm-uapi.rst > > > @@ -105,6 +105,29 @@ 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 therefore the best platform to validate userspace API and > > > +especially make sure that cross-vendor interoperation is assured. > > > + > > > > I'm not entirely sure how I feel about *requiring* a mesa driver. I'd > > defn *very strongly recommend* a mesa driver, and preferably a gallium > > driver at that. But the current blurb here doesn't capture what I > > think is the most important reason for that: I'm already familiar with > > the core mesa and gallium APIs, which will make it far more easy for > > me to review the userspace driver code, compared to something which is > > an entirely different codebase. > > If we put "strongly recommend" and then a vendor submits a driver with > their own gl, we'll have endless amounts of arguing, and I think in the > end that driver won't land until anyway, so all wasted. This is a big ... until it's converted to be a mesa driver ... > difference compared to the recent igt requirement, since we've merged tons > of features without igts, and because of various reasons, we'll continue > to accept justified exceptions. If all we can agree on is "strongly > recommend" then I think we don't need to document that, and will just keep > suffering through the inevitable arguing :-) > > I agree that it should be a gallium driver, but the kernel isn't really > the right place to document how a mesa driver should look like. > > > In any case, I think it is important that people look at the open src > > userspace, not that it just exists. Upstreaming to mesa is a good way > > to make sure that happens. > > We already require (further up in this doc) that people push their open > source into the canonical upstream, to prevent dodging real review. Meant to add that this here just aims to clarify the existing expectations. And hopefully reduces arguing (most of which happens internally within vendors, and it's a drain). -Daniel > > > +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 > > > +otherwise 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. > > > > a compute-only driver might fall into the same category (although I'd > > prefer it if that were not the case).. > > That's what the above paragraph is for - compute-only hw that's shoehorned > into gl is just not good design, so not in scope. I added this line here > because mesa also has api support beyond rendering/compute, just to make > it clear that's even more out of scope. > > And I agree it'd be nice if more would be standardized in mesa, but right > now I think it's just gl as the clear consensus. At least that's what I > got from chatting with people a bit. > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
