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.
> -Chris
A quick test is showing that bsearch() with the current table definitions is worse
than the linear search by ~7%. If I flatten the tables so there's one table with
all of the commands for a given ring, bsearch() is ~2% better than linear search.
So I'm inclined to add the code to check that the list is sorted but stick with linear
search for now. I'll revisit when we have more complete performance data.
Brad
>
> --
> Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
