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

Ben Widawsky ben at bwidawsk.net
Sat Dec 29 14:38:27 PST 2012


On Sat, 29 Dec 2012 13:21:02 -0800
Kenneth Graunke <kenneth at whitecape.org> wrote:

> On 12/29/2012 11:58 AM, Ben Widawsky wrote:
> > On Fri, 28 Dec 2012 21:21:51 -0800
> > Kenneth Graunke <kenneth at whitecape.org> wrote:
> >
> >> Every generation except Gen7 creates SURFACE_STATE entries via a
> >> uint32_t array.  Only Gen7 uses the older bitfield structure,
> >> which we moved away from because it was less efficient.  Convert
> >> it for consistency.
> >>
> >> This reduces the compiled size of gen7_wm_surface_state.o by 2.86%
> >> in a release build.
> >
> > Just pointing out that this sucks wrt to intel-gen4asm not being
> > able to directly copy the headers anymore.
> >
> > Hopefully someone can update it at some point, or else we'll have a
> > mess on our hands in the not too distant future.
> 
> Huh?  intel-gen4asm is for shaders...these are indirect state objects.

I meant i-g-t, my bad.

> 
> I haven't looked at the intel-gen4asm code in ages, but it could copy 
> over brw_defines.h, which is the core of the new approach.  It's what 
> defines the <FIELD>_SHIFT and <FIELD>_MASK macros, which can be used 
> with the GET_FIELD/SET_FIELD macros.  Or directly.  INTEL_MASK is
> also useful.
> 
> Also, it's already a giant mess: Mesa has a bunch of code, 
> intel-gpu-tools contains some of it, the standalone
> intel-gen4asm/disasm utilities have some other bits, and the DDX has
> a giant pile of shader code.  I'm afraid it's only going to get worse
> with Gen8, if people really are writing their own representation for
> shader instructions rather than using the one I wrote for Mesa...

This is a bit of a cheap shot if you ask me, but probably not
appropriate for an external list discussion at this point.

> 
> --Ken

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?


More information about the mesa-dev mailing list