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

[Tom Stellard]

On Thu, Feb 18, 2016 at 02:07:25AM +0100, Roland Scheidegger wrote:
> 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).

You can set feature flags on a per-function basis now, so it's possible
to have an avx and avx2 function in the same module.  I haven't actually
tried this, though, so I'm not sure now well it's working at the moment.

-Tom

> 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
> > 
> 
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev