On Fri, Sep 29, 2017 at 5:03 PM, Scott D Phillips <[email protected]> wrote: > Matt Turner <[email protected]> writes: > >> The instruction word contains SubRegNum[4:2] so it's in units of dwords >> (hence the * 4 to get it in terms of bytes). Before this patch, the >> subreg would have been wrong for DF arguments. > > Trying to grok the subregnum stuff here, in brw_eu_emit.c I see: > > static int > get_3src_subreg_nr(struct brw_reg reg) > { > > /* Normally, SubRegNum is in bytes (0..31). However, 3-src > * instructions use 32-bit units (components 0..7). Since they > * only support F/D/UD types, this doesn't lose any > * flexibility, but uses fewer bits. > */ > > return reg.subnr / 4; > } > > Does the code above need updated for DF registers too? Or is that > already accounted for somehow?
Nope, it does not, but that's a good question nonetheless. Align1 mode has SubRegNum[4:0], which means it can represent subregister numbers from 0-31. Regular (1 and 2 source) align16 instructions only have SubRegNum[4], which means it can represent subregister numbers of only 0 and 16. 3-source instructions, which until CNL are only available in align16 mode, use a different instruction format in order to fit the extra source. In order to do that, they lose some flexibility available to 1-2 source instructions like the full range of datatypes. Only F, D, UD, and DF datatypes are supported, so there's no need for subregister bits for offsets lower than four bytes, but they do offer a bit for replication (called RepCtrl) that picks a single value and replicates it to all channels. For that you want more than just the SubRegNum[4] offered by regular align16 instructions, so they made it SubRegNum[4:2], which is capable of representing any four-byte aligned subregister. With doubles, you'd just never use bit 2. The code in get_3src_subreg_nr() is just an easy hack chop off the low two bits from reg.subnr in order to go to the SubRegNum[4:2] form. > I'm probably just missing something. With an explanation Patches 1-3 are: > > Reviewed-by: Scott D Phillips <[email protected]> Thanks! _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
