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

[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. 

> - 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