Hi Tony, The “views" as they stand do not handle unpacked representations directly, though that doesn’t mean that you can’t mix vectors of different data types. When dealing with unpacked data, we envisioned that users would generate a view for the largest data type (in your example 32b), and handle data zeroing/preserving within the lanes explicitly. Adding direct support for unpacked representations would probably complicate the design a little, as we’d need to specify a “small” and “big” data type for the view (there would be more options than just updating the lowest half of a lane, if we want to keep the design generic). I don’t see major issues with the current implementation wrt handling unpacked data, but if you have ideas on how to improve the ergonomics (possibly without complicating too much the design), I’d be happy to hear about them.
I hope this helps. Thanks, Giacomo On 15/07/2017, 00:56, "gem5-dev on behalf of Gutierrez, Anthony" <[email protected] on behalf of [email protected]> wrote: >Hi All, > >I am trying to replace our GPU model's vector register implementation with the >one recently release by ARM: >https://gem5.googlesource.com/public/gem5/+/0747a432d25ade2c197ca6393270e12606419872, > and I noticed an issue I didn't catch when I previously reviewed the patch. > >From the code, it seems that views of a vector register will break if we try >to mix VecElem types across views. What I mean is, if we have a vector >register file where each vector register is 64 lanes of uint32_t, trying to do >an operation that views a vector register with lanes of uint16_t will only >update the first half of the vector register with respect to an operation that >views the vector register as uint32_t. > >Was that the intention? If so, how did you envision people handling operations >of various sizes on the vector registers (i.e., updating only the lower 16b of >a 32b lane)? I am thinking I will need to add support for some partial lane >views, because our GPU instructions can do 16b operations that only update the >lower bits of a 32b lane, but that has to be done across all lanes. > >-Tony >_______________________________________________ >gem5-dev mailing list >[email protected] >http://m5sim.org/mailman/listinfo/gem5-dev IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
