[rust-dev] RFC: Tuple Swizzling/Shuffling

Richard Diamond wichard at vitalitystudios.com
Thu Jan 16 23:57:13 PST 2014


On Thu, Jan 16, 2014 at 5:33 PM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> doesn't the opencl notation in the 16x case require 16^16 orders to be
> supported (even if its implicit in the parser support?)
> That said, if it can be engineered in sane way, sure, that'd be neat, how
> does the OpenCL notation work in the 16x simd case?
>
A float16 is accessed like v.s#, where v is a float16 type and # is a
single hex digit. It ain't pretty if one's not used to it.


> On Thu, Jan 16, 2014 at 6:16 PM, Jens Nockert <jens at nockert.se> wrote:
>
>>
>> On 2014/01/17, at 0:12, Carter Schonwald <carter.schonwald at gmail.com>
>> wrote:
>>
>> > whatever the notation, it needs to be one that
>> > a) gives good support for enforcing the "the shuffle is dictated at
>> compile time"
>> > b) is really simple, and easy to adjust for different size SIMD
>> vectors.   2x, 4x,8x,16x are all ones that currently and/or  will soon
>> exist on the CPU front at the very least!
>>
>> I prefer the OpenCL notation, vector.xyzw, vector.s0321 and so on.
>> Supports up to 16 elements, which is fine with most common SIMD types.
>> (AVX-512 with bytes and so on will always require horrible syntax, since
>> there are so many elements)
>
> I explicitly choose an index based element addressing scheme over
OpenGL/OpenCL's notation because:

   1. Not everyone speaks English; in fact, most people don't. Granted,
   most people on the Internet do.
   2. 'Most' SIMD types doesn't cut it for inclusion in a systems language
   or for the future in general; there's a lot of future left, so expect
   eventual use of SIMD types of unbounded size.
   3. There's nothing more natural for a systems language than offset
   indexing. There's nothing more generic either. I'm not saying that such a
   language shouldn't have features that make life easier for us mere mortals;
   I'm saying turning to the alphabet in this case would be a Bad Idea because
   they would be fulfilling the exact same role as a thing that does that role
   Better.
   4. OpenGL/OpenCL's notation is tacky (subjective, I know).
   5. i8x32 is already out of the question (and that's AVX1).
   6. someSimd.xyzw alphabet ordering/memory layout nonsense. What order is
   one actually using? Plus, apropos to #2 & #5, there aren't enough letters
   to support ze present or ze future.
   7. SIMD types are N-sized arrays of a primitive type; frankly, it's
   pretty smelly that rustc stipulates the use of tuple structures for this in
   the first place (not to mention the loss of inherent, simple element
   indexing), though I will acknowledge that the flaky support for stuffs like
   'type f32x4 = [f32, ..4]; impl f32x4 {}' or the lifetime hell of 'struct
   f32x4([f32x4]);' / 'strust f32x4 { priv d: [f32x4] };' makes the use of
   arrays less than ideal (the former plus compile time constant expressions
   in generics and, of course, swizzling, are going to make all the difference
   in the world to this end though) for SIMD use.

Following in the footsteps of OpenGL/OpenCL/mathematicians (particularly
the latter, who I think are well known for their 1337 software engineering
skillz && experience) in this regard would be a grave blunder for Rust.
That said, I think that supporting generic even/odd/etc masks (particularly
for certain swizzle--binop expressions that map to a somewhat common
instruction) would be advantageous, but that can be easily done without
involving rustc now that Mr. Fackler's external syntax extensions PR has
landed.

In other news, after prototyping what some basic CG maths would look like
and how it would 'write', I've decided to drop the lvalue form in favor of
the functional update form; Functional updates can be used in a way that
basically expresses the lvalue use. I didn't even use the lvalue form once
in the prototype and it's removal would simplify the changes needed to
rustc/syntax to just one new expression.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140117/5623f42a/attachment.html>


More information about the Rust-dev mailing list