color lib

[Manu via Digitalmars-d]

On 9 October 2016 at 18:39, Nicholas Wilson via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On Sunday, 9 October 2016 at 05:34:06 UTC, Ilya Yaroshenko wrote:
>>
>> On Sunday, 9 October 2016 at 05:21:32 UTC, Manu wrote:
>>>
>>> On 9 October 2016 at 14:03, Nicholas Wilson via Digitalmars-d
>>> <digitalmars-d at puremagic.com> wrote:
>>>>
>>>> [...]
>>>
>>>
>>> Well the trouble is the lambda that you might give to 'map' won't work
>>> anymore. Operators don't work on batches, you need to use a completely
>>> different API, and I think that's unfortunate.
>>
>>
>> Could you please give an example what type of operation should be
>> vectorized?
>
>
> anything that is able to be. Given that ElementType!InBatchesOfN are a
> static array
> of ElementType!(R), the compiler can* (assuming no branching and anything
> else that impedes vectorisation) combine most expressions into equivalent
> vector instruction.
> This approach might not work so well for colours as is but should work if we
> "transpose" the colour i.e. rgbargbargbargba -> rrrrggggbbbbaaaa and then
> transpose it back.
>
> *I know this is the sufficiently intelligent compiler argument

I've been waiting for that compiler for almost 2 decades. I've shipped
17 commercial games in that time while waiting, and I had to resort to
manual code that didn't yet have an opportunity to leverage such a
sufficiently intelligent compilers awesome optimiser.
I've never seen an auto-vectoriser go ANYWHERE NEAR the sort of
intelligence required here. I've seen it start to do some good work
with arrays of floats... that's about where it ends.
Arrays of RGBA_10_10_10_2 require unpacking, and then shuffling. When
you stuff the unpack in the way, that will almost always throw an
auto-vectoriser off the scent. I'm also waiting to see saturation
expressions written in C code promote to saturating SIMD arithmetic.
Basically every operation is saturating when working with colours.