Re: [Mesa-dev] [PATCH 1/9] drm/doc/rfc: i915 DG1 uAPI
> -Original Message- > From: Auld, Matthew > Sent: Monday, April 26, 2021 2:39 AM > To: intel-...@lists.freedesktop.org > Cc: Joonas Lahtinen ; Thomas Hellström > ; Ceraolo Spurio, Daniele > ; Lionel Landwerlin > ; Bloomfield, Jon > ; Justen, Jordan L ; > Vetter, Daniel ; Kenneth Graunke > ; Jason Ekstrand ; Dave > Airlie ; dri-de...@lists.freedesktop.org; mesa- > d...@lists.freedesktop.org; Daniel Vetter ; Dave > Airlie > Subject: [PATCH 1/9] drm/doc/rfc: i915 DG1 uAPI > > 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: > (Daniel) > - add a note for set/get caching stuff > - add some more docs for existing query and extensions stuff > - add an actual code example for regions query > - bunch of other stuff > (Jason) > - uAPI change(!): > - try a simpler design with the placements extension > - rather than have a generic setparam which can cover multiple > use cases, have each extension be responsible for one thing > only > v4: > (Daniel) > - add some more notes for ttm conversion > - bunch of other stuff > (Jason) > - uAPI change(!): > - drop all the extra rsvd members for the region_query and > region_info, just keep the bare minimum needed for padding > > Signed-off-by: Matthew Auld > Cc: Joonas Lahtinen > Cc: Thomas Hellström > Cc: Daniele Ceraolo Spurio > Cc: Lionel Landwerlin > Cc: Jon Bloomfield > Cc: Jordan Justen > Cc: Daniel Vetter > Cc: Kenneth Graunke > Cc: Jason Ekstrand > Cc: Dave Airlie > Cc: dri-de...@lists.freedesktop.org > Cc: mesa-dev@lists.freedesktop.org > Acked-by: Daniel Vetter > Acked-by: Dave Airlie > --- Acked-by: Jon Bloomfield ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 1/9] drm/doc/rfc: i915 DG1 uAPI
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:
(Daniel)
- add a note for set/get caching stuff
- add some more docs for existing query and extensions stuff
- add an actual code example for regions query
- bunch of other stuff
(Jason)
- uAPI change(!):
- try a simpler design with the placements extension
- rather than have a generic setparam which can cover multiple
use cases, have each extension be responsible for one thing
only
v4:
(Daniel)
- add some more notes for ttm conversion
- bunch of other stuff
(Jason)
- uAPI change(!):
- drop all the extra rsvd members for the region_query and
region_info, just keep the bare minimum needed for padding
v5:
(Jason)
- for the upstream plan, add a requirement that we send the uAPI bits
again for final sign off before turning it on for real
- document how we intend to extend the rsvd bits for the region query
(Kenneth)
- improve the comment for the smem+lmem mmap mode and caching
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Thomas Hellström
Cc: Daniele Ceraolo Spurio
Cc: Lionel Landwerlin
Cc: Jon Bloomfield
Cc: Jordan Justen
Cc: Daniel Vetter
Cc: Kenneth Graunke
Cc: Jason Ekstrand
Cc: Dave Airlie
Cc: dri-de...@lists.freedesktop.org
Cc: mesa-dev@lists.freedesktop.org
Acked-by: Daniel Vetter
Acked-by: Dave Airlie
Acked-by: Kenneth Graunke
Acked-by: Jon Bloomfield
---
Documentation/gpu/rfc/i915_gem_lmem.h | 237
Documentation/gpu/rfc/i915_gem_lmem.rst | 131 +
Documentation/gpu/rfc/index.rst | 4 +
3 files changed, 372 insertions(+)
create mode 100644 Documentation/gpu/rfc/i915_gem_lmem.h
create mode 100644 Documentation/gpu/rfc/i915_gem_lmem.rst
diff --git a/Documentation/gpu/rfc/i915_gem_lmem.h
b/Documentation/gpu/rfc/i915_gem_lmem.h
new file mode 100644
index ..712a85f932ec
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_gem_lmem.h
@@ -0,0 +1,237 @@
+/**
+ * enum drm_i915_gem_memory_class - Supported memory classes
+ */
+enum drm_i915_gem_memory_class {
+ /** @I915_MEMORY_CLASS_SYSTEM: System memory */
+ I915_MEMORY_CLASS_SYSTEM = 0,
+ /** @I915_MEMORY_CLASS_DEVICE: Device local-memory */
+ I915_MEMORY_CLASS_DEVICE,
+};
+
+/**
+ * struct drm_i915_gem_memory_class_instance - Identify particular memory
region
+ */
+struct drm_i915_gem_memory_class_instance {
+ /** @memory_class: See enum drm_i915_gem_memory_class */
+ __u16 memory_class;
+
+ /** @memory_instance: Which instance */
+ __u16 memory_instance;
+};
+
+/**
+ * struct drm_i915_memory_region_info - Describes one region as known to the
+ * driver.
+ *
+ * Note that we reserve some stuff here for potential future work. As an
example
+ * we might want expose the capabilities for a given region, which could
include
+ * things like if the region is CPU mappable/accessible, what are the supported
+ * mapping types etc.
+ *
+ * Note that to extend struct drm_i915_memory_region_info and struct
+ * drm_i915_query_memory_regions in the future the plan is to do the following:
+ *
+ * .. code-block:: C
+ *
+ * struct drm_i915_memory_region_info {
+ * struct drm_i915_gem_memory_class_instance region;
+ * union {
+ * __u32 rsvd0;
+ * __u32 new_thing1;
+ * };
+ * ...
+ * union {
+ * __u64 rsvd1[8];
+ * struct {
+ * __u64 new_thing2;
+ * __u64 new_thing3;
+ * ...
+ * };
+ * };
+ * };
+ *
+ * With this things should remain source compatible between versions for
+ * userspace, even as we add new fields.
+ *
+ * Note this is using both struct drm_i915_query_item and struct
drm_i915_query.
+ * For this new query we are adding the new query id
DRM_I915_QUERY_MEMORY_REGIONS
+ * at &drm_i915_query_item.query_id.
+ */
+struct drm_i915_memory_region_info {
+ /** @region: The class:instance pair encoding */
+ struct drm_i915_gem_memory_class_instance region;
+
+ /** @rsvd0: MBZ */
+ __u32 rsvd0;
+
+ /** @probed_size: Memory probed by the driver (-1 = unknown) */
+ __u64 probed_size;
+
+ /** @unallocated_size: Estimate of memory remaining (-1 = unknown) */
+ __u64 unallocated_size;
+
+ /** @rsvd1: MBZ */
+__u64 rsvd1[8];
+};
+
+/**
+ * struct drm_i915_query_memory_regions
+ *
+ * The region info query enumerates all regions known to the driver by filling
+ * in an array of struct drm_i915_memory_region_info structures.
+ *
+ * Example for getting the li
[Mesa-dev] [PATCH v2 2/9] drm/i915: mark stolen as private
In the next patch we want to expose the supported regions to userspace,
which can then be fed into the gem_create_ext placement extensions. For
now treat stolen memory as private from userspace pov.
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Thomas Hellström
Cc: Daniele Ceraolo Spurio
Cc: Lionel Landwerlin
Cc: Jon Bloomfield
Cc: Jordan Justen
Cc: Daniel Vetter
Cc: Kenneth Graunke
Cc: Jason Ekstrand
Cc: Dave Airlie
Cc: dri-de...@lists.freedesktop.org
Cc: mesa-dev@lists.freedesktop.org
Reviewed-by: Kenneth Graunke
---
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 4
drivers/gpu/drm/i915/intel_memory_region.h | 1 +
2 files changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
index e1a32672bbe8..293f640faa0a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
@@ -803,6 +803,8 @@ i915_gem_stolen_lmem_setup(struct drm_i915_private *i915)
intel_memory_region_set_name(mem, "stolen-local");
+ mem->private = true;
+
return mem;
}
@@ -821,6 +823,8 @@ i915_gem_stolen_smem_setup(struct drm_i915_private *i915)
intel_memory_region_set_name(mem, "stolen-system");
+ mem->private = true;
+
return mem;
}
diff --git a/drivers/gpu/drm/i915/intel_memory_region.h
b/drivers/gpu/drm/i915/intel_memory_region.h
index 4c8ec15af55f..942fc4f68764 100644
--- a/drivers/gpu/drm/i915/intel_memory_region.h
+++ b/drivers/gpu/drm/i915/intel_memory_region.h
@@ -86,6 +86,7 @@ struct intel_memory_region {
u16 instance;
enum intel_region_id id;
char name[16];
+ bool private; /* not for userspace */
struct list_head reserved;
--
2.26.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 3/9] drm/i915/query: Expose memory regions through the query uAPI
From: Abdiel Janulgue
Returns the available memory region areas supported by the HW.
v2(Daniel & Jason):
- Add some kernel-doc, including example usage.
- Drop all the extra rsvd
v3(Jason & Tvrtko)
- add back rsvd
Signed-off-by: Abdiel Janulgue
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Thomas Hellström
Cc: Daniele Ceraolo Spurio
Cc: Lionel Landwerlin
Cc: Jon Bloomfield
Cc: Jordan Justen
Cc: Daniel Vetter
Cc: Kenneth Graunke
Cc: Jason Ekstrand
Cc: Dave Airlie
Cc: dri-de...@lists.freedesktop.org
Cc: mesa-dev@lists.freedesktop.org
Reviewed-by: Kenneth Graunke
---
drivers/gpu/drm/i915/i915_query.c | 59 +
drivers/gpu/drm/i915/intel_memory_region.h | 8 +-
include/uapi/drm/i915_drm.h| 134 +
3 files changed, 196 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_query.c
b/drivers/gpu/drm/i915/i915_query.c
index fed337ad7b68..5e2b909827f4 100644
--- a/drivers/gpu/drm/i915/i915_query.c
+++ b/drivers/gpu/drm/i915/i915_query.c
@@ -419,11 +419,70 @@ static int query_perf_config(struct drm_i915_private
*i915,
}
}
+static int query_memregion_info(struct drm_i915_private *i915,
+ struct drm_i915_query_item *query_item)
+{
+ struct drm_i915_query_memory_regions __user *query_ptr =
+ u64_to_user_ptr(query_item->data_ptr);
+ struct drm_i915_memory_region_info __user *info_ptr =
+ &query_ptr->regions[0];
+ struct drm_i915_memory_region_info info = { };
+ struct drm_i915_query_memory_regions query;
+ struct intel_memory_region *mr;
+ u32 total_length;
+ int ret, id, i;
+
+ if (query_item->flags != 0)
+ return -EINVAL;
+
+ total_length = sizeof(query);
+ for_each_memory_region(mr, i915, id) {
+ if (mr->private)
+ continue;
+
+ total_length += sizeof(info);
+ }
+
+ ret = copy_query_item(&query, sizeof(query), total_length, query_item);
+ if (ret != 0)
+ return ret;
+
+ if (query.num_regions)
+ return -EINVAL;
+
+ for (i = 0; i < ARRAY_SIZE(query.rsvd); i++) {
+ if (query.rsvd[i])
+ return -EINVAL;
+ }
+
+ for_each_memory_region(mr, i915, id) {
+ if (mr->private)
+ continue;
+
+ info.region.memory_class = mr->type;
+ info.region.memory_instance = mr->instance;
+ info.probed_size = mr->total;
+ info.unallocated_size = mr->avail;
+
+ if (__copy_to_user(info_ptr, &info, sizeof(info)))
+ return -EFAULT;
+
+ query.num_regions++;
+ info_ptr++;
+ }
+
+ if (__copy_to_user(query_ptr, &query, sizeof(query)))
+ return -EFAULT;
+
+ return total_length;
+}
+
static int (* const i915_query_funcs[])(struct drm_i915_private *dev_priv,
struct drm_i915_query_item *query_item)
= {
query_topology_info,
query_engine_info,
query_perf_config,
+ query_memregion_info,
};
int i915_query_ioctl(struct drm_device *dev, void *data, struct drm_file *file)
diff --git a/drivers/gpu/drm/i915/intel_memory_region.h
b/drivers/gpu/drm/i915/intel_memory_region.h
index 942fc4f68764..7cd8e3d66a7f 100644
--- a/drivers/gpu/drm/i915/intel_memory_region.h
+++ b/drivers/gpu/drm/i915/intel_memory_region.h
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include "i915_buddy.h"
@@ -19,12 +20,9 @@ struct drm_i915_gem_object;
struct intel_memory_region;
struct sg_table;
-/**
- * Base memory type
- */
enum intel_memory_type {
- INTEL_MEMORY_SYSTEM = 0,
- INTEL_MEMORY_LOCAL,
+ INTEL_MEMORY_SYSTEM = I915_MEMORY_CLASS_SYSTEM,
+ INTEL_MEMORY_LOCAL = I915_MEMORY_CLASS_DEVICE,
INTEL_MEMORY_STOLEN_SYSTEM,
INTEL_MEMORY_STOLEN_LOCAL,
};
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 6a34243a7646..57c376680a60 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -2230,6 +2230,7 @@ struct drm_i915_query_item {
#define DRM_I915_QUERY_TOPOLOGY_INFO1
#define DRM_I915_QUERY_ENGINE_INFO 2
#define DRM_I915_QUERY_PERF_CONFIG 3
+#define DRM_I915_QUERY_MEMORY_REGIONS 4
/* Must be kept compact -- no holes and well documented */
/**
@@ -2464,6 +2465,139 @@ struct drm_i915_query_perf_config {
__u8 data[];
};
+/**
+ * enum drm_i915_gem_memory_class - Supported memory classes
+ */
+enum drm_i915_gem_memory_class {
+ /** @I915_MEMORY_CLASS_SYSTEM: System memory */
+ I915_MEMORY_CLASS_SYSTEM = 0,
+ /** @I915_MEMORY_CLASS_DEVICE: Device local-memory */
+ I915_MEMORY_CLASS_DEVICE,
+};
+
+/**
+ * struct drm_i915_gem_memory_class_instance - Identify particula
[Mesa-dev] [PATCH v2 4/9] drm/i915: rework gem_create flow for upcoming extensions
With the upcoming gem_create_ext we want to be able create a "vanilla"
object upfront and pass that directly to the extensions, before actually
initialising the object. Functionally this should be the same expect we
now feed the object into the lower-level region specific init_object.
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Thomas Hellström
Cc: Daniele Ceraolo Spurio
Cc: Lionel Landwerlin
Cc: Jon Bloomfield
Cc: Jordan Justen
Cc: Daniel Vetter
Cc: Kenneth Graunke
Cc: Jason Ekstrand
Cc: Dave Airlie
Cc: dri-de...@lists.freedesktop.org
Cc: mesa-dev@lists.freedesktop.org
Reviewed-by: Kenneth Graunke
---
drivers/gpu/drm/i915/gem/i915_gem_create.c | 92 +++---
1 file changed, 65 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c
b/drivers/gpu/drm/i915/gem/i915_gem_create.c
index 45d60e3d98e3..409226df0dd2 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_create.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_create.c
@@ -7,41 +7,51 @@
#include "gem/i915_gem_region.h"
#include "i915_drv.h"
+#include "i915_trace.h"
+
+static int i915_gem_publish(struct drm_i915_gem_object *obj,
+ struct drm_file *file,
+ u64 *size_p,
+ u32 *handle_p)
+{
+ u64 size = obj->base.size;
+ int ret;
+
+ ret = drm_gem_handle_create(file, &obj->base, handle_p);
+ /* drop reference from allocate - handle holds it now */
+ i915_gem_object_put(obj);
+ if (ret)
+ return ret;
+
+ *size_p = size;
+ return 0;
+}
static int
-i915_gem_create(struct drm_file *file,
- struct intel_memory_region *mr,
- u64 *size_p,
- u32 *handle_p)
+i915_gem_setup(struct drm_i915_gem_object *obj,
+ struct intel_memory_region *mr,
+ u64 size)
{
- struct drm_i915_gem_object *obj;
- u32 handle;
- u64 size;
int ret;
GEM_BUG_ON(!is_power_of_2(mr->min_page_size));
- size = round_up(*size_p, mr->min_page_size);
+ size = round_up(size, mr->min_page_size);
if (size == 0)
return -EINVAL;
/* For most of the ABI (e.g. mmap) we think in system pages */
GEM_BUG_ON(!IS_ALIGNED(size, PAGE_SIZE));
- /* Allocate the new object */
- obj = i915_gem_object_create_region(mr, size, 0);
- if (IS_ERR(obj))
- return PTR_ERR(obj);
-
- GEM_BUG_ON(size != obj->base.size);
+ if (i915_gem_object_size_2big(size))
+ return -E2BIG;
- ret = drm_gem_handle_create(file, &obj->base, &handle);
- /* drop reference from allocate - handle holds it now */
- i915_gem_object_put(obj);
+ ret = mr->ops->init_object(mr, obj, size, 0);
if (ret)
return ret;
- *handle_p = handle;
- *size_p = size;
+ GEM_BUG_ON(size != obj->base.size);
+
+ trace_i915_gem_object_create(obj);
return 0;
}
@@ -50,9 +60,11 @@ i915_gem_dumb_create(struct drm_file *file,
struct drm_device *dev,
struct drm_mode_create_dumb *args)
{
+ struct drm_i915_gem_object *obj;
enum intel_memory_type mem_type;
int cpp = DIV_ROUND_UP(args->bpp, 8);
u32 format;
+ int ret;
switch (cpp) {
case 1:
@@ -85,10 +97,22 @@ i915_gem_dumb_create(struct drm_file *file,
if (HAS_LMEM(to_i915(dev)))
mem_type = INTEL_MEMORY_LOCAL;
- return i915_gem_create(file,
- intel_memory_region_by_type(to_i915(dev),
- mem_type),
- &args->size, &args->handle);
+ obj = i915_gem_object_alloc();
+ if (!obj)
+ return -ENOMEM;
+
+ ret = i915_gem_setup(obj,
+intel_memory_region_by_type(to_i915(dev),
+mem_type),
+args->size);
+ if (ret)
+ goto object_free;
+
+ return i915_gem_publish(obj, file, &args->size, &args->handle);
+
+object_free:
+ i915_gem_object_free(obj);
+ return ret;
}
/**
@@ -103,11 +127,25 @@ i915_gem_create_ioctl(struct drm_device *dev, void *data,
{
struct drm_i915_private *i915 = to_i915(dev);
struct drm_i915_gem_create *args = data;
+ struct drm_i915_gem_object *obj;
+ int ret;
i915_gem_flush_free_objects(i915);
- return i915_gem_create(file,
- intel_memory_region_by_type(i915,
- INTEL_MEMORY_SYSTEM),
- &args->size, &args->handle);
+ obj = i915_gem_object_alloc();
+ if (!obj)
+ return -ENOMEM;
+
+ ret = i915_gem_setup(obj,
+
[Mesa-dev] [PATCH v2 5/9] drm/i915/uapi: introduce drm_i915_gem_create_ext
Same old gem_create but with now with extensions support. This is needed
to support various upcoming usecases.
v2:(Chris)
- Use separate ioctl number for gem_create_ext, instead of hijacking
the existing gem_create ioctl, otherwise we run into the issue
with being unable to detect if the kernel supports the new extension
behaviour.
- We now have gem_create_ext.flags, which should be zeroed.
- I915_GEM_CREATE_EXT_SETPARAM value is now zero, since this is the
index into our array of extensions.
- Setup a "vanilla" object which we can directly apply our extensions
to.
v3:(Daniel & Jason)
- drop I915_GEM_CREATE_EXT_SETPARAM. Instead just have each extension
do one thing only, instead of generic setparam which can cover
various use cases.
- add some kernel-doc.
Signed-off-by: Matthew Auld
Signed-off-by: CQ Tang
Cc: Joonas Lahtinen
Cc: Daniele Ceraolo Spurio
Cc: Lionel Landwerlin
Cc: Jordan Justen
Cc: Daniel Vetter
Cc: Kenneth Graunke
Cc: Jason Ekstrand
Cc: Dave Airlie
Cc: dri-de...@lists.freedesktop.org
Cc: mesa-dev@lists.freedesktop.org
Reviewed-by: Kenneth Graunke
---
drivers/gpu/drm/i915/gem/i915_gem_create.c | 56 ++
drivers/gpu/drm/i915/gem/i915_gem_ioctls.h | 2 +
drivers/gpu/drm/i915/i915_drv.c| 1 +
include/uapi/drm/i915_drm.h| 42
4 files changed, 101 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c
b/drivers/gpu/drm/i915/gem/i915_gem_create.c
index 409226df0dd2..1e82633a3898 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_create.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_create.c
@@ -8,6 +8,7 @@
#include "i915_drv.h"
#include "i915_trace.h"
+#include "i915_user_extensions.h"
static int i915_gem_publish(struct drm_i915_gem_object *obj,
struct drm_file *file,
@@ -149,3 +150,58 @@ i915_gem_create_ioctl(struct drm_device *dev, void *data,
i915_gem_object_free(obj);
return ret;
}
+
+struct create_ext {
+ struct drm_i915_private *i915;
+ struct drm_i915_gem_object *vanilla_object;
+};
+
+static const i915_user_extension_fn create_extensions[] = {
+};
+
+/**
+ * Creates a new mm object and returns a handle to it.
+ * @dev: drm device pointer
+ * @data: ioctl data blob
+ * @file: drm file pointer
+ */
+int
+i915_gem_create_ext_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file)
+{
+ struct drm_i915_private *i915 = to_i915(dev);
+ struct drm_i915_gem_create_ext *args = data;
+ struct create_ext ext_data = { .i915 = i915 };
+ struct drm_i915_gem_object *obj;
+ int ret;
+
+ if (args->flags)
+ return -EINVAL;
+
+ i915_gem_flush_free_objects(i915);
+
+ obj = i915_gem_object_alloc();
+ if (!obj)
+ return -ENOMEM;
+
+ ext_data.vanilla_object = obj;
+ ret = i915_user_extensions(u64_to_user_ptr(args->extensions),
+ create_extensions,
+ ARRAY_SIZE(create_extensions),
+ &ext_data);
+ if (ret)
+ goto object_free;
+
+ ret = i915_gem_setup(obj,
+intel_memory_region_by_type(i915,
+INTEL_MEMORY_SYSTEM),
+args->size);
+ if (ret)
+ goto object_free;
+
+ return i915_gem_publish(obj, file, &args->size, &args->handle);
+
+object_free:
+ i915_gem_object_free(obj);
+ return ret;
+}
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ioctls.h
b/drivers/gpu/drm/i915/gem/i915_gem_ioctls.h
index 7fd22f3efbef..28d6526e32ab 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ioctls.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ioctls.h
@@ -14,6 +14,8 @@ int i915_gem_busy_ioctl(struct drm_device *dev, void *data,
struct drm_file *file);
int i915_gem_create_ioctl(struct drm_device *dev, void *data,
struct drm_file *file);
+int i915_gem_create_ext_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file);
int i915_gem_execbuffer2_ioctl(struct drm_device *dev, void *data,
struct drm_file *file);
int i915_gem_get_aperture_ioctl(struct drm_device *dev, void *data,
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 785dcf20c77b..b5878c089830 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1728,6 +1728,7 @@ static const struct drm_ioctl_desc i915_ioctls[] = {
DRM_IOCTL_DEF_DRV(I915_GEM_ENTERVT, drm_noop,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
DRM_IOCTL_DEF_DRV(I915_GEM_LEAVEVT, drm_noop,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
DRM_IOCTL_DEF_DRV(I915_GEM_CREATE, i915_gem_create_ioctl,
DRM_RENDER_ALLOW),
+ DRM_IOCTL_
[Mesa-dev] [PATCH v2 6/9] drm/i915/uapi: implement object placement extension
Add new extension to support setting an immutable-priority-list of
potential placements, at creation time.
If we use the normal gem_create or gem_create_ext without the
extensions/placements then we still get the old behaviour with only
placing the object in system memory.
v2(Daniel & Jason):
- Add a bunch of kernel-doc
- Simplify design for placements extension
Testcase: igt/gem_create/create-ext-placement-sanity-check
Testcase: igt/gem_create/create-ext-placement-each
Testcase: igt/gem_create/create-ext-placement-all
Signed-off-by: Matthew Auld
Signed-off-by: CQ Tang
Cc: Joonas Lahtinen
Cc: Daniele Ceraolo Spurio
Cc: Lionel Landwerlin
Cc: Jordan Justen
Cc: Daniel Vetter
Cc: Kenneth Graunke
Cc: Jason Ekstrand
Cc: Dave Airlie
Cc: dri-de...@lists.freedesktop.org
Cc: mesa-dev@lists.freedesktop.org
Reviewed-by: Kenneth Graunke
---
drivers/gpu/drm/i915/gem/i915_gem_create.c| 218 --
drivers/gpu/drm/i915/gem/i915_gem_object.c| 3 +
.../gpu/drm/i915/gem/i915_gem_object_types.h | 6 +
.../drm/i915/gem/selftests/i915_gem_mman.c| 26 +++
drivers/gpu/drm/i915/intel_memory_region.c| 16 ++
drivers/gpu/drm/i915/intel_memory_region.h| 4 +
include/uapi/drm/i915_drm.h | 62 +
7 files changed, 318 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c
b/drivers/gpu/drm/i915/gem/i915_gem_create.c
index 1e82633a3898..957f790c644b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_create.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_create.c
@@ -4,12 +4,51 @@
*/
#include "gem/i915_gem_ioctls.h"
+#include "gem/i915_gem_lmem.h"
#include "gem/i915_gem_region.h"
#include "i915_drv.h"
#include "i915_trace.h"
#include "i915_user_extensions.h"
+static u32 object_max_page_size(struct drm_i915_gem_object *obj)
+{
+ u32 max_page_size = 0;
+ int i;
+
+ for (i = 0; i < obj->mm.n_placements; i++) {
+ struct intel_memory_region *mr = obj->mm.placements[i];
+
+ GEM_BUG_ON(!is_power_of_2(mr->min_page_size));
+ max_page_size = max_t(u32, max_page_size, mr->min_page_size);
+ }
+
+ GEM_BUG_ON(!max_page_size);
+ return max_page_size;
+}
+
+static void object_set_placements(struct drm_i915_gem_object *obj,
+ struct intel_memory_region **placements,
+ unsigned int n_placements)
+{
+ GEM_BUG_ON(!n_placements);
+
+ /*
+* For the common case of one memory region, skip storing an
+* allocated array and just point at the region directly.
+*/
+ if (n_placements == 1) {
+ struct intel_memory_region *mr = placements[0];
+ struct drm_i915_private *i915 = mr->i915;
+
+ obj->mm.placements = &i915->mm.regions[mr->id];
+ obj->mm.n_placements = 1;
+ } else {
+ obj->mm.placements = placements;
+ obj->mm.n_placements = n_placements;
+ }
+}
+
static int i915_gem_publish(struct drm_i915_gem_object *obj,
struct drm_file *file,
u64 *size_p,
@@ -29,14 +68,12 @@ static int i915_gem_publish(struct drm_i915_gem_object *obj,
}
static int
-i915_gem_setup(struct drm_i915_gem_object *obj,
- struct intel_memory_region *mr,
- u64 size)
+i915_gem_setup(struct drm_i915_gem_object *obj, u64 size)
{
+ struct intel_memory_region *mr = obj->mm.placements[0];
int ret;
- GEM_BUG_ON(!is_power_of_2(mr->min_page_size));
- size = round_up(size, mr->min_page_size);
+ size = round_up(size, object_max_page_size(obj));
if (size == 0)
return -EINVAL;
@@ -62,6 +99,7 @@ i915_gem_dumb_create(struct drm_file *file,
struct drm_mode_create_dumb *args)
{
struct drm_i915_gem_object *obj;
+ struct intel_memory_region *mr;
enum intel_memory_type mem_type;
int cpp = DIV_ROUND_UP(args->bpp, 8);
u32 format;
@@ -102,10 +140,10 @@ i915_gem_dumb_create(struct drm_file *file,
if (!obj)
return -ENOMEM;
- ret = i915_gem_setup(obj,
-intel_memory_region_by_type(to_i915(dev),
-mem_type),
-args->size);
+ mr = intel_memory_region_by_type(to_i915(dev), mem_type);
+ object_set_placements(obj, &mr, 1);
+
+ ret = i915_gem_setup(obj, args->size);
if (ret)
goto object_free;
@@ -129,6 +167,7 @@ i915_gem_create_ioctl(struct drm_device *dev, void *data,
struct drm_i915_private *i915 = to_i915(dev);
struct drm_i915_gem_create *args = data;
struct drm_i915_gem_object *obj;
+ struct intel_memory_region *mr;
int ret;
i915_gem_flush_free_objects(i915);
@@ -137,10 +176,10 @@ i915_gem_create_i
[Mesa-dev] [PATCH v2 7/9] drm/i915/lmem: support optional CPU clearing for special internal use
For some internal device local-memory objects it would be useful to have
an option to CPU clear the pages upon gathering the backing store. Note
that this might be before the blitter is useable, which is the case for
some internal GuC objects.
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Thomas Hellström
Cc: Daniele Ceraolo Spurio
Cc: Lionel Landwerlin
Cc: Jon Bloomfield
Cc: Jordan Justen
Cc: Daniel Vetter
Cc: Kenneth Graunke
Cc: Jason Ekstrand
Cc: Dave Airlie
Cc: dri-de...@lists.freedesktop.org
Cc: mesa-dev@lists.freedesktop.org
Acked-by: Kenneth Graunke
---
.../gpu/drm/i915/gem/i915_gem_object_types.h | 8 +-
drivers/gpu/drm/i915/gem/i915_gem_region.c| 22 +
.../drm/i915/selftests/intel_memory_region.c | 87 ++-
3 files changed, 113 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index 69d6e54bc569..0727d0c76aa0 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -172,11 +172,13 @@ struct drm_i915_gem_object {
#define I915_BO_ALLOC_CONTIGUOUS BIT(0)
#define I915_BO_ALLOC_VOLATILE BIT(1)
#define I915_BO_ALLOC_STRUCT_PAGE BIT(2)
+#define I915_BO_ALLOC_CPU_CLEAR BIT(3)
#define I915_BO_ALLOC_FLAGS (I915_BO_ALLOC_CONTIGUOUS | \
I915_BO_ALLOC_VOLATILE | \
-I915_BO_ALLOC_STRUCT_PAGE)
-#define I915_BO_READONLY BIT(3)
-#define I915_TILING_QUIRK_BIT4 /* unknown swizzling; do not release! */
+I915_BO_ALLOC_STRUCT_PAGE | \
+I915_BO_ALLOC_CPU_CLEAR)
+#define I915_BO_READONLY BIT(4)
+#define I915_TILING_QUIRK_BIT5 /* unknown swizzling; do not release! */
/*
* Is the object to be mapped as read-only to the GPU
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_region.c
b/drivers/gpu/drm/i915/gem/i915_gem_region.c
index 6a84fb6dde24..ce8fcfc54079 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_region.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_region.c
@@ -95,6 +95,28 @@ i915_gem_object_get_pages_buddy(struct drm_i915_gem_object
*obj)
sg_mark_end(sg);
i915_sg_trim(st);
+ /* Intended for kernel internal use only */
+ if (obj->flags & I915_BO_ALLOC_CPU_CLEAR) {
+ struct scatterlist *sg;
+ unsigned long i;
+
+ for_each_sg(st->sgl, sg, st->nents, i) {
+ unsigned int length;
+ void __iomem *vaddr;
+ dma_addr_t daddr;
+
+ daddr = sg_dma_address(sg);
+ daddr -= mem->region.start;
+ length = sg_dma_len(sg);
+
+ vaddr = io_mapping_map_wc(&mem->iomap, daddr, length);
+ memset64((void __force *)vaddr, 0, length /
sizeof(u64));
+ io_mapping_unmap(vaddr);
+ }
+
+ wmb();
+ }
+
__i915_gem_object_set_pages(obj, st, sg_page_sizes);
return 0;
diff --git a/drivers/gpu/drm/i915/selftests/intel_memory_region.c
b/drivers/gpu/drm/i915/selftests/intel_memory_region.c
index a5fc0bf3feb9..f85fd8cbfbf5 100644
--- a/drivers/gpu/drm/i915/selftests/intel_memory_region.c
+++ b/drivers/gpu/drm/i915/selftests/intel_memory_region.c
@@ -513,7 +513,7 @@ static int igt_cpu_check(struct drm_i915_gem_object *obj,
u32 dword, u32 val)
if (err)
return err;
- ptr = i915_gem_object_pin_map_unlocked(obj, I915_MAP_WC);
+ ptr = i915_gem_object_pin_map(obj, I915_MAP_WC);
if (IS_ERR(ptr))
return PTR_ERR(ptr);
@@ -593,7 +593,9 @@ static int igt_gpu_write(struct i915_gem_context *ctx,
if (err)
break;
+ i915_gem_object_lock(obj, NULL);
err = igt_cpu_check(obj, dword, rng);
+ i915_gem_object_unlock(obj);
if (err)
break;
} while (!__igt_timeout(end_time, NULL));
@@ -629,6 +631,88 @@ static int igt_lmem_create(void *arg)
return err;
}
+static int igt_lmem_create_cleared_cpu(void *arg)
+{
+ struct drm_i915_private *i915 = arg;
+ I915_RND_STATE(prng);
+ IGT_TIMEOUT(end_time);
+ u32 size, i;
+ int err;
+
+ i915_gem_drain_freed_objects(i915);
+
+ size = max_t(u32, PAGE_SIZE, i915_prandom_u32_max_state(SZ_32M, &prng));
+ size = round_up(size, PAGE_SIZE);
+ i = 0;
+
+ do {
+ struct drm_i915_gem_object *obj;
+ unsigned int flags;
+ u32 dword, val;
+ void *vaddr;
+
+ /*
+* Alternate between cleared and uncleared allocations, while
+* also dirtying the pages each time to check that the pages are
+* always cleared if requ
[Mesa-dev] [PATCH v2 8/9] drm/i915/gem: clear userspace buffers for LMEM
All userspace objects must be cleared when allocating the backing store,
before they are potentially visible to userspace. For now use simple
CPU based clearing to do this for device local-memory objects, note that
in the near future this will instead use the blitter engine.
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Thomas Hellström
Cc: Daniele Ceraolo Spurio
Cc: Lionel Landwerlin
Cc: Jon Bloomfield
Cc: Jordan Justen
Cc: Daniel Vetter
Cc: Kenneth Graunke
Cc: Jason Ekstrand
Cc: Dave Airlie
Cc: dri-de...@lists.freedesktop.org
Cc: mesa-dev@lists.freedesktop.org
Reviewed-by: Kenneth Graunke
---
drivers/gpu/drm/i915/gem/i915_gem_create.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c
b/drivers/gpu/drm/i915/gem/i915_gem_create.c
index 957f790c644b..f6729feae582 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_create.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_create.c
@@ -71,6 +71,7 @@ static int
i915_gem_setup(struct drm_i915_gem_object *obj, u64 size)
{
struct intel_memory_region *mr = obj->mm.placements[0];
+ unsigned int flags;
int ret;
size = round_up(size, object_max_page_size(obj));
@@ -83,7 +84,16 @@ i915_gem_setup(struct drm_i915_gem_object *obj, u64 size)
if (i915_gem_object_size_2big(size))
return -E2BIG;
- ret = mr->ops->init_object(mr, obj, size, 0);
+ /*
+* For now resort to CPU based clearing for device local-memory, in the
+* near future this will use the blitter engine for accelerated, GPU
+* based clearing.
+*/
+ flags = 0;
+ if (mr->type == INTEL_MEMORY_LOCAL)
+ flags = I915_BO_ALLOC_CPU_CLEAR;
+
+ ret = mr->ops->init_object(mr, obj, size, flags);
if (ret)
return ret;
--
2.26.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 9/9] drm/i915/gem: hide new uAPI behind CONFIG_BROKEN
Treat it the same as the fake local-memory stuff, where it is disabled
for normal kernels, in case some random UMD is tempted to use this. Once
we have all the other bits and pieces in place, like the TTM conversion,
we can turn this on for real.
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Thomas Hellström
Cc: Daniele Ceraolo Spurio
Cc: Lionel Landwerlin
Cc: Jon Bloomfield
Cc: Jordan Justen
Cc: Daniel Vetter
Cc: Kenneth Graunke
Cc: Jason Ekstrand
Cc: Dave Airlie
Cc: dri-de...@lists.freedesktop.org
Cc: mesa-dev@lists.freedesktop.org
Reviewed-by: Kenneth Graunke
---
drivers/gpu/drm/i915/gem/i915_gem_create.c | 3 +++
drivers/gpu/drm/i915/i915_query.c | 3 +++
2 files changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c
b/drivers/gpu/drm/i915/gem/i915_gem_create.c
index f6729feae582..548ddf39d853 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_create.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_create.c
@@ -335,6 +335,9 @@ static int ext_set_placements(struct i915_user_extension
__user *base,
{
struct drm_i915_gem_create_ext_memory_regions ext;
+ if (!IS_ENABLED(CONFIG_DRM_I915_UNSTABLE_FAKE_LMEM))
+ return -ENODEV;
+
if (copy_from_user(&ext, base, sizeof(ext)))
return -EFAULT;
diff --git a/drivers/gpu/drm/i915/i915_query.c
b/drivers/gpu/drm/i915/i915_query.c
index 5e2b909827f4..e49da36c62fb 100644
--- a/drivers/gpu/drm/i915/i915_query.c
+++ b/drivers/gpu/drm/i915/i915_query.c
@@ -432,6 +432,9 @@ static int query_memregion_info(struct drm_i915_private
*i915,
u32 total_length;
int ret, id, i;
+ if (!IS_ENABLED(CONFIG_DRM_I915_UNSTABLE_FAKE_LMEM))
+ return -ENODEV;
+
if (query_item->flags != 0)
return -EINVAL;
--
2.26.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal
On Wed, Apr 28, 2021 at 04:45:01PM +0200, Christian König wrote: > Am 28.04.21 um 16:34 schrieb Daniel Vetter: > > On Wed, Apr 28, 2021 at 03:37:49PM +0200, Christian König wrote: > > > Am 28.04.21 um 15:34 schrieb Daniel Vetter: > > > > On Wed, Apr 28, 2021 at 03:11:27PM +0200, Christian König wrote: > > > > > Am 28.04.21 um 14:26 schrieb Daniel Vetter: > > > > > > On Wed, Apr 28, 2021 at 02:21:54PM +0200, Daniel Vetter wrote: > > > > > > > On Wed, Apr 28, 2021 at 12:31:09PM +0200, Christian König wrote: > > > > > > > > Am 28.04.21 um 12:05 schrieb Daniel Vetter: > > > > > > > > > On Tue, Apr 27, 2021 at 02:01:20PM -0400, Alex Deucher wrote: > > > > > > > > > > On Tue, Apr 27, 2021 at 1:35 PM Simon Ser > > > > > > > > > > wrote: > > > > > > > > > > > On Tuesday, April 27th, 2021 at 7:31 PM, Lucas Stach > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > Ok. So that would only make the following use cases > > > > > > > > > > > > > broken for now: > > > > > > > > > > > > > > > > > > > > > > > > > > - amd render -> external gpu > > > > > > > > > > > > > - amd video encode -> network device > > > > > > > > > > > > FWIW, "only" breaking amd render -> external gpu will > > > > > > > > > > > > make us pretty > > > > > > > > > > > > unhappy > > > > > > > > > > > I concur. I have quite a few users with a multi-GPU setup > > > > > > > > > > > involving > > > > > > > > > > > AMD hardware. > > > > > > > > > > > > > > > > > > > > > > Note, if this brokenness can't be avoided, I'd prefer a > > > > > > > > > > > to get a clear > > > > > > > > > > > error, and not bad results on screen because nothing is > > > > > > > > > > > synchronized > > > > > > > > > > > anymore. > > > > > > > > > > It's an upcoming requirement for windows[1], so you are > > > > > > > > > > likely to > > > > > > > > > > start seeing this across all GPU vendors that support > > > > > > > > > > windows. I > > > > > > > > > > think the timing depends on how quickly the legacy hardware > > > > > > > > > > support > > > > > > > > > > sticks around for each vendor. > > > > > > > > > Yeah but hw scheduling doesn't mean the hw has to be > > > > > > > > > constructed to not > > > > > > > > > support isolating the ringbuffer at all. > > > > > > > > > > > > > > > > > > E.g. even if the hw loses the bit to put the ringbuffer > > > > > > > > > outside of the > > > > > > > > > userspace gpu vm, if you have pagetables I'm seriously hoping > > > > > > > > > you have r/o > > > > > > > > > pte flags. Otherwise the entire "share address space with cpu > > > > > > > > > side, > > > > > > > > > seamlessly" thing is out of the window. > > > > > > > > > > > > > > > > > > And with that r/o bit on the ringbuffer you can once more > > > > > > > > > force submit > > > > > > > > > through kernel space, and all the legacy dma_fence based > > > > > > > > > stuff keeps > > > > > > > > > working. And we don't have to invent some horrendous > > > > > > > > > userspace fence based > > > > > > > > > implicit sync mechanism in the kernel, but can instead do > > > > > > > > > this transition > > > > > > > > > properly with drm_syncobj timeline explicit sync and protocol > > > > > > > > > reving. > > > > > > > > > > > > > > > > > > At least I think you'd have to work extra hard to create a > > > > > > > > > gpu which > > > > > > > > > cannot possibly be intercepted by the kernel, even when it's > > > > > > > > > designed to > > > > > > > > > support userspace direct submit only. > > > > > > > > > > > > > > > > > > Or are your hw engineers more creative here and we're screwed? > > > > > > > > The upcomming hardware generation will have this hardware > > > > > > > > scheduler as a > > > > > > > > must have, but there are certain ways we can still stick to the > > > > > > > > old > > > > > > > > approach: > > > > > > > > > > > > > > > > 1. The new hardware scheduler currently still supports kernel > > > > > > > > queues which > > > > > > > > essentially is the same as the old hardware ring buffer. > > > > > > > > > > > > > > > > 2. Mapping the top level ring buffer into the VM at least > > > > > > > > partially solves > > > > > > > > the problem. This way you can't manipulate the ring buffer > > > > > > > > content, but the > > > > > > > > location for the fence must still be writeable. > > > > > > > Yeah allowing userspace to lie about completion fences in this > > > > > > > model is > > > > > > > ok. Though I haven't thought through full consequences of that, > > > > > > > but I > > > > > > > think it's not any worse than userspace lying about which > > > > > > > buffers/address > > > > > > > it uses in the current model - we rely on hw vm ptes to catch > > > > > > > that stuff. > > > > > > > > > > > > > > Also it might be good to switch to a non-recoverable ctx model > > > > > > > for these. > > > > > > > That's already what we do in i915 (opt-in, but all current umd > > > > > > > use that > > > > > > > mode). So any
Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal
On Wed, Apr 28, 2021 at 04:39:24PM -0400, Alex Deucher wrote: > On Wed, Apr 28, 2021 at 10:35 AM Daniel Vetter wrote: > > > > On Wed, Apr 28, 2021 at 03:37:49PM +0200, Christian König wrote: > > > Am 28.04.21 um 15:34 schrieb Daniel Vetter: > > > > On Wed, Apr 28, 2021 at 03:11:27PM +0200, Christian König wrote: > > > > > Am 28.04.21 um 14:26 schrieb Daniel Vetter: > > > > > > On Wed, Apr 28, 2021 at 02:21:54PM +0200, Daniel Vetter wrote: > > > > > > > On Wed, Apr 28, 2021 at 12:31:09PM +0200, Christian König wrote: > > > > > > > > Am 28.04.21 um 12:05 schrieb Daniel Vetter: > > > > > > > > > On Tue, Apr 27, 2021 at 02:01:20PM -0400, Alex Deucher wrote: > > > > > > > > > > On Tue, Apr 27, 2021 at 1:35 PM Simon Ser > > > > > > > > > > wrote: > > > > > > > > > > > On Tuesday, April 27th, 2021 at 7:31 PM, Lucas Stach > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > Ok. So that would only make the following use cases > > > > > > > > > > > > > broken for now: > > > > > > > > > > > > > > > > > > > > > > > > > > - amd render -> external gpu > > > > > > > > > > > > > - amd video encode -> network device > > > > > > > > > > > > FWIW, "only" breaking amd render -> external gpu will > > > > > > > > > > > > make us pretty > > > > > > > > > > > > unhappy > > > > > > > > > > > I concur. I have quite a few users with a multi-GPU setup > > > > > > > > > > > involving > > > > > > > > > > > AMD hardware. > > > > > > > > > > > > > > > > > > > > > > Note, if this brokenness can't be avoided, I'd prefer a > > > > > > > > > > > to get a clear > > > > > > > > > > > error, and not bad results on screen because nothing is > > > > > > > > > > > synchronized > > > > > > > > > > > anymore. > > > > > > > > > > It's an upcoming requirement for windows[1], so you are > > > > > > > > > > likely to > > > > > > > > > > start seeing this across all GPU vendors that support > > > > > > > > > > windows. I > > > > > > > > > > think the timing depends on how quickly the legacy hardware > > > > > > > > > > support > > > > > > > > > > sticks around for each vendor. > > > > > > > > > Yeah but hw scheduling doesn't mean the hw has to be > > > > > > > > > constructed to not > > > > > > > > > support isolating the ringbuffer at all. > > > > > > > > > > > > > > > > > > E.g. even if the hw loses the bit to put the ringbuffer > > > > > > > > > outside of the > > > > > > > > > userspace gpu vm, if you have pagetables I'm seriously hoping > > > > > > > > > you have r/o > > > > > > > > > pte flags. Otherwise the entire "share address space with cpu > > > > > > > > > side, > > > > > > > > > seamlessly" thing is out of the window. > > > > > > > > > > > > > > > > > > And with that r/o bit on the ringbuffer you can once more > > > > > > > > > force submit > > > > > > > > > through kernel space, and all the legacy dma_fence based > > > > > > > > > stuff keeps > > > > > > > > > working. And we don't have to invent some horrendous > > > > > > > > > userspace fence based > > > > > > > > > implicit sync mechanism in the kernel, but can instead do > > > > > > > > > this transition > > > > > > > > > properly with drm_syncobj timeline explicit sync and protocol > > > > > > > > > reving. > > > > > > > > > > > > > > > > > > At least I think you'd have to work extra hard to create a > > > > > > > > > gpu which > > > > > > > > > cannot possibly be intercepted by the kernel, even when it's > > > > > > > > > designed to > > > > > > > > > support userspace direct submit only. > > > > > > > > > > > > > > > > > > Or are your hw engineers more creative here and we're screwed? > > > > > > > > The upcomming hardware generation will have this hardware > > > > > > > > scheduler as a > > > > > > > > must have, but there are certain ways we can still stick to the > > > > > > > > old > > > > > > > > approach: > > > > > > > > > > > > > > > > 1. The new hardware scheduler currently still supports kernel > > > > > > > > queues which > > > > > > > > essentially is the same as the old hardware ring buffer. > > > > > > > > > > > > > > > > 2. Mapping the top level ring buffer into the VM at least > > > > > > > > partially solves > > > > > > > > the problem. This way you can't manipulate the ring buffer > > > > > > > > content, but the > > > > > > > > location for the fence must still be writeable. > > > > > > > Yeah allowing userspace to lie about completion fences in this > > > > > > > model is > > > > > > > ok. Though I haven't thought through full consequences of that, > > > > > > > but I > > > > > > > think it's not any worse than userspace lying about which > > > > > > > buffers/address > > > > > > > it uses in the current model - we rely on hw vm ptes to catch > > > > > > > that stuff. > > > > > > > > > > > > > > Also it might be good to switch to a non-recoverable ctx model > > > > > > > for these. > > > > > > > That's already what we do in i915 (opt-in, but all current umd > > > > > > > use that > > > > > > > mode). So a
Re: [Mesa-dev] Rename "master" branch to "main"?
On 2021-03-25 08:11:45, Jason Ekstrand wrote: > On Thu, Mar 25, 2021 at 9:41 AM Rob Clark wrote: > > > > yeah, I meant to convert a repo w/ more MRs than 7 but less than mesa > > using the script to beta test that, wasn't suggesting to do it by hand > > Plan is to convert piglit next. It's sitting at about 60 open MRs. > Piglit's conversion went through last month without any issues. Therefore I opened an MR for mesa: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10474 This MR makes some changes to the tree to rename the branch, and it adds an empty warning message commit. This warning message will live as the last commit on the upstream master branch for the forseeable future as a notice to developers that they need to change the upstream tracking ref to main. We also have a related issue open to track some other tasks related to the rename: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4501 Timing wise, it's probably about the best time around now to maximize the time before the next release branchpoint. Regarding the 21.1 release, I think there could be arguments for before or after. One reason to go before the release is to work out any kinks before the potentially more urgent 20.1.1 release. But, before or after, I think Eric and Dylan will be more than capable of doing some extra checks to verify that the scripts are working for the stable branches. -Jordan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
