[Mesa-dev] i965: Splitting out FS codegen ***re-autogen required***

Kenneth Graunke kenneth at whitecape.org
Tue Nov 20 21:40:08 PST 2012


Hey all,

Here's a bunch of preliminary refactoring which should help me
implement the Gen8 code generator.

A bit of background: Gen8 uses a different instruction encoding than
Gen4-7 (essentially, a lot of bits got moved around), which means that
I can't use struct brw_instruction.  This basically also means that the
brw_eu_emit.c is useless to me, including the brw_compile struct with
the store of brw_instruction structs.

This patch series splits fs_visitor into two parts:

- fs_visitor translates GLSL or Mesa IR into FS IR, optimizes it, and
  performs register allocation (it's still a giant monolith, sadly).

  This contains the emit() functions.

- fs_generator generates the final assembly code, in a hardware specific
  format.  This is the part that deals with brw_instruction and brw_eu_emit.

  This corresponds to the generate() layer and all the code that lives in
  the (poorly named) brw_fs_emit.cpp file.  (We might want to rename that.)

  It actually generates both the SIMD8 and SIMD16 assembly together, as they
  need to be packed into a single program that can be uploaded to the GPU.

  Assembly generation can never fail.  (The only failure mode was due to
  unsupported opcodes, which is an internal driver bug, not a user error.)

For Gen8, I intend to replace fs_generator with a new backend, but reuse
the fs_visitor frontends.

A big reason for this refactoring is that my first attempt at a Gen8 code
generator managed to emit a mix of Gen4-7 and Gen8 instructions.  This is
really easy to do, since brw_eu.h tends to get included all over the place,
which gives you access to brw_instruction, emitter functions like brw_SAMPLE,
and struct brw_compile, containing the instruction store.  I want to ensure
that C++ code which mixes encodings won't compile.

By moving the brw_compile structure (commonly referred to as "p") into
fs_generator, I manage to isolate it into the part I'm replacing, which
means my new code won't have access to it, and thus can't mix encodings.

Thanks in advance for the feedback.

--Ken



More information about the mesa-dev mailing list