On 01/12/2020 12:55, Chris Wilson wrote:
Quoting Matthew Auld (2020-11-27 12:06:08)
Same old gem_create but with now with extensions support. This is needed
to support various upcoming usecases. For now we use the extensions
mechanism to support setting an immutable-priority-list of potential
placements, at creation time.
If we wish to set the placements/regions we can simply do:
struct drm_i915_gem_object_param region_param = { … }; /* Unchanged */
struct drm_i915_gem_create_ext_setparam setparam_region = {
.base = { .name = I915_GEM_CREATE_EXT_SETPARAM },
.param = region_param,
}
struct drm_i915_gem_create_ext create_ext = {
.size = 16 * PAGE_SIZE,
.extensions = (uintptr_t)&setparam_region,
};
int err = ioctl(fd, DRM_IOCTL_I915_GEM_CREATE_EXT, &create_ext);
if (err) ...
Looking at the existing gem_create, there is no detection of an
unsupported extension. That is there is no rejection of new userspace
asking for placement on an old kernel. (As erroneous as that would be
for many other reasons.)
Unless I've missed something, we need a new ioctl number for CREATEv2.
+Joonas
Right, and I guess it's not a good idea for userspace to implement
something like has_gem_create_ext()?
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx