[Mesa-dev] [Mesa-stable] [PATCH 2/2] anv/entrypoints: Rework #if guards

[Jason Ekstrand]

On Fri, Jun 10, 2016 at 1:14 PM, Emil Velikov <emil.l.velikov at gmail.com>
wrote:

> On 10 June 2016 at 20:57, Jason Ekstrand <jason at jlekstrand.net> wrote:
> > This reworks the #if guards a bit.  When Emil originally wrote them, he
> > just guarded everything.  However, part of what anv_entrypoints_gen.py
> > generates is a hash table for looking up entrypoints based on their name.
> > This table *cannot* get out of sync between C and python regardless of
> > preprocessor flags.  In order to prevent this, this commit makes us use
> > void pointers in the dispatch table for those entrypoints which aren't
> > available.  This means that the dispatch table size and entry order is
> > constant and it should never get out-of-sync with the python.
> >
> Double-checking that I've for this right:
> So this moves the guard per function and ensures that all entries and
> thus the hash table and lookup is always at the same place. Regardless
> if we'll ever hit the non-supported platforms' entry points.
>

Yes, that's correct.


> I'm thinking about an alternative solution, not sure if it's going to
> work/fly. Forward declare the specific types (in case we're building
> w/o said platform) and drop the guards around the functions and don't
> change the function signature/return type.
>

I thought about that.  In particular, declaring typedefs that just give you
void * instead of a function pointer for the ones we're not using.  That
would let us make at least some of it less #iffy.


> It should be possible (from a very quick look) since all the platform
> specifics arguments are pointers to the specific types.
> I think that may be better solution, but regardless if you opt for it or
> not
>

I'm all for doing it better, but I'm more for getting it working.  i'll
push with your ack.
--Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20160610/132f5770/attachment.html>