[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