public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 00/13] Gen7 batch buffer command parser
Date: Tue, 25 Mar 2014 15:21:03 +0200	[thread overview]
Message-ID: <8761n2ifcw.fsf@intel.com> (raw)
In-Reply-To: <20140325131536.GC26878@phenom.ffwll.local>

On Tue, 25 Mar 2014, Daniel Vetter <daniel@ffwll.ch> 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 have
>> reviewed a lot of miserable stuff in the past.
>> 
>> Most infuriatingly, I did not find a single real bug in the code!
>> 
>> I think we'll need to automate some things going forward, for example
>> listing the non-conforming length encoding with Damien's tools for cross
>> checking.
>> 
>> There are a few subtle points we need to discuss (separate mails
>> internally) but all in all this series is:
>> 
>> Reviewed-by: Jani Nikula <jani.nikula@intel.com>
>
> Ok, pulled this one in, thanks a lot for the patches&review. I think it's
> time we start to move on with the next bits, the batch copy stuff seams
> like a suitable piece. There's still issues with launching the entire
> thing in the end, but we can start with the copy infrastructure.
>
> Open issues I see still:
>
> - The littel issue we're discussing internally. Like I've said that one is
>   blocking us and needs to be resolved before we can switch to enforcing
>   mode.
>
> - Secure batch dispatch is still fubar.
>
> - CodingStyle says: Functions should be a) at most 3 indent levels b) at
>   most 3 ansi screens long (i.e. 75 lines). i915_parse_cmds violates both
>   metrics pretty deftly. I think a few refactoring patches to extract
>   helper functions and structure the flow a bit would be good.

Just extracting the handlers for (desc->flags & CMD_DESC_REGISTER) and
(desc->flags & CMD_DESC_BITMASK) would go a long way.

BR,
Jani.




>
> Cheers, Daniel
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch

-- 
Jani Nikula, Intel Open Source Technology Center

  reply	other threads:[~2014-03-25 13:21 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-18 18:15 [PATCH 00/13] Gen7 batch buffer command parser bradley.d.volkin
2014-02-18 18:15 ` [PATCH 01/13] drm/i915: Refactor shmem pread setup bradley.d.volkin
2014-03-06 12:13   ` Jani Nikula
2014-02-18 18:15 ` [PATCH 02/13] drm/i915: Implement command buffer parsing logic bradley.d.volkin
2014-03-06 13:10   ` Jani Nikula
2014-03-06 21:07     ` Daniel Vetter
2014-03-20 12:40   ` Jani Nikula
2014-02-18 18:15 ` [PATCH 03/13] drm/i915: Initial command parser table definitions bradley.d.volkin
2014-03-06 13:12   ` Jani Nikula
2014-02-18 18:15 ` [PATCH 04/13] drm/i915: Reject privileged commands bradley.d.volkin
2014-02-18 18:15 ` [PATCH 05/13] drm/i915: Allow some privileged commands from master bradley.d.volkin
2014-02-18 18:15 ` [PATCH 06/13] drm/i915: Add register whitelists for mesa bradley.d.volkin
2014-02-18 18:15 ` [PATCH 07/13] drm/i915: Add register whitelist for DRM master bradley.d.volkin
2014-02-18 18:15 ` [PATCH 08/13] drm/i915: Enable register whitelist checks bradley.d.volkin
2014-02-18 18:15 ` [PATCH 09/13] drm/i915: Reject commands that explicitly generate interrupts bradley.d.volkin
2014-02-18 18:15 ` [PATCH 10/13] drm/i915: Enable PPGTT command parser checks bradley.d.volkin
2014-03-06 13:17   ` Jani Nikula
2014-03-06 21:32     ` Volkin, Bradley D
2014-03-06 21:58       ` Daniel Vetter
2014-03-06 22:13         ` Volkin, Bradley D
2014-02-18 18:15 ` [PATCH 11/13] drm/i915: Reject commands that would store to global HWS page bradley.d.volkin
2014-02-18 18:15 ` [PATCH 12/13] drm/i915: Add a CMD_PARSER_VERSION getparam bradley.d.volkin
2014-02-18 18:15 ` [PATCH 13/13] drm/i915: Enable command parsing by default bradley.d.volkin
2014-03-04 17:21 ` [PATCH 00/13] Gen7 batch buffer command parser Volkin, Bradley D
2014-03-05 10:46 ` Daniel Vetter
2014-03-05 16:59   ` Volkin, Bradley D
2014-03-05 17:14     ` Daniel Vetter
2014-03-05 17:45       ` Volkin, Bradley D
2014-03-11 12:41 ` Jani Nikula
2014-03-12 18:02   ` Volkin, Bradley D
2014-03-20 14:43 ` Jani Nikula
2014-03-25 13:15   ` Daniel Vetter
2014-03-25 13:21     ` Jani Nikula [this message]
2014-03-25 19:46     ` Volkin, Bradley D
2014-03-25 19:53       ` Daniel Vetter
  -- strict thread matches above, loose matches on Subject: below --
2013-11-26 16:51 [RFC 00/22] " bradley.d.volkin
2014-01-29 21:55 ` [PATCH 00/13] " bradley.d.volkin
2014-01-29 22:11   ` Daniel Vetter
2014-01-29 22:22     ` Volkin, Bradley D
2014-01-29 23:31       ` Daniel Vetter
2014-02-05 15:41   ` Jani Nikula

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8761n2ifcw.fsf@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=daniel@ffwll.ch \
    --cc=intel-gfx@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox