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

[Roland Scheidegger]

Am 17.02.2016 um 22:09 schrieb Rowley, Timothy O:
>> On Nov 18, 2015, at 12:34 PM, Emil Velikov
>> <emil.l.velikov at gmail.com> wrote: I have no objections against
>> getting this merged, although here are a couple of things that
>> should be sorted. Some of these are just reiteration from others:
> 
> Sorry about the delay responding to this; we’ve been working on a
> number of the issues you mentioned (plus the usual year-end holidays
> and other work).
> 
>> - First and foremost - please base your work against master. Mesa, 
>> alike most other open-source projects, tries to keep features out
>> of bugfix releases. As such basing things against 11.0 is not
>> suitable.
> 
> Basing our efforts on a particular Mesa branch was an initial
> development decision to keep a stable base while we figured out how
> to build a driver from scratch.  We have now rebased to the Mesa
> master and periodically merge updates.
> 
>> - Further combinatorial explosion of build configurations - with 
>> internal/external core, swr-arch, etc. Some of these can (should?)
>> be nuked, although further comments will follow as patch(es) hit
>> the mailing list.
> 
> All the additional swr build options have been removed, leaving swr
> simply as an additional gallium driver that can be enabled.  The
> build-time architecture dependence has been addressed by building the
> swr driver twice (avx and avx2), and having swr_create_screen check
> the architecture and load the appropriate library.  I’m not
> completely satisfied with the current solution as since the driver is
> part of the loaded library we need to link most of mesa into the
> “driver”.  The fix for this seems to be to just build the core swr
> rasterizer architecture specific and dlopen/dlsym the fifty or so API
> entry points.  However this interim solution simplifies things for
> our users and removes the swr specific options from the general Mesa
> build system.
You could use different functions for avx and avx2 code, and plug the
right ones in at runtime, as you can link them both just fine. It just
requires that your code containing avx2 code is in a different compile
unit to the one containing avx-only code. This way you only really have
separate compiled code for the functions where there's really a
difference (obviously, this prevents the compiler from using avx2 on its
own in the shared parts, but I doubt that's a problem). Albeit if you
have lots of differences scattered around (the worst would probably be
different structures based on such difference used everywhere...) this
might not be very practical (at a first glance, didn't look like it at
least for avx and avx2).
Though I'm not actually sure how you would do that for c++ template
code, maybe it doesn't work as easily...
In any case, so far for llvmpipe we didn't bother (except for the jitted
code of course) to optimize for newer instruction sets precisely due to
it being annoying (certainly prevents you from doing "let's just
optimize this math here in this little inline function when avx is
available" - so we still have rasterization functions which emulate
sse41 _mm_mul_epi32 with _mm_mul_epu32 and so on).

Roland


> 
>> - Using llvm's C++ interface, building against multiple LLVM 
>> versions. If openswr only supports only limited versions of llvm,
>> then the build should bail out accordingly - more
>> comments/suggestions as patch(es) hit the ML.
> 
> OpenSWR now supports llvm 3.6, 3.7, and 3.8.  We don’t explicitly
> prevent people from trying to use llvm-svn, though as you say the C++
> api is not stable so they might encounter problems.
> 
>> - Will patches porting core openswr functionality from the
>> internal tree be part of the public discussions ? The VMWare people
>> have done a great thing trying to keep things open, and people
>> have, on the rare occasion, found nitpicks in their patches.
> 
> Moving patches from the internal rasterizer tree can be scripted at a
> top level, but unfortunately that’s the easy bit of keeping the two
> in sync when changes happen on both sides of the fence.  I can try
> tracking individual patches up to my git knowledge.
> 
>> - And last but not least - please split patches sensibly, for your 
>> submission and further work). The "Initial public Mesa+SWR"
>> touches files in quite a few different places.
> 
> I’m about to send the patches to the list for review; splitting them
> into the driver, rasterizer, mesa changes, and build system.
> 
>> Mildly related - I'll be resending/merging a series with reworks 
>> things in src/gallium/auxiliary/target-helpers/ so things might
>> clash as you rebase your work.
> 
> No problem - all part of working with a larger project.  Thanks for
> the heads-up.
> 
> -Tim
> 
> _______________________________________________ mesa-dev mailing
> list mesa-dev at lists.freedesktop.org 
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>