All of lore.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.