From: "Michael H. Nguyen"
This is v7 in response to
http://lists.freedesktop.org/archives/intel-gfx/2014-December/057033.html
Minor updates from the last rev
- Keep batch pool in LRU order (Daniel)
- Remove duplicate madv assignments (Daniel)
Brad Volkin (5):
drm/i915: Implement a
From: Brad Volkin
This patch sets up all of the tracking and copying necessary to
use batch pools with the command parser and dispatches the copied
(shadow) batch to the hardware.
After this patch, the parser is in 'enabling' mode.
Note that performance takes a hit from the copy in some cases
a
From: Brad Volkin
Move it to a separate function since the main do_execbuffer function
already has so much going on.
v2:
- Move pin/unpin calls inside i915_parse_cmds() (Chris W, v4 7/7
feedback)
Issue: VIZ-4719
Signed-off-by: Brad Volkin
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 8
From: Brad Volkin
By adding a new exec_entry flag, we cleanly mark the shadow objects
as purgeable after they are on the active list.
v2:
- Move 'shadow_batch_obj->madv = I915_MADV_WILLNEED' inside _get
fnc (danvet, from v4 6/7 feedback)
v3:
- Remove duplicate 'madv = I915_MADV_WILLNEED' (dan
From: Brad Volkin
Previously we couldn't trust the user-supplied batch length because
it came directly from userspace (i.e. untrusted code). It would have
affected what commands software parsed without regard to what hardware
would actually execute, leaving a potential hole.
With the parser now
From: Brad Volkin
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, but separating
it out makes it easier to change the underlying algorithms and to
extend to future u
On 12/11/2014 05:49 AM, Bloomfield, Jon wrote:
-Original Message-
From: Nguyen, Michael H
Sent: Monday, December 08, 2014 10:34 PM
To: intel-gfx@lists.freedesktop.org
Cc: Bloomfield, Jon; Brad Volkin
Subject: [PATCH v6 5/5] drm/i915: Tidy up execbuffer command parsing code
From: Bra
On 12/11/2014 05:26 AM, Bloomfield, Jon wrote:
-Original Message-
From: Nguyen, Michael H
Sent: Monday, December 08, 2014 10:34 PM
To: intel-gfx@lists.freedesktop.org
Cc: Bloomfield, Jon; Brad Volkin
Subject: [PATCH v6 4/5] drm/i915: Mark shadow batch buffers as purgeable
From: Brad Vo
On 12/10/2014 08:41 AM, Bloomfield, Jon wrote:
why do we take the batch_pool lock in i915_gem_batch_pool_info() ?
i915_gem_batch_pool_info() is a new debugfs entry while
print_batch_pool_stats() is just an internal fnc, called from the
debugfs entry i915_gem_object_info(). i915_gem_object_inf
Hi Jon,
On 12/10/2014 03:06 AM, Bloomfield, Jon wrote:
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
Of Daniel Vetter
Sent: Tuesday, December 09, 2014 1:18 PM
To: Nguyen, Michael H
Cc: Brad Volkin; intel-gfx@lists.freedesktop.org
Subject: R
On 12/09/2014 05:22 AM, Daniel Vetter wrote:
On Mon, Dec 08, 2014 at 02:33:50PM -0800, michael.h.ngu...@intel.com wrote:
From: Brad Volkin
Move it to a separate function since the main do_execbuffer function
already has so much going on.
v2:
- Move pin/unpin calls inside i915_parse_cmds() (
On 12/09/2014 05:21 AM, Daniel Vetter wrote:
On Mon, Dec 08, 2014 at 02:33:49PM -0800, michael.h.ngu...@intel.com wrote:
From: Brad Volkin
By adding a new exec_entry flag, we cleanly mark the shadow objects
as purgeable after they are on the active list.
v2:
- Move 'shadow_batch_obj->madv =
On 12/09/2014 05:18 AM, Daniel Vetter wrote:
On Mon, Dec 08, 2014 at 02:33:46PM -0800, michael.h.ngu...@intel.com wrote:
From: Brad Volkin
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
From: Brad Volkin
By adding a new exec_entry flag, we cleanly mark the shadow objects
as purgeable after they are on the active list.
v2:
- Move 'shadow_batch_obj->madv = I915_MADV_WILLNEED' inside _get
fnc (danvet, from v4 6/7 feedback)
Issue: VIZ-4719
Signed-off-by: Brad Volkin
---
driver
From: Brad Volkin
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, but separating
it out makes it easier to change the underlying algorithms and to
extend to future u
From: "Michael H. Nguyen"
This is v6 in response to
http://lists.freedesktop.org/archives/intel-gfx/2014-November/056314.html
- Simplified pool_get() code
Use single cache list to manage pool
s/active_list/cache_list
Use single loop instead of an inner & outer
- Sq
From: Brad Volkin
Previously we couldn't trust the user-supplied batch length because
it came directly from userspace (i.e. untrusted code). It would have
affected what commands software parsed without regard to what hardware
would actually execute, leaving a potential hole.
With the parser now
From: Brad Volkin
Move it to a separate function since the main do_execbuffer function
already has so much going on.
v2:
- Move pin/unpin calls inside i915_parse_cmds() (Chris W, v4 7/7
feedback)
Issue: VIZ-4719
Signed-off-by: Brad Volkin
Conflicts:
drivers/gpu/drm/i915/i915_gem_exe
From: Brad Volkin
This patch sets up all of the tracking and copying necessary to
use batch pools with the command parser and dispatches the copied
(shadow) batch to the hardware.
After this patch, the parser is in 'enabling' mode.
Note that performance takes a hit from the copy in some cases
a
On 12/08/2014 07:19 AM, Bloomfield, Jon wrote:
-Original Message-
From: Nguyen, Michael H
Sent: Wednesday, November 26, 2014 9:54 PM
To: intel-gfx@lists.freedesktop.org
Cc: Bloomfield, Jon; Volkin, Bradley D
Subject: [PATCH v5 1/7] drm/i915: Implement a framework for batch buffer
pools
On 12/02/2014 03:13 AM, Chris Wilson wrote:
> On Mon, Dec 01, 2014 at 02:39:51PM -0800, Michael H. Nguyen wrote:
>> Re: madvise on creation
>>
>> Were you referring to this?
>>
>> from http://lists.freedesktop.org/archives/intel-gfx/2014-November/055060.htm
&g
On 12/02/2014 01:45 AM, Daniel Vetter wrote:
On Mon, Dec 01, 2014 at 02:39:51PM -0800, Michael H. Nguyen wrote:
On 11/26/2014 11:44 PM, Chris Wilson wrote:
On Wed, Nov 26, 2014 at 01:53:34PM -0800, michael.h.ngu...@intel.com wrote:
From: "Michael H. Nguyen"
This is v5 of the s
On 11/26/2014 11:44 PM, Chris Wilson wrote:
On Wed, Nov 26, 2014 at 01:53:34PM -0800, michael.h.ngu...@intel.com wrote:
From: "Michael H. Nguyen"
This is v5 of the series sent here:
http://lists.freedesktop.org/archives/intel-gfx/2014-November/055141.html
This version incorp
From: Brad Volkin
Move it to a separate function since the main do_execbuffer function
already has so much going on.
v2:
- Move pin/unpin calls inside i915_parse_cmds() (Chris W, v4 7/7
feedback)
Issue: VIZ-4719
Signed-off-by: Brad Volkin
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 8
From: Brad Volkin
It provides some useful information about the buffers in
the global command parser batch pool.
v2: rebase on global pool instead of per-ring pools
v3: rebase
Issue: VIZ-4719
Signed-off-by: Brad Volkin
---
drivers/gpu/drm/i915/i915_debugfs.c | 41
From: Brad Volkin
By adding a new exec_entry flag, we cleanly mark the shadow objects
as purgeable after they are on the active list.
v2:
- Move 'shadow_batch_obj->madv = I915_MADV_WILLNEED' inside _get
fnc (danvet, from v4 6/7 feedback)
Issue: VIZ-4719
Signed-off-by: Brad Volkin
---
driver
From: Brad Volkin
This patch sets up all of the tracking and copying necessary to
use batch pools with the command parser and dispatches the copied
(shadow) batch to the hardware.
After this patch, the parser is in 'enabling' mode.
Note that performance takes a hit from the copy in some cases
a
From: Brad Volkin
To better account for the potentially large memory consumption
of the batch pool.
Issue: VIZ-4719
Signed-off-by: Brad Volkin
---
drivers/gpu/drm/i915/i915_debugfs.c | 45 +
1 file changed, 36 insertions(+), 9 deletions(-)
diff --git a/driv
From: Brad Volkin
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, but separating
it out makes it easier to change the underlying algorithms and to
extend to future u
From: "Michael H. Nguyen"
This is v5 of the series sent here:
http://lists.freedesktop.org/archives/intel-gfx/2014-November/055141.html
This version incorporates the following feedback from v4.
- 0/7 Move 'pending_read_domains |= I915_GEM_DOMAIN_COMMAND' after the
parser
From: Brad Volkin
Previously we couldn't trust the user-supplied batch length because
it came directly from userspace (i.e. untrusted code). It would have
affected what commands software parsed without regard to what hardware
would actually execute, leaving a potential hole.
With the parser now
Hi Daniel, Chris
On 11/12/2014 08:38 AM, Chris Wilson wrote:
On Wed, Nov 12, 2014 at 05:33:08PM +0100, Daniel Vetter wrote:
On Wed, Nov 12, 2014 at 10:46 AM, Chris Wilson wrote:
On Wed, Nov 12, 2014 at 09:44:34AM +0100, Daniel Vetter wrote:
On Fri, Nov 07, 2014 at 02:22:01PM -0800, bradley.d
Hi Chris,
+static struct drm_i915_gem_object*
+i915_gem_execbuffer_parse(struct intel_engine_cs *ring,
+ struct drm_i915_gem_exec_object2 *shadow_exec_entry,
+ struct eb_vmas *eb,
+ struct drm_i915_gem_object *batch_obj,
+
From: "Michael H. Nguyen"
Was missing
Issue: VIZ-4701
Signed-off-by: Michael H. Nguyen
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 14 +++---
drivers/gpu/drm/i915/i915_reg.h| 3 +++
2 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/gp
On 08/14/2014 09:51 AM, arun.siluv...@linux.intel.com wrote:
From: Arun Siluvery
The workarounds at the moment are initialized in init_clock_gating() but
they are lost during reset, suspend/resume; this patch moves workarounds
that are part of register state context to render ring init fn oth
Hi,
$ perf list
I see "net", "iommu" and other trace events listed however I do not see
any i915 ones. Is there anything in particular I need to do at build or
runtime to make them show up? i915 is loaded. I am using the perf tool
built under ~/tools/perf.
Thanks,
Mike
_
On 05/16/2014 04:29 PM, Michael H Nguyen wrote:
Hi,
I am trying to step through i-g-t & libdrm source w/ GDB but single
stepping seems erratic so I am guessing the build is optimized. Is
changing "CFLAGS = -g -O2" to "CFLAGS = -g -O0" the right thing to do?
If so, ho
Hi,
I am trying to step through i-g-t & libdrm source w/ GDB but single
stepping seems erratic so I am guessing the build is optimized. Is
changing "CFLAGS = -g -O2" to "CFLAGS = -g -O0" the right thing to do?
If so, how can I do that globally one time versus touching every
Makefile inside th
38 matches
Mail list logo
