* [RFC] drm/i195: Add flag to enable virtual mappings above 4Gb
@ 2015-03-18 16:57 Nick Hoath
2015-03-18 17:08 ` Tvrtko Ursulin
2015-03-19 16:29 ` Daniel Vetter
0 siblings, 2 replies; 3+ messages in thread
From: Nick Hoath @ 2015-03-18 16:57 UTC (permalink / raw)
To: intel-gfx
Wa32bitGeneralStateOffset & Wa32bitInstructionBaseOffset hardware
workarounds require that GeneralStateOffset & InstructionBaseOffset
are restricted to a 32 bit address space.
This is a preparatory patch prior to supporting 64bit virtual memory
allocations.
Allow the user space to flag that a mapping can occur beyond
the 32bit limit. This allows backward compatibility and user space
drivers that haven't been enhanced to support these workarounds to
function.
Signed-off-by: Nick Hoath <nicholas.hoath@intel.com>
---
drivers/gpu/drm/i915/i915_drv.h | 6 ++++++
drivers/gpu/drm/i915/i915_gem.c | 18 +++++++++++++++---
include/uapi/drm/i915_drm.h | 7 ++++++-
3 files changed, 27 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3cc0196..1e6fc1d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2066,6 +2066,12 @@ struct drm_i915_gem_object {
unsigned int has_dma_mapping:1;
unsigned int frontbuffer_bits:INTEL_FRONTBUFFER_BITS;
+
+ /**
+ * If the object should be mapped in to the bottom 4Gb
+ * memory space only, then this flag should not be set
+ */
+ unsigned int hi_mem:1;
struct sg_table *pages;
int pages_pin_count;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 61134ab..efa782c 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -395,7 +395,9 @@ static int
i915_gem_create(struct drm_file *file,
struct drm_device *dev,
uint64_t size,
- uint32_t *handle_p)
+ uint32_t *handle_p,
+ uint32_t flags
+ )
{
struct drm_i915_gem_object *obj;
int ret;
@@ -410,6 +412,9 @@ i915_gem_create(struct drm_file *file,
if (obj == NULL)
return -ENOMEM;
+ if (flags & I915_CREATE_FLAG_HI_MEM)
+ obj->hi_mem = 1;
+
ret = drm_gem_handle_create(file, &obj->base, &handle);
/* drop reference from allocate - handle holds it now */
drm_gem_object_unreference_unlocked(&obj->base);
@@ -429,7 +434,8 @@ i915_gem_dumb_create(struct drm_file *file,
args->pitch = ALIGN(args->width * DIV_ROUND_UP(args->bpp, 8), 64);
args->size = args->pitch * args->height;
return i915_gem_create(file, dev,
- args->size, &args->handle);
+ args->size, &args->handle,
+ I915_CREATE_FLAG_HI_MEM);
}
/**
@@ -440,9 +446,10 @@ i915_gem_create_ioctl(struct drm_device *dev, void *data,
struct drm_file *file)
{
struct drm_i915_gem_create *args = data;
return i915_gem_create(file, dev,
- args->size, &args->handle);
+ args->size, &args->handle,
+ args->flags);
}
static inline int
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 6eed16b..eb2e7d9 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -428,6 +428,8 @@ struct drm_i915_gem_init {
__u64 gtt_end;
};
+#define I915_CREATE_FLAG_HI_MEM 0x00000001
+
struct drm_i915_gem_create {
/**
* Requested size for the object.
@@ -441,7 +443,10 @@ struct drm_i915_gem_create {
* Object handles are nonzero.
*/
__u32 handle;
- __u32 pad;
+ /**
+ * Object creation flags
+ */
+ __u32 flags;
};
struct drm_i915_gem_pread {
--
2.1.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 3+ messages in thread* Re: [RFC] drm/i195: Add flag to enable virtual mappings above 4Gb
2015-03-18 16:57 [RFC] drm/i195: Add flag to enable virtual mappings above 4Gb Nick Hoath
@ 2015-03-18 17:08 ` Tvrtko Ursulin
2015-03-19 16:29 ` Daniel Vetter
1 sibling, 0 replies; 3+ messages in thread
From: Tvrtko Ursulin @ 2015-03-18 17:08 UTC (permalink / raw)
To: Nick Hoath, intel-gfx
On 03/18/2015 04:57 PM, Nick Hoath wrote:
> Wa32bitGeneralStateOffset & Wa32bitInstructionBaseOffset hardware
> workarounds require that GeneralStateOffset & InstructionBaseOffset
> are restricted to a 32 bit address space.
>
> This is a preparatory patch prior to supporting 64bit virtual memory
> allocations.
>
> Allow the user space to flag that a mapping can occur beyond
> the 32bit limit. This allows backward compatibility and user space
> drivers that haven't been enhanced to support these workarounds to
> function.
Just on the naming..
Maybe the whole thing would better be named "full mem", "full range" or
something like that?
"Hi mem", especially since the name is used in the userspace API has so
much historical baggage meaning it needs to be _only_ in the special
high memory range.
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [RFC] drm/i195: Add flag to enable virtual mappings above 4Gb
2015-03-18 16:57 [RFC] drm/i195: Add flag to enable virtual mappings above 4Gb Nick Hoath
2015-03-18 17:08 ` Tvrtko Ursulin
@ 2015-03-19 16:29 ` Daniel Vetter
1 sibling, 0 replies; 3+ messages in thread
From: Daniel Vetter @ 2015-03-19 16:29 UTC (permalink / raw)
To: Nick Hoath; +Cc: intel-gfx
On Wed, Mar 18, 2015 at 04:57:53PM +0000, Nick Hoath wrote:
> Wa32bitGeneralStateOffset & Wa32bitInstructionBaseOffset hardware
> workarounds require that GeneralStateOffset & InstructionBaseOffset
> are restricted to a 32 bit address space.
>
> This is a preparatory patch prior to supporting 64bit virtual memory
> allocations.
>
> Allow the user space to flag that a mapping can occur beyond
> the 32bit limit. This allows backward compatibility and user space
> drivers that haven't been enhanced to support these workarounds to
> function.
>
> Signed-off-by: Nick Hoath <nicholas.hoath@intel.com>
Because of the libdrm buffer cache being opaque to the different users
I don't see how a flag set at create time will work.
Also on a very quick look all userspace is still nice and relocates
indirect state with I915_GEM_DOMAIN_INSTRUCTION (well except no-reloc
userspace where this is lost). Can't we just piggy-pack on top of that?
Creative abuse of established abi ;-) But that's easy to resolve with an
additional bit for no-reloc in execbuf to signal that it's indirect state
and one flag to allow it.
Upside of that approach is that we don't need to change anything in
userspace, except SNA (atm the only no-reloc user).
And yeah I think for this one here we need to have all the support rolled
out for everyone to make sure it actually works ...
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2015-03-19 16:27 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-03-18 16:57 [RFC] drm/i195: Add flag to enable virtual mappings above 4Gb Nick Hoath
2015-03-18 17:08 ` Tvrtko Ursulin
2015-03-19 16:29 ` Daniel Vetter
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox