[Mesa-dev] Introducing OpenSWR: High performance software rasterizer

[Rowley, Timothy O]

> On Oct 20, 2015, at 12:44 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
> 
> On Tue, Oct 20, 2015 at 1:43 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>> On Tue, Oct 20, 2015 at 1:11 PM, Rowley, Timothy O
>> <timothy.o.rowley at intel.com> wrote:
>>> Does one build work on both AVX and AVX2?
>>> -----------------------------------------
>>> 
>>> * Unfortunately, no.  The architecture support is fixed at compile
>>>   time.  While the AVX version of course will run on AVX2 machines
>>>   and the jitted code will use AVX2, the overall performance will
>>>   suffer relative to a full AVX2 build.
>>> 
>>> * There is some idea that if we move some code from the driver back
>>>   to SWR core, we could build two versions of libSWR and dynamically
>>>   load the correct version at runtime.  Unfortunately this mechanism
>>>   would not work with AVX512, as some of the SWR state structures
>>>   would change size.
>> 
>> Without commenting on any of the other issues, I believe one of your
>> stated goals is to ease distribution to your end-users. If you expect
>> them to build their own code, that's no problem. However if you're
>> thinking of relying on distros to include your driver and have end
>> users use that, then you should consider some solution that enables
>> runtime selection of this stuff (even if that's building 3 versions of
>> the driver -- swr-avx, swr-avx2, swr-avx512, and having e.g. loader
>> magic determine which the right one is for the current CPU).

We’ve found that the large clusters tend to roll their own user environment specific to their system configuration, so this problem of binary support hasn’t been an immediate concern for the initial users.  We hadn’t considered building complete driver/core-swr combinations behind a loader; we’ll consider this as a possibility for avx512.

Most of the code movement to make runtime selection at the interface layer between core SWR and the driver has been done; we would need to verify any stray AVX/AVX2 architecture differences in the driver and add loader logic.

-Tim