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