[Intel-gfx] [RFC 05/22] drm/i915: Implement command parsing

[Volkin, Bradley D]

On Tue, Nov 26, 2013 at 09:56:09AM -0800, Chris Wilson wrote:
> On Tue, Nov 26, 2013 at 09:38:55AM -0800, Volkin, Bradley D wrote:
> > On Tue, Nov 26, 2013 at 09:29:32AM -0800, Chris Wilson wrote:
> > > On Tue, Nov 26, 2013 at 08:51:22AM -0800, bradley.d.volkin at intel.com wrote:
> > > > +static const struct drm_i915_cmd_descriptor*
> > > > +find_cmd_in_table(const struct drm_i915_cmd_table *table,
> > > > +		  u32 cmd_header)
> > > > +{
> > > > +	int i;
> > > > +
> > > > +	for (i = 0; i < table->count; i++) {
> > > > +		const struct drm_i915_cmd_descriptor *desc = &table->table[i];
> > > > +		u32 masked_cmd = desc->cmd.mask & cmd_header;
> > > > +		u32 masked_value = desc->cmd.value & desc->cmd.mask;
> > > > +
> > > > +		if (masked_cmd == masked_value)
> > > > +			return desc;
> > > 
> > > Maybe pre-sort the cmd table and use bsearch? And a runtime test on
> > > module load to check that the table is sorted correctly.
> > 
> > So far it doesn't look like the search is a bottleneck, but I've tried to keep
> > the tables sorted so that we could easily switch to bsearch if needed. Would
> > you prefer to just use bsearch from the start?
> 
> Yes. I think it will be easier (especially if the codes does the runtime
> check) to keep the table sorted as commands are incremently added in the
> future, rather than having to retrofit the bsearch when it becomes a
> significant problem.

Ok, makes sense. I'll assume the same comment applies to the register whitelists and
make similar changes there.

Brad

> -Chris
> 
> -- 
> Chris Wilson, Intel Open Source Technology Centre