[Mesa-dev] [PATCH] i965: Replace structs with bit-shifting for Gen7 SURFACE_STATE entries.

Kenneth Graunke kenneth at whitecape.org
Sat Dec 29 16:48:14 PST 2012


On 12/29/2012 02:38 PM, Ben Widawsky wrote:
> Anyway, we all agree it's a mess, and I just wanted to point out that
> this patch is the nail in the coffin. Maybe you should CC the
> maintainers for the other projects which depend on this?

The nail in the coffin of what, exactly?  intel-gpu-tools has code to 
deal with Gen7 surface states.  I'm not taking that away, and it will 
continue to work.  Nobody is being forced to do anything here.

Also, the only user of struct gen7_surface_state in intel-gpu-tools is 
rendercopy_gen7.c, and is exactly one 40 line function.  That's a 
trivial amount of code.  It could be updated in less time than it took 
to send these emails.

SNA and UXA both have non-trivial uses of gen7_surface_state, but 
consider this:

$ diff -u xf86-video-intel/src/brw_structs.h 
mesa/src/mesa/drivers/dri/i965/brw_structs.h | diffstat

  brw_structs.h | 2517 
++++++++++++++++++++++++++--------------------------------
  1 file changed, 1171 insertions(+), 1346 deletions(-)

That tells me: these two files have diverged so significantly that 
they're no longer the same.  And this is before applying my patch. 
There's no way you could simply copy one over the other.

So I don't see how my patch in any way influences the status quo.

One could argue that, for long term maintainability, we should share 
more code between Mesa/IGT/DDX/VAAPI.  We could try and find a solution 
involving a shared library.  We could also explicitly mark that certain 
components should only be edited in repo/project X, and copied from 
there, to avoid divergence.  But each of those comes with a cost and 
various trade-offs, which is why we've continued to punt on finding a 
solution...


More information about the mesa-dev mailing list