On Fri, Nov 07, 2014 at 07:34:31AM -0800, Neil Roberts wrote:
> The predicate source registers are needed to implement conditional
> rendering without stalling. The two source registers are used to load
> the previous values of the PS_DEPTH_COUNT register saved from
> PIPE_CONTROL commands. These c
Ping on this series. They're related to the batch copy series, but
the changes are valid and tests should still pass even without the
kernel changes being merged.
On Mon, Nov 03, 2014 at 11:18:59AM -0800, Volkin, Bradley D wrote:
> From: Brad Volkin
>
> The size of the batch bu
On Thu, Nov 06, 2014 at 05:56:36AM -0800, Daniel Vetter wrote:
> On Thu, Nov 06, 2014 at 07:36:55AM +, Chris Wilson wrote:
> > On Wed, Nov 05, 2014 at 02:42:00PM -0800, Volkin, Bradley D wrote:
> > > For this part, I've got an implementation that works ok but o
[snip]
On Wed, Nov 05, 2014 at 01:50:24AM -0800, Daniel Vetter wrote:
> On Tue, Nov 04, 2014 at 08:35:00AM -0800, Volkin, Bradley D wrote:
> > On Tue, Nov 04, 2014 at 02:17:59AM -0800, Daniel Vetter wrote:
> > > On Mon, Nov 03, 2014 at 11:19:42AM -0800, bradley.d.vol...@inte
On Tue, Nov 04, 2014 at 02:30:14AM -0800, Daniel Vetter wrote:
> On Mon, Nov 03, 2014 at 11:19:42AM -0800, bradley.d.vol...@intel.com wrote:
> > + flags |= I915_DISPATCH_SECURE;
>
> I've forgotten one: You must have a full ppgtt check here since the
> binding for aliasing ppgtt i
On Tue, Nov 04, 2014 at 02:17:59AM -0800, Daniel Vetter wrote:
> On Mon, Nov 03, 2014 at 11:19:42AM -0800, bradley.d.vol...@intel.com wrote:
> > 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
On Mon, Nov 03, 2014 at 11:19:40AM -0800, Volkin, Bradley D wrote:
> From: Brad Volkin
>
> This is v3 of the series I sent here:
> http://lists.freedesktop.org/archives/intel-gfx/2014-July/048705.html
>
> Most of the previous commentary still applies. We've fixe
On Thu, Oct 30, 2014 at 04:03:23PM -0700, armin.c.re...@intel.com wrote:
> From: Armin Reese
>
> The new 'i915_context_dump' file generates a hex dump of the
> entire logical context DRM object. It is useful for
> validating the contents of the default context set up by
> the golden state batch
On Thu, Oct 23, 2014 at 08:52:59AM -0700, Volkin, Bradley D wrote:
> On Thu, Oct 23, 2014 at 05:31:12AM -0700, Daniel Vetter wrote:
> > On Wed, Oct 22, 2014 at 09:04:32AM -0700, Volkin, Bradley D wrote:
> > > [snip]
> > >
> > > On Tue, Oct 21, 2014 at 0
On Thu, Oct 23, 2014 at 05:31:12AM -0700, Daniel Vetter wrote:
> On Wed, Oct 22, 2014 at 09:04:32AM -0700, Volkin, Bradley D wrote:
> > [snip]
> >
> > On Tue, Oct 21, 2014 at 08:50:33AM -0700, Daniel Vetter wrote:
> > > On Thu, Oct 16, 2014 at 12:24:42PM -07
[snip]
On Tue, Oct 21, 2014 at 08:50:33AM -0700, Daniel Vetter wrote:
> On Thu, Oct 16, 2014 at 12:24:42PM -0700, bradley.d.vol...@intel.com wrote:
> > diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > index 1a0611b..1ed5702 100644
> > --
On Tue, Oct 21, 2014 at 08:26:05AM -0700, Daniel Vetter wrote:
> On Wed, Oct 15, 2014 at 02:52:41PM -0700, bradley.d.vol...@intel.com wrote:
> > From: Brad Volkin
> >
> > The size of the batch buffer passed to the kernel is significantly
> > larger than the size of the batch buffer passed to the
I went through and compared this against both the spec (the state commands
listed in 3D-Media-GPGPU chapter 3D Pipeline Stages section) and the other
information I've seen on recommended setup, and as far as I can tell this
looks good. It still might be worth getting another set of eyes on this,
bu
On Wed, Sep 24, 2014 at 05:50:30AM -0700, Mika Kuoppala wrote:
> In null/golden context there are multiple state commands where
> the actual state is always zero. For more compact batch representation
> add a macro which just emits command and the rest of the state as zero.
>
> Signed-off-by: Mika
[snip]
On Thu, Sep 18, 2014 at 07:58:30AM -0700, Mika Kuoppala wrote:
> @@ -577,7 +596,7 @@ static int do_switch(struct intel_engine_cs *ring,
> vma->bind_vma(vma, to->legacy_hw_ctx.rcs_state->cache_level,
> GLOBAL_BIND);
> }
>
> - if (!to->legacy_hw_ctx.initialized || i
On Fri, Sep 12, 2014 at 11:25:14AM -0700, armin.c.re...@intel.com wrote:
> From: Armin Reese
>
> This patch includes the Gen9 batch buffer to generate
> a 'golden context' for that product family.
>
> Also:
> 1) IS_GEN9 macro has been added to drivers/gpu/drm/i915/i915_drv.h
> 2) drivers/gpu/drm
On Thu, Sep 11, 2014 at 01:49:07AM -0700, Chris Wilson wrote:
> On Thu, Sep 11, 2014 at 11:39:46AM +0300, Mika Kuoppala wrote:
> > When PPGGT is in use, we need to bind secure batches also to ggtt.
> > We used to pin, exec and unpin. This trick worked as there was nothing
> > competing in ggtt spac
On Fri, Jul 11, 2014 at 08:48:52AM -0700, oscar.ma...@intel.com wrote:
> From: Oscar Mateo
>
> For a description of this patchset, please check the previous cover letters:
> [1], [2] and [3].
>
> The main changes introduced in this v4 are:
>
> - Do not abstract __i915_add_request away.
> - Squ
On Wed, Jul 09, 2014 at 12:36:38AM -0700, Chris Wilson wrote:
> On Tue, Jul 08, 2014 at 03:26:38PM -0700, bradley.d.vol...@intel.com wrote:
> > From: Brad Volkin
> >
> > It provides some useful information about the buffers in
> > the global command parser batch pool.
> >
> > v2: rebase on globa
On Wed, Jul 09, 2014 at 08:30:08AM -0700, Chris Wilson wrote:
> On Wed, Jul 09, 2014 at 08:10:47AM -0700, Volkin, Bradley D wrote:
> > On Wed, Jul 09, 2014 at 12:37:08AM -0700, Chris Wilson wrote:
> > > On Tue, Jul 08, 2014 at 03:26:36PM -0700, bradley.d.vol...@intel.com
> &g
On Wed, Jul 09, 2014 at 12:37:08AM -0700, Chris Wilson wrote:
> On Tue, Jul 08, 2014 at 03:26:36PM -0700, bradley.d.vol...@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 desc
On Thu, Jun 26, 2014 at 08:48:46AM -0700, Jesse Barnes wrote:
> The command parser may be present, but not active, so check for PPGTT
> before allowing this test to run.
>
> Signed-off-by: Jesse Barnes
> ---
> tests/gem_exec_parse.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
On Tue, Jun 24, 2014 at 04:45:05AM -0700, Mateo Lozano, Oscar wrote:
> Ok, let´s try to extract something positive out of all this.
>
> OPTION A (Ben´s proposal):
>
> > I think the only solution for what Chris is asking for is to implement this
> > as 1
> > context per engine, as opposed to 1 co
On Mon, Jun 23, 2014 at 07:35:38AM -0700, Mateo Lozano, Oscar wrote:
> > -Original Message-
> > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> > Sent: Monday, June 23, 2014 2:42 PM
> > To: Mateo Lozano, Oscar
> > Cc: Volkin, Bradley D; intel-gfx@lis
On Mon, Jun 23, 2014 at 05:42:50AM -0700, Mateo Lozano, Oscar wrote:
> > -Original Message-
> > From: Volkin, Bradley D
> > > + reg_state[CTX_RING_HEAD+1] = 0;
> > > + reg_state[CTX_RING_TAIL] = RING_TAIL(ring->mmio_base);
> > > + reg_sta
On Fri, Jun 13, 2014 at 08:37:46AM -0700, oscar.ma...@intel.com wrote:
> From: Oscar Mateo
>
> Notice that the BSD invalidate bit is no longer present in GEN8, so
Hmm. As far as I can tell, it is still present for VCS on gen8. As to
whether we need to set it, I don't know.
> we can consolidate
On Fri, Jun 13, 2014 at 08:37:45AM -0700, oscar.ma...@intel.com wrote:
> From: Oscar Mateo
>
> Very similar to the legacy add_request, only modified to account for
> logical ringbuffer.
>
> Signed-off-by: Oscar Mateo
> ---
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> drivers/gpu/drm/i91
On Fri, Jun 13, 2014 at 08:37:44AM -0700, oscar.ma...@intel.com wrote:
> From: Oscar Mateo
>
> Well, new-ish: if all this code looks familiar, that's because it's
> a clone of the existing submission mechanism (with some modifications
> here and there to adapt it to LRCs and Execlists).
>
> And
On Fri, Jun 13, 2014 at 08:37:43AM -0700, oscar.ma...@intel.com wrote:
> From: Oscar Mateo
>
> For the moment, just mark the place (we still need to do a lot of
> preparation before execlists are ready to start submitting things).
>
> Signed-off-by: Oscar Mateo
> ---
> drivers/gpu/drm/i915/int
On Fri, Jun 13, 2014 at 08:37:41AM -0700, oscar.ma...@intel.com wrote:
> From: Oscar Mateo
>
> Reusing stuff, a penny at a time.
>
> Signed-off-by: Oscar Mateo
> ---
> drivers/gpu/drm/i915/i915_gem.c | 4 ++--
> drivers/gpu/drm/i915/intel_ringbuffer.h | 4 ++--
> 2 files changed, 4 ins
On Fri, Jun 20, 2014 at 08:41:08AM -0700, Tvrtko Ursulin wrote:
>
> 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 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
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
> >
> > This adds a small module for managing a pool of batch buffers.
> > The only current use case is for the command parser, as desc
On Thu, Jun 19, 2014 at 11:31:53AM +0100, Damien Lespiau wrote:
> Cc: Bradley Volkin
> Signed-off-by: Damien Lespiau
Thanks for taking care of this Damien.
Reviewed-by: Brad Volkin
> ---
> include/drm/i915_drm.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/drm/i915_drm.h
On Fri, Jun 13, 2014 at 08:37:37AM -0700, oscar.ma...@intel.com wrote:
> From: Oscar Mateo
>
> I plan to reuse these for the new logical ring path.
>
> No functional changes.
>
> Signed-off-by: Oscar Mateo
> ---
> drivers/gpu/drm/i915/intel_ringbuffer.c | 31 ++-
>
On Fri, Jun 13, 2014 at 08:37:33AM -0700, oscar.ma...@intel.com wrote:
> From: Oscar Mateo
>
> This is mostly for correctness so that we know we are running the LR
> context correctly (this is, the PDPs are contained inside the context
> object).
>
> v2: Move the check to inside the enable PPGTT
On Fri, Jun 13, 2014 at 08:37:30AM -0700, oscar.ma...@intel.com wrote:
> From: Oscar Mateo
>
> For the most part, logical ring context objects are similar to hardware
> contexts in that the backing object is meant to be opaque. There are
> some exceptions where we need to poke certain offsets of
On Fri, Jun 13, 2014 at 08:37:29AM -0700, oscar.ma...@intel.com wrote:
> From: Oscar Mateo
>
> As we have said a couple of times by now, logical ring contexts have
> their own ringbuffers: not only the backing pages, but the whole
> management struct.
>
> In a previous version of the series, thi
On Fri, Jun 13, 2014 at 08:37:28AM -0700, oscar.ma...@intel.com wrote:
> From: Oscar Mateo
>
> There are a few big differences between context init and fini with the
> previous implementation of hardware contexts. One of them is
> demonstrated in this patch: we must allocate a ctx backing object
On Fri, Jun 13, 2014 at 08:37:22AM -0700, oscar.ma...@intel.com wrote:
> From: Oscar Mateo
>
> We are going to start creating a lot of extra ringbuffers soon, so
> these functions are handy.
>
> No functional changes.
>
> Signed-off-by: Oscar Mateo
> ---
> drivers/gpu/drm/i915/intel_ringbuffe
[snip]
On Mon, Jun 16, 2014 at 08:18:00AM -0700, Mateo Lozano, Oscar wrote:
> > > +struct intel_context *
> > > +i915_gem_context_validate(struct drm_device *dev, struct drm_file *file,
> > > + struct intel_engine_cs *ring, const u32 ctx_id) {
> > > + struct intel_context *ctx =
On Wed, Jun 18, 2014 at 09:52:52AM -0700, Chris Wilson wrote:
> On Wed, Jun 18, 2014 at 09:36:14AM -0700, bradley.d.vol...@intel.com wrote:
> > From: Brad Volkin
> >
> > This patch sets up all of the tracking and copying necessary to
> > use batch pools with the command parser, but does not actua
On Thu, Jun 12, 2014 at 06:36:04PM +0100, Chris Wilson wrote:
> On Thu, Jun 12, 2014 at 10:10:58AM -0700, Volkin, Bradley D wrote:
> > On Thu, Jun 12, 2014 at 03:13:14PM +0100, Chris Wilson wrote:
> > > + /* Check if a second thread completed the prefaulting for us
On Thu, Jun 12, 2014 at 03:13:14PM +0100, Chris Wilson wrote:
> remap_pfn_range() has a nasty surprise if you try to handle two faults
> from the same vma concurrently: that is the second thread hits a BUG()
> to assert that the range is clear. As we hold our struct_mutex whilst
> manipulating the
On Tue, Jun 10, 2014 at 04:14:41AM -0700, Chris Wilson wrote:
> On an Ivybridge i7-3720qm with 1600MHz DDR3, with 32 fences,
> Upload rate for 2 linear surfaces: 8134MiB/s -> 8154MiB/s
> Upload rate for 2 tiled surfaces: 8625MiB/s -> 8632MiB/s
> Upload rate for 4 linear surfaces: 8127MiB/s -> 8
On Tue, Jun 10, 2014 at 04:14:40AM -0700, Chris Wilson wrote:
> Inserting additional PTEs has no side-effect for us as the pfn are fixed
> for the entire time the object is resident in the global GTT. The
> downside is that we pay the entire cost of faulting the object upon the
> first hit, for whi
On Wed, May 28, 2014 at 03:02:24PM -0700, Jesse Barnes wrote:
> Need testing and possibly disabling on earlier steppings, but looks ok
> here on my B3.
>
> Signed-off-by: Jesse Barnes
> ---
> drivers/gpu/drm/i915/i915_drv.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
On Wed, May 28, 2014 at 02:29:34PM -0700, Daniel Vetter wrote:
> Jesse reportedly has a patch somewhere to (finally!) enable ppgtt on
> vlv. Would we still need any part of this with ppgtt support on vlv?
> -Daniel
Of course, as soon as I accept that it'll never happen... :)
Off the top of my hea
On Wed, May 21, 2014 at 07:02:56AM -0700, Mika Kuoppala wrote:
> + if (ring->id == RCS && !to->is_initialized && from == NULL) {
> + ret = i915_gem_render_state_init(ring);
> + if (ret)
> + DRM_ERROR("init render state: %d\n", ret);
> + }
Apologi
On Mon, May 19, 2014 at 09:49:31AM -0700, Mateo Lozano, Oscar wrote:
> > -Original Message-
> > From: Volkin, Bradley D
> > Sent: Monday, May 19, 2014 5:41 PM
> > To: Mateo Lozano, Oscar
> > Cc: Daniel Vetter; intel-gfx@lists.freedesktop.org
> > Subjec
On Mon, May 19, 2014 at 09:33:37AM -0700, Mateo Lozano, Oscar wrote:
> > -Original Message-
> > From: Volkin, Bradley D
> > Sent: Monday, May 19, 2014 5:24 PM
> > To: Mateo Lozano, Oscar
> > Cc: Daniel Vetter; intel-gfx@lists.freedesktop.org
> > Subjec
On Fri, May 09, 2014 at 05:08:32AM -0700, oscar.ma...@intel.com wrote:
> From: Ben Widawsky
>
> for_each_ring() iterates over all rings supported by the hardware, not
> just those which have been initialized as in for_each_active_ring()
I think we should give this a new name; something like for_
On Mon, May 19, 2014 at 09:12:26AM -0700, Mateo Lozano, Oscar wrote:
> BTW: do you want me to kill private_default_ctx as well? It doesn´t look very
> useful...
Isn't private_default_ctx the one that's actually used when userspace
specifies DEFAULT_CONTEXT_ID?
Brad
> ___
On Fri, May 16, 2014 at 12:53:30PM -0700, Jesse Barnes wrote:
> On Fri, 16 May 2014 12:34:08 -0700
> Jesse Barnes wrote:
>
> > On Fri, 16 May 2014 20:20:50 +0100
> > Chris Wilson wrote:
> > > Yes, X only sets the secure bit when it pokes the display registers, and
> > > those registers should be
_user().
> v22: Use sg_alloc_table_from_pages for that chunky feeling
> v23: Export a function for sanity checking dma-buf rather than encode
> userptr details elsewhere, and clean up comments based on
> suggestions by Bradley.
>
> Signed-off-by: Chris Wilson
> Cc: Tvrtk
On Mon, May 12, 2014 at 09:24:06AM -0700, Daniel Vetter wrote:
> On Thu, May 08, 2014 at 09:02:18AM -0700, Volkin, Bradley D wrote:
> > On Thu, May 08, 2014 at 08:45:07AM -0700, Ville Syrjälä wrote:
> > > On Thu, May 08, 2014 at 08:27:16AM -0700, Volkin, Bradley D wrote:
>
On Sat, May 10, 2014 at 06:42:32AM -0700, Siluvery, Arun wrote:
> On 09/05/2014 22:18, Volkin, Bradley D wrote:
> > On Mon, Apr 28, 2014 at 08:01:29AM -0700, arun.siluv...@linux.intel.com
> > wrote:
> >> + if (ret)
> >> + return ret;
> >>
On Mon, Apr 28, 2014 at 08:01:29AM -0700, arun.siluv...@linux.intel.com wrote:
> From: "Siluvery, Arun"
>
> This patch adds support to have gem objects of variable size.
> The size of the gem object obj->size is always constant and this fact
> is tightly coupled in the driver; this implementation
On Thu, May 08, 2014 at 08:50:40AM -0700, Tvrtko Ursulin wrote:
>
> 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
On Thu, May 08, 2014 at 08:45:07AM -0700, Ville Syrjälä wrote:
> On Thu, May 08, 2014 at 08:27:16AM -0700, Volkin, Bradley D wrote:
> > On Thu, May 08, 2014 at 02:56:05AM -0700, Tvrtko Ursulin wrote:
> > >
> > > Hi Brad,
> > >
> > > On 04/28/20
On Thu, May 08, 2014 at 06:15:44AM -0700, Lespiau, Damien wrote:
> On Thu, May 08, 2014 at 02:05:07PM +0100, Damien Lespiau wrote:
> > On Mon, Apr 28, 2014 at 08:22:08AM -0700, bradley.d.vol...@intel.com wrote:
> > > From: Brad Volkin
> > > +/*
> > > + * Different command ranges have different num
On Thu, May 08, 2014 at 06:42:16AM -0700, Tvrtko Ursulin wrote:
>
> On 04/28/2014 04:22 PM, bradley.d.vol...@intel.com wrote:
> > From: Brad Volkin
> >
> > For clients that submit large batch buffers the command parser has
> > a substantial impact on performance. On my HSW ULT system performance
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, cmd_table_count));
> > BUG_ON(!validate_regs_
On Mon, May 05, 2014 at 01:07:33AM -0700, Chris Wilson wrote:
> During the review of
>
> commit 1f70999f9052f5a1b0ce1a55aff3808f2ec9fe42
> Author: Chris Wilson
> Date: Mon Jan 27 22:43:07 2014 +
>
> drm/i915: Prevent recursion by retiring requests when the ring is full
>
> Ville raise
On Mon, May 05, 2014 at 01:07:32AM -0700, Chris Wilson wrote:
> A few improvements to the fallback method for waiting upon ring space:
>
> 1. Fix the start/end wait tracepoints to always be paired.
> 2. Increase responsiveness of checking
> 3. Mark the process as waiting upon io
> 4. Check for sig
Could someone help to review this patch please? It provides a nice
improvement to the command parser's performance, so I'd like to get
this one in.
Thanks,
Brad
On Mon, Apr 28, 2014 at 08:22:08AM -0700, Volkin, Bradley D wrote:
> From: Brad Volkin
>
> For clients that
Reviewed-by: Brad Volkin
On Fri, Apr 18, 2014 at 02:04:29PM -0700, Rodrigo Vivi wrote:
> From: Ben Widawsky
>
> It seems we need this at least for the current platforms we have, but
> probably not later. In any event, it should cause too much harm as we do
> the same thing on several other plat
Reviewed-by: Brad Volkin
On Fri, Apr 18, 2014 at 02:04:28PM -0700, Rodrigo Vivi wrote:
> From: Ben Widawsky
>
> The same register exists for querying and programming eDRAM AKA eLLC. So
> we can simply use it. For now, use all the same defaults as we had
> for Haswell, since like Haswell, I have
On Fri, Apr 18, 2014 at 02:04:27PM -0700, Rodrigo Vivi wrote:
> From: Ben Widawsky
>
> I don't have any insight on what parts can do what. The docs do seem to
> suggest WT caching works in at least the same manner as it doesn't on
> Haswell.
As Ben previously mentioned, s/doesn't/does. Other tha
On Mon, Apr 28, 2014 at 08:53:30AM -0700, Daniel Vetter wrote:
> On Mon, Apr 28, 2014 at 08:22:08AM -0700, bradley.d.vol...@intel.com wrote:
> > From: Brad Volkin
> >
> > For clients that submit large batch buffers the command parser has
> > a substantial impact on performance. On my HSW ULT syst
On Mon, Apr 28, 2014 at 08:42:56AM -0700, Daniel Vetter wrote:
> On Mon, Apr 28, 2014 at 08:22:08AM -0700, bradley.d.vol...@intel.com wrote:
> > From: Brad Volkin
> >
> > For clients that submit large batch buffers the command parser has
> > a substantial impact on performance. On my HSW ULT syst
On Mon, Apr 28, 2014 at 08:22:08AM -0700, Volkin, Bradley D wrote:
> From: Brad Volkin
>
> 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 th
On Thu, Apr 24, 2014 at 02:22:39AM -0700, Chris Wilson wrote:
> On Fri, Mar 28, 2014 at 03:58:25PM -0700, Volkin, Bradley D wrote:
> > On Mon, Mar 17, 2014 at 05:21:55AM -0700, Chris Wilson wrote:
> > > @@ -1949,58 +1956,58 @@ static unsigned long
> > > __i915_gem_shr
Reviewed-by: Brad Volkin
On Thu, Apr 24, 2014 at 10:07:32AM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> 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 th
Reviewed-by: Brad Volkin
On Wed, Apr 23, 2014 at 05:38:33PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> 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 ma
On Wed, Apr 23, 2014 at 05:38:35PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> 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. Re
Reviewed-by: Brad Volkin
On Wed, Apr 23, 2014 at 05:38:34PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> No need for the old test case once the new one was added.
>
> v2:
>* Just rebase for lib/ reorganization.
>
> Signed-off-by: Tvrtko Ursulin
> ---
> tests/.gitignore
Reviewed-by: Brad Volkin
On Wed, Apr 23, 2014 at 09:03:23AM -0700, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> They build fine so give them some exposure.
>
> Signed-off-by: Tvrtko Ursulin
> ---
> Android.mk | 2 +-
> benchmarks/Android.mk | 36 ++
Reviewed-by: Brad Volkin
On Wed, Apr 23, 2014 at 08:07:55AM -0700, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> 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
> ---
> lib/drmtest.h
On Wed, Apr 23, 2014 at 06:33:40AM -0700, Tvrtko Ursulin wrote:
>
> 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
> >>
> >> A set of userptr test cases to sup
[snip]
On Wed, Apr 23, 2014 at 06:28:54AM -0700, Tvrtko Ursulin wrote:
> On 04/18/2014 12:18 AM, Volkin, Bradley D wrote:
> > On Wed, Mar 19, 2014 at 04:13:06AM -0700, Tvrtko Ursulin wrote:
> >> +static void **handle_ptr_map;
> >> +static unsigned int num_handle_ptr_m
On Wed, Apr 09, 2014 at 09:47:57AM -0700, Daniel Vetter wrote:
> On Wed, Apr 09, 2014 at 08:12:28AM -0700, Volkin, Bradley D wrote:
> > On Tue, Apr 08, 2014 at 11:20:30PM -0700, Chris Wilson wrote:
> > > On Tue, Apr 08, 2014 at 02:22:16PM -0700, bradley.d.vol...@inte
On Wed, Mar 19, 2014 at 04:13:04AM -0700, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> 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
On Wed, Mar 19, 2014 at 04:13:05AM -0700, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> No need for the old test case once the new one was added.
>
> Signed-off-by: Tvrtko Ursulin
Reviewed-by: Brad Volkin
> ---
> tests/.gitignore | 1 -
> tests/Makefile.sources | 1 -
> tests/g
On Wed, Mar 19, 2014 at 04:13:06AM -0700, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> 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. Re
Hi Chris, just want to bring this one back to your attention while
I'm going through the rest of the series.
Thanks,
Brad
On Fri, Mar 28, 2014 at 03:58:25PM -0700, Volkin, Bradley D wrote:
> On Mon, Mar 17, 2014 at 05:21:55AM -0700, Chris Wilson wrote:
> > A common issue we have is
port until we have the required
> infrastructure - but reserve the bit in flags for future use.
> v21: use_mm() is not required for get_user_pages(). It is only meant to
> be used to fix up the kernel thread's current->mm for use with
> copy_user().
>
> Signed-off-b
On Tue, Apr 08, 2014 at 11:20:30PM -0700, Chris Wilson wrote:
> On Tue, Apr 08, 2014 at 02:22:16PM -0700, bradley.d.vol...@intel.com wrote:
> > From: Brad Volkin
> >
> > The command parser in newer kernels will reject it and setting this
> > bit is not required for the actual test case.
> >
> >
Hi Daniel, we've merged the kernel change for this but not the test. I'm
assuming we still want the test case.
Brad
On Thu, Mar 27, 2014 at 11:44:45AM -0700, Volkin, Bradley D wrote:
> From: Brad Volkin
>
> Signed-off-by: Brad Volkin
> ---
> te
On Mon, Mar 17, 2014 at 05:21:55AM -0700, Chris Wilson wrote:
> A common issue we have is that retiring requests causes recursion
> through GTT manipulation or page table manipulation which we can only
> handle at very specific points. However, to maintain internal
> consistency (enforced through o
On Thu, Mar 27, 2014 at 02:58:01PM -0700, Kenneth Graunke wrote:
> On 03/27/2014 11:43 AM, bradley.d.vol...@intel.com wrote:
> > From: Brad Volkin
> >
> > There is some thought that the data from the performance counters enabled
> > via OACONTROL should only be available to the process that enabl
On Thu, Mar 27, 2014 at 02:47:03PM -0700, Kenneth Graunke wrote:
> Does any code actually rely on the tables being sorted?
Not today. The idea was to make it easier to move to an algorithm that does
in the future. For example, I thought binary search might be an easy win.
>
> I didn't see any ea
On Thu, Mar 27, 2014 at 01:16:26PM -0700, Daniel Vetter wrote:
> On Thu, Mar 27, 2014 at 4:57 PM, Volkin, Bradley D
> wrote:
> > On Thu, Mar 27, 2014 at 12:57:21AM -0700, Daniel Vetter wrote:
> >> Another one that blows is igt/gen7_forcewake_mt. Not sure yet whether it
[snip]
On Thu, Mar 27, 2014 at 12:57:21AM -0700, Daniel Vetter wrote:
> Another one that blows is igt/gen7_forcewake_mt. Not sure yet whether it's
> an issue with the test or the checker:
>
> https://bugs.freedesktop.org/show_bug.cgi?id=76670
For this one, the parser rejects an MI_STORE_REGISTER
On Wed, Mar 26, 2014 at 10:37:44AM -0700, Kenneth Graunke wrote:
> On 03/26/2014 09:38 AM, Daniel Vetter wrote:
> > On Wed, Mar 26, 2014 at 09:03:58AM -0700, Volkin, Bradley D wrote:
> >> On Tue, Mar 25, 2014 at 11:21:23PM -0700, Daniel Vetter wrote:
> >>> On Tue, Ma
On Tue, Mar 25, 2014 at 11:21:23PM -0700, Daniel Vetter wrote:
> On Tue, Mar 25, 2014 at 10:52:03PM -0700, Kenneth Graunke wrote:
> > Mesa needs to be able to write OACONTROL in order to expose the
> > Observability Architecture's performance counters via OpenGL.
> >
> > Signed-off-by: Kenneth Gra
On Tue, Mar 25, 2014 at 06:17:55AM -0700, Daniel Vetter wrote:
> On Thu, Jan 30, 2014 at 11:46:15AM +, Chris Wilson wrote:
> > On Wed, Jan 29, 2014 at 10:10:47PM +, Chris Wilson wrote:
> > > On Wed, Jan 29, 2014 at 01:58:29PM -0800, bradley.d.vol...@intel.com
> > > wrote:
> > > > From: Bra
On Tue, Mar 25, 2014 at 06:15:36AM -0700, Daniel Vetter wrote:
> On Thu, Mar 20, 2014 at 04:43:05PM +0200, Jani Nikula wrote:
> >
> > Hi Bradley -
> >
> > Apologies for my procrastination with the review; I don't easily recall
> > as tedious a review as the command and register tables. And I sure
Thanks for fixing this Damien.
Reviewed-by: Brad Volkin
On Tue, Mar 18, 2014 at 05:43:08PM +, Damien Lespiau wrote:
> When compiling on 32bits, I have the following warning:
>
> drivers/gpu/drm/i915/i915_cmd_parser.c:405:4: warning: format ‘%ld’
> expects argument of type ‘long int’, but ar
On Tue, Mar 11, 2014 at 05:41:06AM -0700, Jani Nikula wrote:
>
> Hi Bradley -
>
> I've now rather meticulously reviewed what *is* in the command and
> register tables, and didn't spot any obvious errors.
Thanks Jani! I know it's a huge pain, so I appreciate you taking the
time for it.
>
> Ther
1 - 100 of 138 matches
Mail list logo
