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@xxxxxxxxx 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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
