[Mesa-stable] [PATCH 2/2] anv/entrypoints: Rework #if guards
Jason Ekstrand
jason at jlekstrand.net
Fri Jun 10 20:18:43 UTC 2016
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-stable/attachments/20160610/132f5770/attachment-0001.html>
More information about the mesa-stable
mailing list