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
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
