Kenneth Graunke <kenn...@whitecape.org> writes: > On 11/18/2013 03:22 PM, Kenneth Graunke wrote: >> On 11/18/2013 12:27 PM, Eric Anholt wrote: >>> Kenneth Graunke <kenn...@whitecape.org> writes: >>> >>>> Broadwell significantly changes the EU instruction encoding. Many of >>>> the fields got moved to different bit positions; some even got split >>>> in two. >>>> >>>> With so many changes, it was infeasible to continue using struct >>>> brw_instruction. We needed a new representation. >>>> >>>> This new approach is a bit different: rather than a struct, I created a >>>> class that has four DWords, and helper functions that read/write various >>>> bits. This has several advantages: >>>> >>>> 1. We can create several different names for the same bits. For >>>> example, conditional modifiers, SFID for SEND instructions, and the >>>> MATH instruction's function opcode are all stored in bits 27:24. >>>> >>>> In each situation, we can use the appropriate setter function: >>>> set_sfid(), set_math_function(), or set_cond_modifier(). This >>>> is much easier to follow. >>>> >>>> 2. Since the fields are expressed using the original 128-bit numbers, >>>> the code to create the getter/setter functions follows the table in >>>> the documentation very closely. >>>> >>>> To aid in debugging, I've enabled -fkeep-inline-functions when building >>>> gen8_instruction.cpp. Otherwise, these functions cannot be called by >>>> gdb, making it insanely difficult to print out anything. >>> >>> I dislike C++ creep. >> >> I wrote this in C++ because all of the compiler infrastructure which >> uses it is already in C++. It seemed natural. >> >> However, Damien requested that we write it in C so it could be easily >> copied to xf86-video-intel, intel-gpu-tools, gen4asm/disasm, etc. Which >> is probably a good thing. He actually already ported it to C. > > For reference, Damien's C port of this code is in the public > intel-gpu-tools repo as assember/gen8_instruction.[ch]:
Looks like a pretty straightforward port, with a few more bitfields added. I'd consider it a feature to be using the same code as the other tree (even if we aren't actually using the same code from a library).
pgpmhcTXWu76s.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev