[Mesa-dev] [PATCH v2 1/4] drm/i915/uapi: fix kernel doc warnings

2021-04-19 Thread Matthew Auld
Fix the cases where it is almost already valid kernel doc, for the others just nerf the warnings for now. Signed-off-by: Matthew Auld Cc: Joonas Lahtinen Cc: Jordan Justen Cc: Daniel Vetter Cc: Kenneth Graunke Cc: Jason Ekstrand Cc: Dave Airlie Cc: dri-de...@lists.freedesktop.org Cc:

[Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

2021-04-19 Thread Marek Olšák
Hi, This is our initial proposal for explicit fences everywhere and new memory management that doesn't use BO fences. It's a redesign of how Linux graphics drivers work, and it can coexist with what we have now. *1. Introduction* (skip this if you are already sold on explicit fences) The

[Mesa-dev] [PATCH v2 2/4] drm/doc: add section for driver uAPI

2021-04-19 Thread Matthew Auld
Add section for drm/i915 uAPI and pull in i915_drm.h. Suggested-by: Daniel Vetter Signed-off-by: Matthew Auld Cc: Joonas Lahtinen Cc: Jordan Justen Cc: Daniel Vetter Cc: Kenneth Graunke Cc: Jason Ekstrand Cc: Dave Airlie Cc: dri-de...@lists.freedesktop.org Cc:

[Mesa-dev] [PATCH v2 3/4] drm/i915/uapi: convert i915_user_extension to kernel doc

2021-04-19 Thread Matthew Auld
Add some example usage for the extension chaining also, which is quite nifty. v2: (Daniel) - clarify that the name is just some integer, also document that the name space is not global v3: prefer kernel-doc references for structs Suggested-by: Daniel Vetter Signed-off-by: Matthew Auld

[Mesa-dev] [PATCH v2 4/4] drm/i915/uapi: convert i915_query and friend to kernel doc

2021-04-19 Thread Matthew Auld
Add a note about the two-step process. v2(Tvrtko): - Also document the other method of just passing in a buffer which is large enough, which avoids two ioctl calls. Can make sense for smaller query items. v3: prefer kernel-doc references for structs and members Suggested-by: Daniel

Re: [Mesa-dev] [PATCH v3 4/4] drm/doc/rfc: i915 DG1 uAPI

2021-04-19 Thread Matthew Auld
On 16/04/2021 17:38, Jason Ekstrand wrote: On Thu, Apr 15, 2021 at 11:04 AM Matthew Auld wrote: Add an entry for the new uAPI needed for DG1. v2(Daniel): - include the overall upstreaming plan - add a note for mmap, there are differences here for TTM vs i915 - bunch of other

Re: [Mesa-dev] [PATCH v3 4/4] drm/doc/rfc: i915 DG1 uAPI

2021-04-19 Thread Jason Ekstrand
On Mon, Apr 19, 2021 at 7:02 AM Matthew Auld wrote: > > On 16/04/2021 17:38, Jason Ekstrand wrote: > > On Thu, Apr 15, 2021 at 11:04 AM Matthew Auld > > wrote: > >> > >> Add an entry for the new uAPI needed for DG1. > >> > >> v2(Daniel): > >>- include the overall upstreaming plan > >>-

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

2021-04-19 Thread Jason Ekstrand
Not going to comment on everything on the first pass... On Mon, Apr 19, 2021 at 5:48 AM Marek Olšák wrote: > > Hi, > > This is our initial proposal for explicit fences everywhere and new memory > management that doesn't use BO fences. It's a redesign of how Linux graphics > drivers work, and

[Mesa-dev] [PATCH v4] drm/doc/rfc: i915 DG1 uAPI

2021-04-19 Thread Matthew Auld
Add an entry for the new uAPI needed for DG1. Also add the overall upstream plan, including some notes for the TTM conversion. v2(Daniel): - include the overall upstreaming plan - add a note for mmap, there are differences here for TTM vs i915 - bunch of other suggestions from Daniel v3:

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

2021-04-19 Thread Marek Olšák
We already don't have accurate BO fences in some cases. Instead, BOs can have fences which are equal to the last seen command buffer for each queue. It's practically the same as if the kernel had no visibility into command submissions and just added a fence into all queues when it needed to wait