[Mesa-dev] [PATCH 0/18] Misc genxml patches

[Kristian Høgsberg]

Thanks! I'll keep 15 and 17 out. I'd still like to have tile mode as an
enum, but maybe I'll make the generator split inline values out as enums -
or maybe just when you've specified an enum name as the type. That is,

    <field name="Tile Mode" start="12" end="13" type="TILE_MODE">
      <value name="LINEAR" value="0"/>
      <value name="WMAJOR" value="1"/>
      <value name="XMAJOR" value="2"/>
      <value name="YMAJOR" value="3"/>
    </field>

generates

enum GEN9_TILE_MODE {
   LINEAR = 0,
   WMAJOR = 1,
   XMAJOR = 2,
   YMAJOR = 3,
};

and

struct GEN9_SURFACE_STATE {
   ...
   enum GEN9_TILE_MODE TileMode;
   ...
};

Kristian

On Tue, Nov 29, 2016 at 4:19 PM Jason Ekstrand <jason at jlekstrand.net> wrote:

> I'm a bit inclined to drop patch 15 because I think tile mode deserves to
> remain inline.  I don't care about 17.  I didn't really review it for not
> breaking things though.  The rest are
>
> Reviewed-by: Jason Ekstrand <jason at jlekstrand.net>
>
> Don't push until you get Jenkins' ok though!
>
> --Jason
>
> On Tue, Nov 29, 2016 at 12:55 PM, Kristian Høgsberg <hoegsberg at gmail.com>
> wrote:
>
> On Tue, Nov 29, 2016 at 12:48 PM Kristian H. Kristensen <
> hoegsberg at gmail.com> wrote:
>
> Hi,
>
> Here's a few patches to the genxml files that I've been sitting on. The
> main part of the series is about emitting C enums for genxml enums, so
> it looks nice and pretty in gdb. It also adds support to aubinator so
> it knows how to decode enums as well as the inline values Lionel added
> support for:
>
>     Surface Array: true
>     Surface Format: 2 (R32G32B32A32_UINT)
>     Surface Vertical Alignment: 1 (VALIGN 4)
>
> Look at that surface format being decoded! Patch 17 is "take it or
> leave it". I know nothing in mesa needs unpack functions, but I wouldn't
> mind having it upstream so I don't lose it (again).
>
>
> Oh, and true to form, I forgot the most important point: patch 16 is a
> legitimate
> fix for the compute shader KSP being split across a innocuous looking
> KernelStartPointer
> 32 bit field and a 16 bit "Kernel Start Pointer High" field. The driver
> doesn't know this
> and only sets KernelStartPointer. As long as anv uses instruction base
> offset, it's unlikely to
> cause a problem, but should be fixed.
>
> Kristian
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20161130/e4dbbda2/attachment.html>