On Thu, Jan 16, 2014 at 5:33 PM, Carter Schonwald < [email protected]> 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 <[email protected]> wrote: > >> >> On 2014/01/17, at 0:12, Carter Schonwald <[email protected]> >> 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.
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
