[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