Hi,
On 06/18/2014 09:57 AM, sonika.jin...@intel.com wrote:
[snip]
+static int intel_primary_plane_set_property(struct drm_plane *plane,
+ struct drm_property *prop,
+ uint64_t val)
+{
+ struct drm_device *dev = plane-dev;
Hi,
On 06/18/2014 09:57 AM, sonika.jin...@intel.com wrote:
[snip]
+static int intel_primary_plane_set_property(struct drm_plane *plane,
+ struct drm_property *prop,
+ uint64_t val)
+{
+ struct drm_device *dev = plane-dev;
On 06/27/2014 11:49 AM, Jindal, Sonika wrote:
On 6/27/2014 4:04 PM, Tvrtko Ursulin wrote:
Hi,
On 06/18/2014 09:57 AM, sonika.jin...@intel.com wrote:
[snip]
+static int intel_primary_plane_set_property(struct drm_plane *plane,
+struct drm_property *prop
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
On 07/10/2014 10:21 AM, Chris Wilson wrote:
Whilst I strongly advise against doing so for the implicit coherency
issues between the multiple buffer objects accessing the same backing
store, it nevertheless is a valid use case, akin to mmaping the same
file multiple times.
The reason why we
On 07/10/2014 10:21 AM, Chris Wilson wrote:
Jerome Glisse pointed out that get_user_pages() does not synchronize
with concurrent invalidations of the VMA. As such if the backing vma is
changed whilst the pages for the object are being grabbed for use by the
GPU, we may end up with a random
);
+ reset_handle_ptr();
+
return 0;
}
Reviewed-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
)
+ test_forked_access(fd);
+
igt_subtest(forbidden-operations)
test_forbidden_ops(fd);
Reviewed-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http
of the tree to 1.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Tvrtko Ursulin tvrtko.ursu...@linux.intel.com
---
drivers/gpu/drm/i915/i915_gem_userptr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c
b/drivers/gpu/drm
On 07/11/2014 12:06 PM, Chris Wilson wrote:
On Fri, Jul 11, 2014 at 12:00:26PM +0100, Tvrtko Ursulin wrote:
On 07/11/2014 11:28 AM, Chris Wilson wrote:
During the range invalidate, we walk the list of buffers associated with
the mmu_notifer and find the ones that overlap the range
On 07/11/2014 12:35 PM, Chris Wilson wrote:
On Fri, Jul 11, 2014 at 12:31:12PM +0100, Tvrtko Ursulin wrote:
On 07/11/2014 12:06 PM, Chris Wilson wrote:
On Fri, Jul 11, 2014 at 12:00:26PM +0100, Tvrtko Ursulin wrote:
But it will be interesting to know what code managed to trigger this
race
++;
}
num_test_children = 0;
+ if (err)
+ igt_fail(err);
}
/* exit handler code */
Looks fine.
Reviewed-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org
On 07/11/2014 03:02 PM, Daniel Vetter wrote:
On Fri, Jul 11, 2014 at 12:06:02PM +0100, Chris Wilson wrote:
On Fri, Jul 11, 2014 at 12:00:26PM +0100, Tvrtko Ursulin wrote:
On 07/11/2014 11:28 AM, Chris Wilson wrote:
During the range invalidate, we walk the list of buffers associated
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
Userptr v23 was not thread safe against memory map operations and object
creation from separate threads. MMU notifier callback would get triggered
on a partially constructed object causing a NULL pointer dereference.
This test excercises that path
On 07/14/2014 11:34 AM, Chris Wilson wrote:
On Mon, Jul 14, 2014 at 11:03:26AM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
Userptr v23 was not thread safe against memory map operations and object
creation from separate threads. MMU notifier callback would get
On 07/14/2014 02:07 PM, Chris Wilson wrote:
You don't have any cancellation points in the loop. (mmap may or may not
be, it is not required to be.)
But rather than use a global, just pass a pointer to a local struct.
It doesn't need both a cancellation point and a flag. Should I just
add
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
Userptr v23 was not thread safe against memory map operations and object
creation from separate threads. MMU notifier callback would get triggered
on a partially constructed object causing a NULL pointer dereference.
This test excercises that path
On 07/18/2014 10:20 AM, Gore, Tim wrote:
Unfortunately Android threads do not support cancel and testcancel, so this
Test cannot build for android.
Do we really need a cancellation point, since we don't need to cancel the
thread.
Tvrtko's original solution seemed workable, if a bit less
Git detection probably belongs to configure.ac with the version.h
rule reworked accordingly. Feel free to drop this if someone
wants to spend time on a better fix.
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
---
Makefile.am | 4 +++-
1 file changed, 3 insertions(+), 1 deletion
Two parts to the fix:
1. Do not use pthread_cancel since not available on Android.
2. Do not assert in the thread since that does not get propagated
to the process. Rather pass out any failures so we know test
did not work as expected.
Signed-off-by: Tvrtko Ursulin tvrtko.ursu
copy() blit helper assumes a certain object size much larger than a page size.
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
Cc: Chris Wilson ch...@chris-wilson.co.uk
---
tests/gem_userptr_blits.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git
Hardcoding has upsides and downsides.
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
---
benchmarks/gem_userptr_benchmark.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/benchmarks/gem_userptr_benchmark.c
b/benchmarks/gem_userptr_benchmark.c
index bdfce12..4d7442b
Larger performance impact is expected with first draft of the kernel
implementation for overlapping objects so this is just to confirm that.
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
Cc: Chris Wilson ch...@chris-wilson.co.uk
---
benchmarks/gem_userptr_benchmark.c | 97
: Compile for mmu-notifiers after tweaking
v3: Rename is_linear/has_linear
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Li, Victor Y victor.y...@intel.com
Cc: Kelley, Sean V sean.v.kel...@intel.com
Cc: Tvrtko Ursulin tvrtko.ursu...@linux.intel.com
Cc: Gong, Zhipeng zhipeng.g...@intel.com
On 07/23/2014 03:34 PM, Daniel Vetter wrote:
On Wed, Jul 23, 2014 at 02:23:53PM +0100, Tvrtko Ursulin wrote:
I think it would be good to add some more tests to cover the tracking
handover between the interval tree and linear list to ensure invalidation
still works correctly in non-trivial
Just tell the test to expect them to work then.
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
Cc: Chris Wilson ch...@chris-wilson.co.uk
---
tests/gem_userptr_blits.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/gem_userptr_blits.c b/tests/gem_userptr_blits.c
On 07/21/2014 01:21 PM, Chris Wilson wrote:
During release of the GEM object we hold the struct_mutex. As the
object may be holding onto the last reference for the task-mm,
calling mmput() may trigger exit_mmap() which close the vma
which will call drm_gem_vm_close() and attempt to reacquire
On 07/25/2014 10:37 AM, Daniel Vetter wrote:
On Fri, Jul 25, 2014 at 10:17:26AM +0100, Chris Wilson wrote:
On Fri, Jul 25, 2014 at 11:06:38AM +0200, Daniel Vetter wrote:
On Fri, Jul 25, 2014 at 10:00:19AM +0100, tim.g...@intel.com wrote:
From: Tim Gore tim.g...@intel.com
On 07/23/2014 06:15 PM, Chris Wilson wrote:
On Wed, Jul 23, 2014 at 05:39:49PM +0100, Tvrtko Ursulin wrote:
On 07/21/2014 01:21 PM, Chris Wilson wrote:
+ mn = i915_mmu_notifier_get(obj-userptr.mm);
+ if (IS_ERR(mn))
+ return PTR_ERR(mn);
Very minor, but I would
Hi Jesse,
On 07/31/2014 07:58 PM, Jesse Barnes wrote:
Expose an ioctl to create Android fences based on the Android sync point
infrastructure (which in turn is based on DMA-buf fences). Just a
sketch at this point, no testing has been done.
There are a couple of goals here:
1) allow
.
Reviewed-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
Thanks,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
No need for the old test case once the new one was added.
v2:
* Just rebase for lib/ reorganization.
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
Reviewed-by: Brad Volkin bradley.d.vol...@intel.com
---
tests/.gitignore | 1
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
This adds a small benchmark for the new userptr functionality.
Apart from basic surface creation and destruction, also tested is the
impact of having userptr surfaces in the process address space. Reason
for that is the impact of MMU notifiers
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
A set of userptr test cases to support the new feature.
For the eviction and swapping stress testing I have extracted
some common behaviour from gem_evict_everything and made both
test cases use it to avoid duplicating the code.
Both unsynchronized
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
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
Hi Brad,
On 04/28/2014 04:22 PM, bradley.d.vol...@intel.com wrote:
[snip]
- BUG_ON(!validate_cmds_sorted(ring));
+ BUG_ON(!validate_cmds_sorted(ring, cmd_tables, cmd_table_count));
BUG_ON(!validate_regs_sorted(ring));
+
+ BUG_ON(init_hash_table(ring, cmd_tables,
On 05/08/2014 12:44 PM, Damien Lespiau wrote:
On Thu, May 08, 2014 at 10:56:05AM +0100, Tvrtko Ursulin wrote:
Hi Brad,
On 04/28/2014 04:22 PM, bradley.d.vol...@intel.com wrote:
[snip]
- BUG_ON(!validate_cmds_sorted(ring));
+ BUG_ON(!validate_cmds_sorted(ring, cmd_tables
On 05/08/2014 02:02 PM, Damien Lespiau wrote:
On Thu, May 08, 2014 at 01:25:33PM +0100, Tvrtko Ursulin wrote:
On 05/08/2014 12:44 PM, Damien Lespiau wrote:
On Thu, May 08, 2014 at 10:56:05AM +0100, Tvrtko Ursulin wrote:
Hi Brad,
On 04/28/2014 04:22 PM, bradley.d.vol...@intel.com wrote
On 04/28/2014 04:22 PM, bradley.d.vol...@intel.com wrote:
From: Brad Volkin bradley.d.vol...@intel.com
For clients that submit large batch buffers the command parser has
a substantial impact on performance. On my HSW ULT system performance
drops as much as ~20% on some tests. Most of the time
On 05/08/2014 04:27 PM, Volkin, Bradley D wrote:
On Thu, May 08, 2014 at 02:56:05AM -0700, Tvrtko Ursulin wrote:
Hi Brad,
On 04/28/2014 04:22 PM, bradley.d.vol...@intel.com wrote:
[snip]
- BUG_ON(!validate_cmds_sorted(ring));
+ BUG_ON(!validate_cmds_sorted(ring, cmd_tables
a BUG_ON() with an error return (Tvrtko, Ville)
commit message improvements
Signed-off-by: Brad Volkin bradley.d.vol...@intel.com
Reviewed-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
Hi Brad,
On 06/18/2014 05:36 PM, bradley.d.vol...@intel.com wrote:
From: Brad Volkin bradley.d.vol...@intel.com
This adds a small module for managing a pool of batch buffers.
The only current use case is for the command parser, as described
in the kerneldoc in the patch. The code is simple,
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
---
include/drm/i915_drm.h | 16
1 file changed, 16 insertions(+)
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index 2f4eb8c..bf75596 100644
--- a/include/drm
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.
v2: Improved error handling
On 06/19/2014 06:35 PM, Volkin, Bradley D wrote:
On Thu, Jun 19, 2014 at 02:48:29AM -0700, Tvrtko Ursulin wrote:
Hi Brad,
On 06/18/2014 05:36 PM, bradley.d.vol...@intel.com wrote:
From: Brad Volkin bradley.d.vol...@intel.com
This adds a small module for managing a pool of batch buffers
On 06/20/2014 04:30 PM, Volkin, Bradley D wrote:
On Fri, Jun 20, 2014 at 06:25:56AM -0700, Tvrtko Ursulin wrote:
On 06/19/2014 06:35 PM, Volkin, Bradley D wrote:
On Thu, Jun 19, 2014 at 02:48:29AM -0700, Tvrtko Ursulin wrote:
Hi Brad,
On 06/18/2014 05:36 PM, bradley.d.vol...@intel.com
On 06/25/2014 01:57 PM, Damien Lespiau wrote:
On Wed, Jun 25, 2014 at 12:46:57PM +0100, Siluvery, Arun wrote:
On 25/06/2014 12:14, Damien Lespiau wrote:
On Wed, Jun 25, 2014 at 11:51:33AM +0100, Damien Lespiau wrote:
(This is not necessarily things one would need to take into account for
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
Tests depend on assertions being enabled since they can, and do,
contain actual test steps. They are also mandatory for ensuring
sane test case behaviour.
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
---
lib/check-ndebug.h | 3 +++
tests
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
We do not have GLib there so it does not build.
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
---
tests/Android.mk | 1 +
1 file changed, 1 insertion(+)
diff --git a/tests/Android.mk b/tests/Android.mk
index ec64acd..c96f30a 100644
On Tue, 2013-12-03 at 15:40 +, Chris Wilson wrote:
On Tue, Dec 03, 2013 at 03:35:41PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
We do not have GLib there so it does not build.
What dependence on GLib would that be?
Haven't looked further than
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
This reverts commit a031a1bf93b828585e7147f06145fc5030814547.
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
Conflicts:
lib/drmtest.c
---
lib/drmtest.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/lib/drmtest.c b
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
It was observed both on Linux and Android that tests which
fork can sometimes hang failing to terminate child
processes.
This was eventually tracked down to race conditions in C
library implementations, all with regards to caching of
PID/TGID and TID
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
Various C library implementations have various races with regards
to caching getpid() or TID inside pthread_kill() implementations.
For example see clone(2) glibc man page and pthread_kill
Bionic C library source.
Work around that by making sure
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
Don't see that it causes a problem but it looks it was intended
to use bo_count at these places.
Also using count to determine number of processes does not make
sense unless thousands of cores.
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
Hi,
On Fri, 2013-12-06 at 08:55 +0800, Xiang, Haihao wrote:
+++ b/tests/gem_media_fill.c
...
+#include cairo.h
It does not look like this include is needed and it is troublesome on
Android.
Regards,
Tvrtko
___
Intel-gfx mailing list
On Fri, 2013-12-06 at 13:12 +0100, Daniel Vetter wrote:
On Fri, Dec 06, 2013 at 11:37:49AM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
Don't see that it causes a problem but it looks it was intended
to use bo_count at these places.
Also using count
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
Causes trouble for Android builds.
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
---
tests/gem_media_fill.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/tests/gem_media_fill.c b/tests/gem_media_fill.c
index 40b391d..b458ded 100644
On Fri, 2013-12-06 at 14:46 +0100, Daniel Vetter wrote:
On Fri, Dec 06, 2013 at 12:33:28PM +, Tvrtko Ursulin wrote:
On Fri, 2013-12-06 at 13:12 +0100, Daniel Vetter wrote:
On Fri, Dec 06, 2013 at 11:37:49AM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
Looks like filter-out macro gets silently unhappy about an undefined variable.
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
---
tools/Android.mk | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/Android.mk b/tools
On 01/22/2014 11:21 AM, Chris Wilson wrote:
On Wed, Jan 22, 2014 at 10:41:38AM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
A set of userptr test cases to support the new feature.
Oh, and another thing...
I guess we will want some benchmarks for mmu_notifier
On 01/22/2014 11:38 AM, Tvrtko Ursulin wrote:
On 01/22/2014 11:21 AM, Chris Wilson wrote:
On Wed, Jan 22, 2014 at 10:41:38AM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
A set of userptr test cases to support the new feature.
Oh, and another thing...
I
Hi,
On 01/29/2014 08:11 PM, Daniel Vetter wrote:
On Wed, Jan 29, 2014 at 01:30:54PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
A set of userptr test cases to support the new feature.
[snip]
Minor thing on patch style: I'd split this up into 3 parts
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
This patch series replaces the old vmap with the new userptr test case.
Some refactoring precedes the actual introduction to pull out code
from gem_evict_everything which is useful for both.
Test case at the moment tests dmabuf sharing of userptr
On 01/29/2014 08:34 PM, Daniel Vetter wrote:
Actually I've found something else to complain about:
On Tue, Jan 28, 2014 at 2:16 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
+#define I915_USERPTR_READ_ONLY 0x1
This smells like an insta-root-exploit:
1. mmap /lib/ld-linux.so as read-only
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
Make sure selection loop does not generate duplicates
when it picks a subset of objects for a single exec buffer.
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
---
tests/eviction_common.c | 7 +++
1 file changed, 7 insertions(+)
diff
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
A set of userptr test cases to support the new feature.
For the eviction and swapping stress testing I have extracted
some common behaviour from gem_evict_everything and made both
test cases use it to avoid duplicating the code.
Both unsynchronized
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
In preparation for userptr test we move the eviction logic
into a common file so it can be used from both test cases.
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
---
tests/eviction_common.c | 235
On 01/30/2014 11:06 AM, Chris Wilson wrote:
On Wed, Jan 29, 2014 at 10:58:48PM +0100, Daniel Vetter wrote:
On Wed, Jan 29, 2014 at 10:53 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
On Wed, Jan 29, 2014 at 09:25:51PM +0100, Daniel Vetter wrote:
So originally I've thought we need this due
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
No need for the old test case once the new one was added.
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
---
tests/.gitignore | 1 -
tests/Makefile.sources | 1 -
tests/gem_vmap_blits.c | 344
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
This adds a small benchmark for the new userptr functionality.
Apart from basic surface creation and destruction, also tested is the
impact of having userptr surfaces in the process address space. Reason
for that is the impact of MMU notifiers
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
A simple userptr benchmark measuring creation and destruction of userptr
surfaces and also impact of having a different number of them in the
process address space.
Example test output from i7-4550U running Android is below.
Questions, comments
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
This adds a small benchmark for the new userptr functionality.
Apart from basic surface creation and destruction, also tested is the
impact of having userptr surfaces in the process address space. Reason
for that is the impact of MMU notifiers
On 02/05/2014 05:51 PM, Daniel Vetter wrote:
On Wed, Feb 05, 2014 at 05:33:06PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
This adds a small benchmark for the new userptr functionality.
Apart from basic surface creation and destruction, also tested
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
This adds a small benchmark for the new userptr functionality.
Apart from basic surface creation and destruction, also tested is the
impact of having userptr surfaces in the process address space. Reason
for that is the impact of MMU notifiers
On 02/21/2014 06:45 PM, Chris Wilson wrote:
[snip]
v20: Refuse to implement read-only support until we have the required
infrastructure - but reserve the bit in flags for future use.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Tvrtko Ursulin tvrtko.ursu...@linux.intel.com
Cc
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
A set of userptr test cases to support the new feature.
For the eviction and swapping stress testing I have extracted
some common behaviour from gem_evict_everything and made both
test cases use it to avoid duplicating the code.
Both unsynchronized
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
This patch series replaces the old vmap with the new userptr test case
and also adds a benchmark for the new feature.
Tested against version 20 of the kernel patch.
Tvrtko Ursulin (3):
tests/gem_userptr_blits: Expanded userptr test cases
tests
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
No need for the old test case once the new one was added.
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
---
tests/.gitignore | 1 -
tests/Makefile.sources | 1 -
tests/gem_vmap_blits.c | 344
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
to support them at the moment.
v20: Refuse to implement read-only support until we have the required
infrastructure - but reserve the bit in flags for future use.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Tvrtko Ursulin tvrtko.ursu...@linux.intel.com
Cc: Gong, Zhipeng zhipeng.g
On 03/05/2014 02:48 PM, Chris Wilson wrote:
On Wed, Feb 26, 2014 at 04:17:43PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
A set of userptr test cases to support the new feature.
For the eviction and swapping stress testing I have extracted
some common
On 03/14/2014 07:18 AM, Daniel Vetter wrote:
[snip]
+ * # Magic Control Blocks
+ *
+ * i-g-t makes heavy use of C macros which serve as magic control blocks. They
+ * work fairly well and transparently but since C doesn't have full-blown
+ * closures there are caveats:
+ *
+ * - Asynchronous
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
This adds a small benchmark for the new userptr functionality.
Apart from basic surface creation and destruction, also tested is the
impact of having userptr surfaces in the process address space. Reason
for that is the impact of MMU notifiers
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
This patch series replaces the old vmap with the new userptr test case
and also adds a benchmark for the new feature.
Tested against version 21 of the kernel patch.
Tvrtko Ursulin (3):
tests/gem_userptr_blits: Expanded userptr test cases
tests
On 03/19/2014 09:54 PM, Chris Wilson wrote:
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 7a01911c16f8..a6ceb2c6f36d 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -417,13 +417,19 @@
...@chris-wilson.co.uk
Cc: Ben Widawsky benjamin.widaw...@intel.com
Cc: Timo Aaltonen tjaal...@ubuntu.com
Cc: Tvrtko Ursulin tvrtko.ursu...@linux.intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/i915_gpu_error.c | 2 +-
drivers/gpu/drm/i915/i915_irq.c
On 03/21/2014 10:14 AM, Chris Wilson wrote:
On Fri, Mar 21, 2014 at 10:03:38AM +, Tvrtko Ursulin wrote:
On 03/20/2014 09:48 PM, Chris Wilson wrote:
As Broadwell has an increased virtual address size, it requires more
than 32 bits to store offsets into its address space. This includes
On 03/21/2014 12:00 PM, Chris Wilson wrote:
On Fri, Mar 21, 2014 at 10:50:05AM +, Tvrtko Ursulin wrote:
No, think you misunderstood me. I said slightly more defensive
just in the sense that in case of weird hardware failures you have a
potentially infinite loop now, where you don't really
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
Looks like there are some redundant lines in the main loop of
i915_gem_object_get_pages_gtt.
I haven't tested this so just RFC please.
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
Cc: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915
On 03/26/2014 05:11 PM, Chris Wilson wrote:
On Wed, Mar 26, 2014 at 04:48:47PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
Looks like there are some redundant lines in the main loop of
i915_gem_object_get_pages_gtt.
I haven't tested this so just RFC please
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
Looks like there are some redundant lines in the main loop of
i915_gem_object_get_pages_gtt.
v2: Put CONFIG_SWIOTLB back in.
I haven't tested this so just RFC please. Not sure that
seven lines net less is worth this. It just made it clerer
On 03/27/2014 10:18 AM, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
Looks like there are some redundant lines in the main loop of
i915_gem_object_get_pages_gtt.
v2: Put CONFIG_SWIOTLB back in.
I haven't tested this so just RFC please. Not sure that
seven lines net
On 04/07/2014 02:18 PM, Siluvery, Arun wrote:
On 27/03/2014 22:23, Chris Wilson wrote:
On Thu, Mar 27, 2014 at 03:28:26PM +,
arun.siluv...@linux.intel.com wrote:
From: Siluvery, Arun arun.siluv...@intel.com
This patch series adds a new ioctl to resize a gem object.
I'm tired, but off
Hi Brad,
On 04/18/2014 12:18 AM, Volkin, Bradley D wrote:
On Wed, Mar 19, 2014 at 04:13:06AM -0700, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
This adds a small benchmark for the new userptr functionality.
Apart from basic surface creation and destruction, also
On 04/18/2014 06:10 PM, Volkin, Bradley D wrote:
On Wed, Mar 19, 2014 at 04:13:04AM -0700, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
A set of userptr test cases to support the new feature.
For the eviction and swapping stress testing I have extracted
some common
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
Dependencies are not available at the moment so it does not build.
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
---
tests/Android.mk | 1 +
1 file changed, 1 insertion(+)
diff --git a/tests/Android.mk b/tests/Android.mk
index 9233b2b
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
Makes for a little bit less code duplication, especially since
it will be used from more callers in the future.
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
---
lib/drmtest.h | 9 +
lib/media_fill_gen7.c | 2 +-
lib
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
This adds a small benchmark for the new userptr functionality.
Apart from basic surface creation and destruction, also tested is the
impact of having userptr surfaces in the process address space. Reason
for that is the impact of MMU notifiers
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
No need for the old test case once the new one was added.
v2:
* Just rebase for lib/ reorganization.
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
---
tests/.gitignore | 1 -
tests/Makefile.sources | 1 -
tests
1 - 100 of 11201 matches
Mail list logo
