Re: [Intel-gfx] [RFC] libdrm_intel: Add support for userptr objects
On 06/19/2014 12:13 PM, Damien Lespiau wrote: On Wed, Feb 26, 2014 at 04:41:41PM +, Tvrtko Ursulin wrote: From: Tvrtko Ursulin tvrtko.ursu...@intel.com Allow userptr objects to be created and used via libdrm_intel. At the moment tiling and mapping to GTT aperture is not supported due hardware limitations across different generations and uncertainty about its usefulness. Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com --- include/drm/i915_drm.h| 16 + intel/intel_bufmgr.c | 13 intel/intel_bufmgr.h | 5 ++ intel/intel_bufmgr_gem.c | 154 +- intel/intel_bufmgr_priv.h | 12 +++- 5 files changed, 198 insertions(+), 2 deletions(-) Apart from couple of remarks below I couldn't find anything that would prevent merging this. Well, except maybe that it'd be very nice to have some feedback from someone using it, we do have an API/ABI guarantee on libdrm after all. Looks like I've forgotten to reply to this. I did address the other review comments and sent out a v2 back then. But for what users are concerned, apart from internal ones who have been using this API for some years now, I don't know of any. Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] libdrm_intel: Add support for userptr objects
On Wed, Jul 09, 2014 at 02:08:08PM +0100, Tvrtko Ursulin wrote: On 06/19/2014 12:13 PM, Damien Lespiau wrote: On Wed, Feb 26, 2014 at 04:41:41PM +, Tvrtko Ursulin wrote: From: Tvrtko Ursulin tvrtko.ursu...@intel.com Allow userptr objects to be created and used via libdrm_intel. At the moment tiling and mapping to GTT aperture is not supported due hardware limitations across different generations and uncertainty about its usefulness. Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com --- include/drm/i915_drm.h| 16 + intel/intel_bufmgr.c | 13 intel/intel_bufmgr.h | 5 ++ intel/intel_bufmgr_gem.c | 154 +- intel/intel_bufmgr_priv.h | 12 +++- 5 files changed, 198 insertions(+), 2 deletions(-) Apart from couple of remarks below I couldn't find anything that would prevent merging this. Well, except maybe that it'd be very nice to have some feedback from someone using it, we do have an API/ABI guarantee on libdrm after all. Looks like I've forgotten to reply to this. I did address the other review comments and sent out a v2 back then. But for what users are concerned, apart from internal ones who have been using this API for some years now, I don't know of any. Well, considering this is only a wrapper of an ioctl() already upstreamed, I'm inclined to just push it as is. Daniel any thoughts? -- Damien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] libdrm_intel: Add support for userptr objects
On Wed, Jul 09, 2014 at 02:16:59PM +0100, Damien Lespiau wrote: On Wed, Jul 09, 2014 at 02:08:08PM +0100, Tvrtko Ursulin wrote: On 06/19/2014 12:13 PM, Damien Lespiau wrote: On Wed, Feb 26, 2014 at 04:41:41PM +, Tvrtko Ursulin wrote: From: Tvrtko Ursulin tvrtko.ursu...@intel.com Allow userptr objects to be created and used via libdrm_intel. At the moment tiling and mapping to GTT aperture is not supported due hardware limitations across different generations and uncertainty about its usefulness. Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com --- include/drm/i915_drm.h| 16 + intel/intel_bufmgr.c | 13 intel/intel_bufmgr.h | 5 ++ intel/intel_bufmgr_gem.c | 154 +- intel/intel_bufmgr_priv.h | 12 +++- 5 files changed, 198 insertions(+), 2 deletions(-) Apart from couple of remarks below I couldn't find anything that would prevent merging this. Well, except maybe that it'd be very nice to have some feedback from someone using it, we do have an API/ABI guarantee on libdrm after all. Looks like I've forgotten to reply to this. I did address the other review comments and sent out a v2 back then. But for what users are concerned, apart from internal ones who have been using this API for some years now, I don't know of any. Well, considering this is only a wrapper of an ioctl() already upstreamed, I'm inclined to just push it as is. Daniel any thoughts? Since both igt and sna have their own wrappers and the beinget patch for this hasn't surfaced yet we don't really have a public open-source user for this yet. My understanding of Dave's stance is that we should hold off with committing until this is requirement is fulfilled. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] libdrm_intel: Add support for userptr objects
On Wed, Jul 09, 2014 at 04:25:55PM +0200, Daniel Vetter wrote:
On Wed, Jul 09, 2014 at 02:16:59PM +0100, Damien Lespiau wrote:
On Wed, Jul 09, 2014 at 02:08:08PM +0100, Tvrtko Ursulin wrote:
On 06/19/2014 12:13 PM, Damien Lespiau wrote:
On Wed, Feb 26, 2014 at 04:41:41PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
Allow userptr objects to be created and used via libdrm_intel.
At the moment tiling and mapping to GTT aperture is not supported
due hardware limitations across different generations and uncertainty
about its usefulness.
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
---
include/drm/i915_drm.h| 16 +
intel/intel_bufmgr.c | 13
intel/intel_bufmgr.h | 5 ++
intel/intel_bufmgr_gem.c | 154
+-
intel/intel_bufmgr_priv.h | 12 +++-
5 files changed, 198 insertions(+), 2 deletions(-)
Apart from couple of remarks below I couldn't find anything that would
prevent merging this. Well, except maybe that it'd be very nice to have
some feedback from someone using it, we do have an API/ABI guarantee on
libdrm after all.
Looks like I've forgotten to reply to this. I did address the other
review comments and sent out a v2 back then.
But for what users are concerned, apart from internal ones who have
been using this API for some years now, I don't know of any.
Well, considering this is only a wrapper of an ioctl() already
upstreamed, I'm inclined to just push it as is. Daniel any thoughts?
Since both igt and sna have their own wrappers and the beinget patch for
this hasn't surfaced yet we don't really have a public open-source user
for this yet. My understanding of Dave's stance is that we should hold off
with committing until this is requirement is fulfilled.
The interface is fairly ugly since it combines the tiling into the
create, which is just as convenient as a second step.
But if you want a user, just wire up an accelerated glReadPixels. Now,
this is only really beneficial as the current ReadPixels is not well
optimised and it assumes that userptr drm_intel_bo is automatically
synced on destruction:
diff --git a/src/mesa/drivers/dri/i965/intel_pixel_read.c
b/src/mesa/drivers/dri/i965/intel_pixel_read.c
index beb3152..1b1f7e4 100644
--- a/src/mesa/drivers/dri/i965/intel_pixel_read.c
+++ b/src/mesa/drivers/dri/i965/intel_pixel_read.c
@@ -161,6 +161,103 @@ do_blit_readpixels(struct gl_context * ctx,
return true;
}
+static bool
+do_userptr_readpixels(struct gl_context * ctx,
+ GLint x, GLint y, GLsizei width, GLsizei height,
+ GLenum format, GLenum type,
+ const struct gl_pixelstore_attrib *pack, GLvoid * pixels)
+{
+ struct brw_context *brw = brw_context(ctx);
+ GLuint dst_offset;
+ drm_intel_bo *dst_buffer;
+ GLint dst_x, dst_y;
+ GLuint dirty;
+
+ DBG(%s\n, __FUNCTION__);
+
+ assert(_mesa_is_bufferobj(pack-BufferObj));
+
+ struct gl_renderbuffer *rb = ctx-ReadBuffer-_ColorReadBuffer;
+ struct intel_renderbuffer *irb = intel_renderbuffer(rb);
+ uintptr_t start, end;
+
+ /* Currently this function only supports reading from color buffers. */
+ if (!_mesa_is_color_format(format))
+ return false;
+
+ assert(irb != NULL);
+
+ if (ctx-_ImageTransferState ||
+ !_mesa_format_matches_format_and_type(irb-mt-format, format, type,
+ false)) {
+ DBG(%s - bad format for blit\n, __FUNCTION__);
+ return false;
+ }
+
+ if (pack-SwapBytes || pack-LsbFirst) {
+ DBG(%s: bad packing params\n, __FUNCTION__);
+ return false;
+ }
+
+ int dst_stride = _mesa_image_row_stride(pack, width, format, type);
+ bool dst_flip = false;
+ /* Mesa flips the dst_stride for pack-Invert, but we want our mt to have a
+* normal dst_stride.
+*/
+ struct gl_pixelstore_attrib uninverted_pack = *pack;
+ if (pack-Invert) {
+ dst_stride = -dst_stride;
+ dst_flip = true;
+ uninverted_pack.Invert = false;
+ }
+
+ dst_offset = (GLintptr)pixels;
+ dst_offset += _mesa_image_offset(2, uninverted_pack, width, height,
+ format, type, 0, 0, 0);
+
+ if (!_mesa_clip_copytexsubimage(ctx,
+ dst_x, dst_y,
+ x, y,
+ width, height)) {
+ return true;
+ }
+
+ dirty = brw-front_buffer_dirty;
+ intel_prepare_render(brw);
+ brw-front_buffer_dirty = dirty;
+
+ start = (uintptr_t)(pixel + dst_offset) ~4095;
+ end = (uintptr_t)(pixel + dst_offset + dst_stride * height + 4095) ~4095;
+
+ dst_buffer = drm_intel_bo_alloc_userptr(bufmgr, glReadPixels,
+ (void *)start,
+ I915_TILING_NONE, dst_stride,
+
Re: [Intel-gfx] [RFC] libdrm_intel: Add support for userptr objects
On Wed, Feb 26, 2014 at 04:41:41PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
Allow userptr objects to be created and used via libdrm_intel.
At the moment tiling and mapping to GTT aperture is not supported
due hardware limitations across different generations and uncertainty
about its usefulness.
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
---
include/drm/i915_drm.h| 16 +
intel/intel_bufmgr.c | 13
intel/intel_bufmgr.h | 5 ++
intel/intel_bufmgr_gem.c | 154
+-
intel/intel_bufmgr_priv.h | 12 +++-
5 files changed, 198 insertions(+), 2 deletions(-)
Apart from couple of remarks below I couldn't find anything that would
prevent merging this. Well, except maybe that it'd be very nice to have
some feedback from someone using it, we do have an API/ABI guarantee on
libdrm after all.
--
Damien
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index 2f4eb8c..d32ef99 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -223,6 +223,7 @@ typedef struct _drm_i915_sarea {
#define DRM_I915_GEM_GET_CACHING 0x30
#define DRM_I915_REG_READ0x31
#define DRM_I915_GET_RESET_STATS 0x32
+#define DRM_I915_GEM_USERPTR 0x34
#define DRM_IOCTL_I915_INIT DRM_IOW( DRM_COMMAND_BASE +
DRM_I915_INIT, drm_i915_init_t)
#define DRM_IOCTL_I915_FLUSH DRM_IO ( DRM_COMMAND_BASE +
DRM_I915_FLUSH)
@@ -273,6 +274,7 @@ typedef struct _drm_i915_sarea {
#define DRM_IOCTL_I915_GEM_CONTEXT_DESTROY DRM_IOW (DRM_COMMAND_BASE +
DRM_I915_GEM_CONTEXT_DESTROY, struct drm_i915_gem_context_destroy)
#define DRM_IOCTL_I915_REG_READ DRM_IOWR
(DRM_COMMAND_BASE + DRM_I915_REG_READ, struct drm_i915_reg_read)
#define DRM_IOCTL_I915_GET_RESET_STATS DRM_IOWR
(DRM_COMMAND_BASE + DRM_I915_GET_RESET_STATS, struct drm_i915_reset_stats)
+#define DRM_IOCTL_I915_GEM_USERPTR DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_USERPTR, struct drm_i915_gem_userptr)
/* Allow drivers to submit batchbuffers directly to hardware, relying
* on the security mechanisms provided by hardware.
@@ -498,6 +500,20 @@ struct drm_i915_gem_mmap_gtt {
__u64 offset;
};
+struct drm_i915_gem_userptr {
+ __u64 user_ptr;
+ __u64 user_size;
+ __u32 flags;
+#define I915_USERPTR_READ_ONLY 0x1
+#define I915_USERPTR_UNSYNCHRONIZED 0x8000
+ /**
+ * Returned handle for the object.
+ *
+ * Object handles are nonzero.
+ */
+ __u32 handle;
+};
+
struct drm_i915_gem_set_domain {
/** Handle for the object */
__u32 handle;
diff --git a/intel/intel_bufmgr.c b/intel/intel_bufmgr.c
index 905556f..7f3d795 100644
--- a/intel/intel_bufmgr.c
+++ b/intel/intel_bufmgr.c
@@ -60,6 +60,19 @@ drm_intel_bo
*drm_intel_bo_alloc_for_render(drm_intel_bufmgr *bufmgr,
return bufmgr-bo_alloc_for_render(bufmgr, name, size, alignment);
}
+drm_intel_bo *drm_intel_bo_alloc_userptr(drm_intel_bufmgr *bufmgr,
+ const char *name, void *addr,
+ uint32_t tiling_mode,
+ uint32_t stride,
+ unsigned long size,
+ unsigned long flags)
+{
+ if (bufmgr-bo_alloc_userptr)
+ return bufmgr-bo_alloc_userptr(bufmgr, name, addr, tiling_mode,
+ stride, size, flags);
+ return NULL;
+}
+
drm_intel_bo *
drm_intel_bo_alloc_tiled(drm_intel_bufmgr *bufmgr, const char *name,
int x, int y, int cpp, uint32_t *tiling_mode,
diff --git a/intel/intel_bufmgr.h b/intel/intel_bufmgr.h
index 9383c72..be83a56 100644
--- a/intel/intel_bufmgr.h
+++ b/intel/intel_bufmgr.h
@@ -113,6 +113,11 @@ drm_intel_bo
*drm_intel_bo_alloc_for_render(drm_intel_bufmgr *bufmgr,
const char *name,
unsigned long size,
unsigned int alignment);
+drm_intel_bo *drm_intel_bo_alloc_userptr(drm_intel_bufmgr *bufmgr,
+ const char *name,
+ void *addr, uint32_t tiling_mode,
+ uint32_t stride, unsigned long size,
+ unsigned long flags);
drm_intel_bo *drm_intel_bo_alloc_tiled(drm_intel_bufmgr *bufmgr,
const char *name,
int x, int y, int cpp,
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 007a6d8..7cad945 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -182,6 +182,11 @@ struct _drm_intel_bo_gem {
void *mem_virtual;
Re: [Intel-gfx] [RFC] libdrm_intel: Add support for userptr objects
On Thu, Jun 19, 2014 at 12:13:20PM +0100, Damien Lespiau wrote: On Wed, Feb 26, 2014 at 04:41:41PM +, Tvrtko Ursulin wrote: From: Tvrtko Ursulin tvrtko.ursu...@intel.com Allow userptr objects to be created and used via libdrm_intel. At the moment tiling and mapping to GTT aperture is not supported due hardware limitations across different generations and uncertainty about its usefulness. Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com --- include/drm/i915_drm.h| 16 + intel/intel_bufmgr.c | 13 intel/intel_bufmgr.h | 5 ++ intel/intel_bufmgr_gem.c | 154 +- intel/intel_bufmgr_priv.h | 12 +++- 5 files changed, 198 insertions(+), 2 deletions(-) Apart from couple of remarks below I couldn't find anything that would prevent merging this. Well, except maybe that it'd be very nice to have some feedback from someone using it, we do have an API/ABI guarantee on libdrm after all. Actually, if you're retouching this patch, maybe spliting the i915_drm.h update would be good, that's something we can push straight away. -- Damien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] libdrm_intel: Add support for userptr objects
On Fri, May 09, 2014 at 06:30:11AM +0100, Chris Wilson wrote:
On Thu, May 08, 2014 at 05:10:24PM -0700, Ben Widawsky wrote:
On Wed, Feb 26, 2014 at 04:41:41PM +, Tvrtko Ursulin wrote:
+struct drm_i915_gem_userptr {
+ __u64 user_ptr;
+ __u64 user_size;
+ __u32 flags;
+#define I915_USERPTR_READ_ONLY 0x1
+#define I915_USERPTR_UNSYNCHRONIZED 0x8000
+ /**
+ * Returned handle for the object.
+ *
+ * Object handles are nonzero.
+ */
+ __u32 handle;
+};
+
Oh yeah. I want a ctx_id here as well. Chris, any objection to adding
this?
What for? bo are file-scoped not context-scoped.
I think what Ben actually wants is a ctx_id in the soft-pin ioctl. Makes
his mirrored ppgtt POC a 2 ioctl thing, but the resulting orthogonality of
interfaces is imo something much to be preferred. Since we still need real
bos for scanout targets and similar, and I'm going to rip everyone's head
off if we do that by shmem-mapping+userptr ;-)
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] libdrm_intel: Add support for userptr objects
On Wed, Feb 26, 2014 at 04:41:41PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
Allow userptr objects to be created and used via libdrm_intel.
At the moment tiling and mapping to GTT aperture is not supported
due hardware limitations across different generations and uncertainty
about its usefulness.
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
---
include/drm/i915_drm.h| 16 +
intel/intel_bufmgr.c | 13
intel/intel_bufmgr.h | 5 ++
intel/intel_bufmgr_gem.c | 154
+-
intel/intel_bufmgr_priv.h | 12 +++-
5 files changed, 198 insertions(+), 2 deletions(-)
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index 2f4eb8c..d32ef99 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -223,6 +223,7 @@ typedef struct _drm_i915_sarea {
#define DRM_I915_GEM_GET_CACHING 0x30
#define DRM_I915_REG_READ0x31
#define DRM_I915_GET_RESET_STATS 0x32
+#define DRM_I915_GEM_USERPTR 0x34
#define DRM_IOCTL_I915_INIT DRM_IOW( DRM_COMMAND_BASE +
DRM_I915_INIT, drm_i915_init_t)
#define DRM_IOCTL_I915_FLUSH DRM_IO ( DRM_COMMAND_BASE +
DRM_I915_FLUSH)
@@ -273,6 +274,7 @@ typedef struct _drm_i915_sarea {
#define DRM_IOCTL_I915_GEM_CONTEXT_DESTROY DRM_IOW (DRM_COMMAND_BASE +
DRM_I915_GEM_CONTEXT_DESTROY, struct drm_i915_gem_context_destroy)
#define DRM_IOCTL_I915_REG_READ DRM_IOWR
(DRM_COMMAND_BASE + DRM_I915_REG_READ, struct drm_i915_reg_read)
#define DRM_IOCTL_I915_GET_RESET_STATS DRM_IOWR
(DRM_COMMAND_BASE + DRM_I915_GET_RESET_STATS, struct drm_i915_reset_stats)
+#define DRM_IOCTL_I915_GEM_USERPTR DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_USERPTR, struct drm_i915_gem_userptr)
/* Allow drivers to submit batchbuffers directly to hardware, relying
* on the security mechanisms provided by hardware.
@@ -498,6 +500,20 @@ struct drm_i915_gem_mmap_gtt {
__u64 offset;
};
+struct drm_i915_gem_userptr {
+ __u64 user_ptr;
+ __u64 user_size;
+ __u32 flags;
+#define I915_USERPTR_READ_ONLY 0x1
+#define I915_USERPTR_UNSYNCHRONIZED 0x8000
+ /**
+ * Returned handle for the object.
+ *
+ * Object handles are nonzero.
+ */
+ __u32 handle;
+};
+
Oh yeah. I want a ctx_id here as well. Chris, any objection to adding
this?
[snip]
--
Ben Widawsky, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] libdrm_intel: Add support for userptr objects
On Thu, May 08, 2014 at 05:10:24PM -0700, Ben Widawsky wrote:
On Wed, Feb 26, 2014 at 04:41:41PM +, Tvrtko Ursulin wrote:
+struct drm_i915_gem_userptr {
+ __u64 user_ptr;
+ __u64 user_size;
+ __u32 flags;
+#define I915_USERPTR_READ_ONLY 0x1
+#define I915_USERPTR_UNSYNCHRONIZED 0x8000
+ /**
+ * Returned handle for the object.
+ *
+ * Object handles are nonzero.
+ */
+ __u32 handle;
+};
+
Oh yeah. I want a ctx_id here as well. Chris, any objection to adding
this?
What for? bo are file-scoped not context-scoped.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] libdrm_intel: Add support for userptr objects
On 05/02/2014 06:15 PM, Ben Widawsky wrote: On Fri, May 02, 2014 at 11:27:45AM +0100, Tvrtko Ursulin wrote: Some people expressed interest in tiling so I thought to preserve it in the API. Kernel even allows it, and it is just because Chris found bspec references saying it will break badly on some platforms, that I (or maybe it was both of us) decided to disable it on this level for time being. So I think it is just a matter of coming up with a blacklist and it would be possible to use it then. Well again, maybe this is specific to my usecase, but I can never imagine a use for such fields at this stage in the buffer's lifecycle. Could you get some people to describe how they want to use it? Actually thinking about it more, when I collated requirements from various groups they were not all that interested. But Chris was actually in favour of keeping it in the kernel rather than disabling it altogether. So I decided to keep it in the userspace API and only reject the attempts to use it for time being. I think a param for USERPTR is warranted. Or did we decide not to do this already? I asked for it, but people with authority said no. It is all very weak, fragile and dangerous anyway - param or feature detect like the above. We would really need a proper feature detect mechanism, like text based in sysfs or something. I don't see why a param is fragile. Feature detect OTOH is almost always implemented in a fragile manner. Not if we had a text file in sysfs with names rather than numbers (getparam) without a central allocation authority. HAS_PARAM(FEATURE1) actually just tricks you into thinking it's fine, while actually you are just asking Do I have feature 48. What is feature 48? Who knows... some features never make it to upstream, some do and then get their HAS_PARAM number reallocated so it is really weak. Something like grep userptr /sys/kernel/debug/dri/0/i915_features, or stat /sys/kernel/debug/dri/0/i915/features/userptr would be much better. This way or the other, it seems to be there is not consensus with upstream gate keepers whether to have it or not. It was Chris actually who ripped it out. Personally I can see both arguments which is why I think we should come up with something better. Probably don't need the special function pointer yet since I don't think we can yet envision use cases which will require any kind of special handling. A simple has_userptr in bufmgr_gem will probably suffice. But I don't care too much either way. What do you mean? Don't add bo_alloc_userptr to the bufmgr. Just add the prototype to intel_bufmgr.h. Not sure, wouldn't like to make inconsistent. I'm pretty close to running this with most of the changes I had asked you for. I need to see how much of your igt test I can reuse now. Cool, so there is nothing for me to do. :) Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] libdrm_intel: Add support for userptr objects
On Fri, May 02, 2014 at 10:15:30AM -0700, Ben Widawsky wrote:
On Fri, May 02, 2014 at 11:27:45AM +0100, Tvrtko Ursulin wrote:
On 05/01/2014 07:47 PM, Ben Widawsky wrote:
On Wed, Feb 26, 2014 at 04:41:41PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
Allow userptr objects to be created and used via libdrm_intel.
At the moment tiling and mapping to GTT aperture is not supported
due hardware limitations across different generations and uncertainty
about its usefulness.
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
---
include/drm/i915_drm.h| 16 +
intel/intel_bufmgr.c | 13
intel/intel_bufmgr.h | 5 ++
intel/intel_bufmgr_gem.c | 154
+-
intel/intel_bufmgr_priv.h | 12 +++-
5 files changed, 198 insertions(+), 2 deletions(-)
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index 2f4eb8c..d32ef99 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -223,6 +223,7 @@ typedef struct _drm_i915_sarea {
#define DRM_I915_GEM_GET_CACHING0x30
#define DRM_I915_REG_READ 0x31
#define DRM_I915_GET_RESET_STATS0x32
+#define DRM_I915_GEM_USERPTR 0x34
#define DRM_IOCTL_I915_INIT DRM_IOW( DRM_COMMAND_BASE +
DRM_I915_INIT, drm_i915_init_t)
#define DRM_IOCTL_I915_FLUSHDRM_IO ( DRM_COMMAND_BASE +
DRM_I915_FLUSH)
@@ -273,6 +274,7 @@ typedef struct _drm_i915_sarea {
#define DRM_IOCTL_I915_GEM_CONTEXT_DESTROY DRM_IOW
(DRM_COMMAND_BASE + DRM_I915_GEM_CONTEXT_DESTROY, struct
drm_i915_gem_context_destroy)
#define DRM_IOCTL_I915_REG_READ DRM_IOWR
(DRM_COMMAND_BASE + DRM_I915_REG_READ, struct drm_i915_reg_read)
#define DRM_IOCTL_I915_GET_RESET_STATS DRM_IOWR
(DRM_COMMAND_BASE + DRM_I915_GET_RESET_STATS, struct
drm_i915_reset_stats)
+#define DRM_IOCTL_I915_GEM_USERPTR DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_USERPTR, struct drm_i915_gem_userptr)
/* Allow drivers to submit batchbuffers directly to hardware, relying
* on the security mechanisms provided by hardware.
@@ -498,6 +500,20 @@ struct drm_i915_gem_mmap_gtt {
__u64 offset;
};
+struct drm_i915_gem_userptr {
+ __u64 user_ptr;
+ __u64 user_size;
Adding alignment might be a safe bet.
H, at first I thought you are raising a good point. But then I don't
understand why I don't see any aligned types in
linux/include/uapi/drm/i915_drm.h ?
I meant an alignment field. I was thinking if some buffers have weird
alignment requirements for the GPU (but not the CPU) making that info
available to the kernel would be important.
We have a flags param and we can always extend the ioctl at the end, so
imo no need to preemptively add stuff we don't need yet.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] libdrm_intel: Add support for userptr objects
On 05/01/2014 07:47 PM, Ben Widawsky wrote:
On Wed, Feb 26, 2014 at 04:41:41PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
Allow userptr objects to be created and used via libdrm_intel.
At the moment tiling and mapping to GTT aperture is not supported
due hardware limitations across different generations and uncertainty
about its usefulness.
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
---
include/drm/i915_drm.h| 16 +
intel/intel_bufmgr.c | 13
intel/intel_bufmgr.h | 5 ++
intel/intel_bufmgr_gem.c | 154 +-
intel/intel_bufmgr_priv.h | 12 +++-
5 files changed, 198 insertions(+), 2 deletions(-)
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index 2f4eb8c..d32ef99 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -223,6 +223,7 @@ typedef struct _drm_i915_sarea {
#define DRM_I915_GEM_GET_CACHING 0x30
#define DRM_I915_REG_READ 0x31
#define DRM_I915_GET_RESET_STATS 0x32
+#define DRM_I915_GEM_USERPTR 0x34
#define DRM_IOCTL_I915_INIT DRM_IOW( DRM_COMMAND_BASE +
DRM_I915_INIT, drm_i915_init_t)
#define DRM_IOCTL_I915_FLUSH DRM_IO ( DRM_COMMAND_BASE +
DRM_I915_FLUSH)
@@ -273,6 +274,7 @@ typedef struct _drm_i915_sarea {
#define DRM_IOCTL_I915_GEM_CONTEXT_DESTROYDRM_IOW (DRM_COMMAND_BASE +
DRM_I915_GEM_CONTEXT_DESTROY, struct drm_i915_gem_context_destroy)
#define DRM_IOCTL_I915_REG_READ DRM_IOWR
(DRM_COMMAND_BASE + DRM_I915_REG_READ, struct drm_i915_reg_read)
#define DRM_IOCTL_I915_GET_RESET_STATSDRM_IOWR
(DRM_COMMAND_BASE + DRM_I915_GET_RESET_STATS, struct drm_i915_reset_stats)
+#define DRM_IOCTL_I915_GEM_USERPTR DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_USERPTR, struct drm_i915_gem_userptr)
/* Allow drivers to submit batchbuffers directly to hardware, relying
* on the security mechanisms provided by hardware.
@@ -498,6 +500,20 @@ struct drm_i915_gem_mmap_gtt {
__u64 offset;
};
+struct drm_i915_gem_userptr {
+ __u64 user_ptr;
+ __u64 user_size;
Adding alignment might be a safe bet.
H, at first I thought you are raising a good point. But then I don't
understand why I don't see any aligned types in
linux/include/uapi/drm/i915_drm.h ?
+ __u32 flags;
+#define I915_USERPTR_READ_ONLY 0x1
I'll eventually want something like:
#define I915_MIRRORED_GVA 0x2 /* Request the same GPU address */
Plenty of free flags. :)
+#define I915_USERPTR_UNSYNCHRONIZED 0x8000
+ /**
+ * Returned handle for the object.
+ *
+ * Object handles are nonzero.
+ */
+ __u32 handle;
+};
+
struct drm_i915_gem_set_domain {
/** Handle for the object */
__u32 handle;
diff --git a/intel/intel_bufmgr.c b/intel/intel_bufmgr.c
index 905556f..7f3d795 100644
--- a/intel/intel_bufmgr.c
+++ b/intel/intel_bufmgr.c
@@ -60,6 +60,19 @@ drm_intel_bo *drm_intel_bo_alloc_for_render(drm_intel_bufmgr
*bufmgr,
return bufmgr-bo_alloc_for_render(bufmgr, name, size, alignment);
}
+drm_intel_bo *drm_intel_bo_alloc_userptr(drm_intel_bufmgr *bufmgr,
+ const char *name, void *addr,
+ uint32_t tiling_mode,
+ uint32_t stride,
+ unsigned long size,
+ unsigned long flags)
+{
+ if (bufmgr-bo_alloc_userptr)
+ return bufmgr-bo_alloc_userptr(bufmgr, name, addr, tiling_mode,
+ stride, size, flags);
+ return NULL;
+}
+
drm_intel_bo *
drm_intel_bo_alloc_tiled(drm_intel_bufmgr *bufmgr, const char *name,
int x, int y, int cpp, uint32_t *tiling_mode,
diff --git a/intel/intel_bufmgr.h b/intel/intel_bufmgr.h
index 9383c72..be83a56 100644
--- a/intel/intel_bufmgr.h
+++ b/intel/intel_bufmgr.h
@@ -113,6 +113,11 @@ drm_intel_bo
*drm_intel_bo_alloc_for_render(drm_intel_bufmgr *bufmgr,
const char *name,
unsigned long size,
unsigned int alignment);
+drm_intel_bo *drm_intel_bo_alloc_userptr(drm_intel_bufmgr *bufmgr,
+ const char *name,
+ void *addr, uint32_t tiling_mode,
+ uint32_t stride, unsigned long size,
+ unsigned long flags);
drm_intel_bo *drm_intel_bo_alloc_tiled(drm_intel_bufmgr *bufmgr,
const char *name,
int x, int y, int cpp,
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 007a6d8..7cad945 100644
---
Re: [Intel-gfx] [RFC] libdrm_intel: Add support for userptr objects
On Fri, May 02, 2014 at 11:27:45AM +0100, Tvrtko Ursulin wrote:
On 05/01/2014 07:47 PM, Ben Widawsky wrote:
On Wed, Feb 26, 2014 at 04:41:41PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
Allow userptr objects to be created and used via libdrm_intel.
At the moment tiling and mapping to GTT aperture is not supported
due hardware limitations across different generations and uncertainty
about its usefulness.
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
---
include/drm/i915_drm.h| 16 +
intel/intel_bufmgr.c | 13
intel/intel_bufmgr.h | 5 ++
intel/intel_bufmgr_gem.c | 154
+-
intel/intel_bufmgr_priv.h | 12 +++-
5 files changed, 198 insertions(+), 2 deletions(-)
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index 2f4eb8c..d32ef99 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -223,6 +223,7 @@ typedef struct _drm_i915_sarea {
#define DRM_I915_GEM_GET_CACHING 0x30
#define DRM_I915_REG_READ 0x31
#define DRM_I915_GET_RESET_STATS 0x32
+#define DRM_I915_GEM_USERPTR 0x34
#define DRM_IOCTL_I915_INIT DRM_IOW( DRM_COMMAND_BASE +
DRM_I915_INIT, drm_i915_init_t)
#define DRM_IOCTL_I915_FLUSH DRM_IO ( DRM_COMMAND_BASE +
DRM_I915_FLUSH)
@@ -273,6 +274,7 @@ typedef struct _drm_i915_sarea {
#define DRM_IOCTL_I915_GEM_CONTEXT_DESTROYDRM_IOW
(DRM_COMMAND_BASE + DRM_I915_GEM_CONTEXT_DESTROY, struct
drm_i915_gem_context_destroy)
#define DRM_IOCTL_I915_REG_READ DRM_IOWR
(DRM_COMMAND_BASE + DRM_I915_REG_READ, struct drm_i915_reg_read)
#define DRM_IOCTL_I915_GET_RESET_STATSDRM_IOWR
(DRM_COMMAND_BASE + DRM_I915_GET_RESET_STATS, struct drm_i915_reset_stats)
+#define DRM_IOCTL_I915_GEM_USERPTR DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_USERPTR, struct drm_i915_gem_userptr)
/* Allow drivers to submit batchbuffers directly to hardware, relying
* on the security mechanisms provided by hardware.
@@ -498,6 +500,20 @@ struct drm_i915_gem_mmap_gtt {
__u64 offset;
};
+struct drm_i915_gem_userptr {
+ __u64 user_ptr;
+ __u64 user_size;
Adding alignment might be a safe bet.
H, at first I thought you are raising a good point. But then I don't
understand why I don't see any aligned types in
linux/include/uapi/drm/i915_drm.h ?
I meant an alignment field. I was thinking if some buffers have weird
alignment requirements for the GPU (but not the CPU) making that info
available to the kernel would be important.
As another potentially lacking field (which I happen not to care about
for the vmap/userptr style usage), we have certain buffers that need to
live within a certain part of the GPU address space.
I should mention that when I wrote the previous email, I didn't have
access to the latest kernel implementation when I sent the mail. I had
been assuming (because I've been wrapped up in my own, different world),
that the address space allocation was done at the time of the IOCTL. It
is not, and therefore, my request for the existing code does not make
sense.
With that though, I should describe my usecase briefly. I want the
ability to carve out the address space at the time of the IOCTL. As
such, I need to know some of these attributes.
+ __u32 flags;
+#define I915_USERPTR_READ_ONLY 0x1
I'll eventually want something like:
#define I915_MIRRORED_GVA 0x2 /* Request the same GPU address */
Plenty of free flags. :)
+#define I915_USERPTR_UNSYNCHRONIZED 0x8000
+ /**
+ * Returned handle for the object.
+ *
+ * Object handles are nonzero.
+ */
+ __u32 handle;
+};
+
struct drm_i915_gem_set_domain {
/** Handle for the object */
__u32 handle;
diff --git a/intel/intel_bufmgr.c b/intel/intel_bufmgr.c
index 905556f..7f3d795 100644
--- a/intel/intel_bufmgr.c
+++ b/intel/intel_bufmgr.c
@@ -60,6 +60,19 @@ drm_intel_bo
*drm_intel_bo_alloc_for_render(drm_intel_bufmgr *bufmgr,
return bufmgr-bo_alloc_for_render(bufmgr, name, size, alignment);
}
+drm_intel_bo *drm_intel_bo_alloc_userptr(drm_intel_bufmgr *bufmgr,
+ const char *name, void *addr,
+ uint32_t tiling_mode,
+ uint32_t stride,
+ unsigned long size,
+ unsigned long flags)
+{
+ if (bufmgr-bo_alloc_userptr)
+ return bufmgr-bo_alloc_userptr(bufmgr, name, addr, tiling_mode,
+ stride, size, flags);
+ return NULL;
+}
+
drm_intel_bo *
drm_intel_bo_alloc_tiled(drm_intel_bufmgr *bufmgr, const char *name,
int x, int y, int cpp, uint32_t *tiling_mode,
diff --git a/intel/intel_bufmgr.h b/intel/intel_bufmgr.h
index
Re: [Intel-gfx] [RFC] libdrm_intel: Add support for userptr objects
On Wed, Feb 26, 2014 at 04:41:41PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
Allow userptr objects to be created and used via libdrm_intel.
At the moment tiling and mapping to GTT aperture is not supported
due hardware limitations across different generations and uncertainty
about its usefulness.
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
---
include/drm/i915_drm.h| 16 +
intel/intel_bufmgr.c | 13
intel/intel_bufmgr.h | 5 ++
intel/intel_bufmgr_gem.c | 154
+-
intel/intel_bufmgr_priv.h | 12 +++-
5 files changed, 198 insertions(+), 2 deletions(-)
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index 2f4eb8c..d32ef99 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -223,6 +223,7 @@ typedef struct _drm_i915_sarea {
#define DRM_I915_GEM_GET_CACHING 0x30
#define DRM_I915_REG_READ0x31
#define DRM_I915_GET_RESET_STATS 0x32
+#define DRM_I915_GEM_USERPTR 0x34
#define DRM_IOCTL_I915_INIT DRM_IOW( DRM_COMMAND_BASE +
DRM_I915_INIT, drm_i915_init_t)
#define DRM_IOCTL_I915_FLUSH DRM_IO ( DRM_COMMAND_BASE +
DRM_I915_FLUSH)
@@ -273,6 +274,7 @@ typedef struct _drm_i915_sarea {
#define DRM_IOCTL_I915_GEM_CONTEXT_DESTROY DRM_IOW (DRM_COMMAND_BASE +
DRM_I915_GEM_CONTEXT_DESTROY, struct drm_i915_gem_context_destroy)
#define DRM_IOCTL_I915_REG_READ DRM_IOWR
(DRM_COMMAND_BASE + DRM_I915_REG_READ, struct drm_i915_reg_read)
#define DRM_IOCTL_I915_GET_RESET_STATS DRM_IOWR
(DRM_COMMAND_BASE + DRM_I915_GET_RESET_STATS, struct drm_i915_reset_stats)
+#define DRM_IOCTL_I915_GEM_USERPTR DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_USERPTR, struct drm_i915_gem_userptr)
/* Allow drivers to submit batchbuffers directly to hardware, relying
* on the security mechanisms provided by hardware.
@@ -498,6 +500,20 @@ struct drm_i915_gem_mmap_gtt {
__u64 offset;
};
+struct drm_i915_gem_userptr {
+ __u64 user_ptr;
+ __u64 user_size;
Adding alignment might be a safe bet.
+ __u32 flags;
+#define I915_USERPTR_READ_ONLY 0x1
I'll eventually want something like:
#define I915_MIRRORED_GVA 0x2 /* Request the same GPU address */
+#define I915_USERPTR_UNSYNCHRONIZED 0x8000
+ /**
+ * Returned handle for the object.
+ *
+ * Object handles are nonzero.
+ */
+ __u32 handle;
+};
+
struct drm_i915_gem_set_domain {
/** Handle for the object */
__u32 handle;
diff --git a/intel/intel_bufmgr.c b/intel/intel_bufmgr.c
index 905556f..7f3d795 100644
--- a/intel/intel_bufmgr.c
+++ b/intel/intel_bufmgr.c
@@ -60,6 +60,19 @@ drm_intel_bo
*drm_intel_bo_alloc_for_render(drm_intel_bufmgr *bufmgr,
return bufmgr-bo_alloc_for_render(bufmgr, name, size, alignment);
}
+drm_intel_bo *drm_intel_bo_alloc_userptr(drm_intel_bufmgr *bufmgr,
+ const char *name, void *addr,
+ uint32_t tiling_mode,
+ uint32_t stride,
+ unsigned long size,
+ unsigned long flags)
+{
+ if (bufmgr-bo_alloc_userptr)
+ return bufmgr-bo_alloc_userptr(bufmgr, name, addr, tiling_mode,
+ stride, size, flags);
+ return NULL;
+}
+
drm_intel_bo *
drm_intel_bo_alloc_tiled(drm_intel_bufmgr *bufmgr, const char *name,
int x, int y, int cpp, uint32_t *tiling_mode,
diff --git a/intel/intel_bufmgr.h b/intel/intel_bufmgr.h
index 9383c72..be83a56 100644
--- a/intel/intel_bufmgr.h
+++ b/intel/intel_bufmgr.h
@@ -113,6 +113,11 @@ drm_intel_bo
*drm_intel_bo_alloc_for_render(drm_intel_bufmgr *bufmgr,
const char *name,
unsigned long size,
unsigned int alignment);
+drm_intel_bo *drm_intel_bo_alloc_userptr(drm_intel_bufmgr *bufmgr,
+ const char *name,
+ void *addr, uint32_t tiling_mode,
+ uint32_t stride, unsigned long size,
+ unsigned long flags);
drm_intel_bo *drm_intel_bo_alloc_tiled(drm_intel_bufmgr *bufmgr,
const char *name,
int x, int y, int cpp,
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 007a6d8..7cad945 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -182,6 +182,11 @@ struct _drm_intel_bo_gem {
void *mem_virtual;
/** GTT virtual address for the buffer, saved across map/unmap cycles */
void *gtt_virtual;
[Intel-gfx] [RFC] libdrm_intel: Add support for userptr objects
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
Allow userptr objects to be created and used via libdrm_intel.
At the moment tiling and mapping to GTT aperture is not supported
due hardware limitations across different generations and uncertainty
about its usefulness.
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
---
include/drm/i915_drm.h| 16 +
intel/intel_bufmgr.c | 13
intel/intel_bufmgr.h | 5 ++
intel/intel_bufmgr_gem.c | 154 +-
intel/intel_bufmgr_priv.h | 12 +++-
5 files changed, 198 insertions(+), 2 deletions(-)
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index 2f4eb8c..d32ef99 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -223,6 +223,7 @@ typedef struct _drm_i915_sarea {
#define DRM_I915_GEM_GET_CACHING 0x30
#define DRM_I915_REG_READ 0x31
#define DRM_I915_GET_RESET_STATS 0x32
+#define DRM_I915_GEM_USERPTR 0x34
#define DRM_IOCTL_I915_INITDRM_IOW( DRM_COMMAND_BASE +
DRM_I915_INIT, drm_i915_init_t)
#define DRM_IOCTL_I915_FLUSH DRM_IO ( DRM_COMMAND_BASE +
DRM_I915_FLUSH)
@@ -273,6 +274,7 @@ typedef struct _drm_i915_sarea {
#define DRM_IOCTL_I915_GEM_CONTEXT_DESTROY DRM_IOW (DRM_COMMAND_BASE +
DRM_I915_GEM_CONTEXT_DESTROY, struct drm_i915_gem_context_destroy)
#define DRM_IOCTL_I915_REG_READDRM_IOWR
(DRM_COMMAND_BASE + DRM_I915_REG_READ, struct drm_i915_reg_read)
#define DRM_IOCTL_I915_GET_RESET_STATS DRM_IOWR (DRM_COMMAND_BASE +
DRM_I915_GET_RESET_STATS, struct drm_i915_reset_stats)
+#define DRM_IOCTL_I915_GEM_USERPTR DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_USERPTR, struct drm_i915_gem_userptr)
/* Allow drivers to submit batchbuffers directly to hardware, relying
* on the security mechanisms provided by hardware.
@@ -498,6 +500,20 @@ struct drm_i915_gem_mmap_gtt {
__u64 offset;
};
+struct drm_i915_gem_userptr {
+ __u64 user_ptr;
+ __u64 user_size;
+ __u32 flags;
+#define I915_USERPTR_READ_ONLY 0x1
+#define I915_USERPTR_UNSYNCHRONIZED 0x8000
+ /**
+ * Returned handle for the object.
+ *
+ * Object handles are nonzero.
+ */
+ __u32 handle;
+};
+
struct drm_i915_gem_set_domain {
/** Handle for the object */
__u32 handle;
diff --git a/intel/intel_bufmgr.c b/intel/intel_bufmgr.c
index 905556f..7f3d795 100644
--- a/intel/intel_bufmgr.c
+++ b/intel/intel_bufmgr.c
@@ -60,6 +60,19 @@ drm_intel_bo *drm_intel_bo_alloc_for_render(drm_intel_bufmgr
*bufmgr,
return bufmgr-bo_alloc_for_render(bufmgr, name, size, alignment);
}
+drm_intel_bo *drm_intel_bo_alloc_userptr(drm_intel_bufmgr *bufmgr,
+ const char *name, void *addr,
+ uint32_t tiling_mode,
+ uint32_t stride,
+ unsigned long size,
+ unsigned long flags)
+{
+ if (bufmgr-bo_alloc_userptr)
+ return bufmgr-bo_alloc_userptr(bufmgr, name, addr, tiling_mode,
+ stride, size, flags);
+ return NULL;
+}
+
drm_intel_bo *
drm_intel_bo_alloc_tiled(drm_intel_bufmgr *bufmgr, const char *name,
int x, int y, int cpp, uint32_t *tiling_mode,
diff --git a/intel/intel_bufmgr.h b/intel/intel_bufmgr.h
index 9383c72..be83a56 100644
--- a/intel/intel_bufmgr.h
+++ b/intel/intel_bufmgr.h
@@ -113,6 +113,11 @@ drm_intel_bo
*drm_intel_bo_alloc_for_render(drm_intel_bufmgr *bufmgr,
const char *name,
unsigned long size,
unsigned int alignment);
+drm_intel_bo *drm_intel_bo_alloc_userptr(drm_intel_bufmgr *bufmgr,
+ const char *name,
+ void *addr, uint32_t tiling_mode,
+ uint32_t stride, unsigned long size,
+ unsigned long flags);
drm_intel_bo *drm_intel_bo_alloc_tiled(drm_intel_bufmgr *bufmgr,
const char *name,
int x, int y, int cpp,
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 007a6d8..7cad945 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -182,6 +182,11 @@ struct _drm_intel_bo_gem {
void *mem_virtual;
/** GTT virtual address for the buffer, saved across map/unmap cycles */
void *gtt_virtual;
+ /**
+* Virtual address of the buffer allocated by user, used for userptr
+* objects only.
+*/
+ void *user_virtual;
int map_count;
drmMMListHead vma_list;
@@ -221,6 +226,11 @@ struct
