[Libclc-dev] [PATCH 1/9] RFC: Refactor clcmacro.h to vectorize without hi/lo

Tom Stellard tom at stellard.net
Wed Aug 6 11:20:12 PDT 2014


On Fri, Aug 01, 2014 at 11:27:48PM -0500, Aaron Watry wrote:
> On Fri, Aug 1, 2014 at 4:57 PM, Tom Stellard <tom at stellard.net> wrote:
> > On Fri, Aug 01, 2014 at 03:48:10PM -0500, Aaron Watry wrote:
> >> On Thu, Jul 31, 2014 at 8:50 PM, Tom Stellard <tom at stellard.net> wrote:
> >> > On Wed, Jul 30, 2014 at 05:34:27PM -0500, Aaron Watry wrote:
> >> >> LLVM: git 6800393083a4030 / svn r213860 (From 7/24)
> >> >> CLANG: git 5ce5cbd836b3 / svn r213853
> >> >> libclc: git a63df067faf8a / svn r213762 with the following two patches applied:
> >> >>
> >> >> r600: Actually use vstore assembly optimizations
> >> >> r600: improve float vload/vstore path
> >> >>
> >> >> With that setup, and mesa 0ddc28b026688d, I get failures in the
> >> >> float16 nextafter tests.
> >> >>
> >> >
> >> > OK, I will try this.  I think I may not have had those two libclc
> >> > patches applied when I tested.
> >> >
> >>
> >> That would be helpful.  I'm trying to recover at the moment from
> >> something that got upgraded and broke all of my systems which are
> >> built against upgraded mesa/llvm versions. Until I can resolve that
> >> issue, I'm unable to do any CL dev work on Evergreen and CL or GL on
> >> SI.
> >>
> >
> > Could this be caused by the recent version bump of LLVM from 3.5 to 3.6?
> >
> 
> Nope, LLVM seems fine. I've rebuilt it from scratch and nuked my
> install prefix before re-installing my entire graphics stack and
> force-removing all of the distro-provided
> mesa/llvm/xserver-xorg-video-ati/glamor packages.
> 
> I've spent most of the evening on it, but eventually tracked the issue
> on my radeonsi to the following mesa commit (which matches what I
> bisected on my evergreen system earlier):
> 
> 3b176c441b7ddc5f7d2f891da3f76cf3c1814ce1 is the first bad commit
> commit 3b176c441b7ddc5f7d2f891da3f76cf3c1814ce1
> Author: Giovanni Campagna <gcampagna at src.gnome.org>
> Date:   Wed Jul 23 19:37:31 2014 +0100
> 
>     gallium: Add a dumb drm/kms winsys backed swrast provider
> 
>     Add a new winsys and target that can be used with a dri2 state tracker
>     and loader instead of drisw. This allows to use gbm as a dri2/image
>     loader and avoid the extra copy from the backbuffer to the shadow
>     frontbuffer.
> 
>     The new driver is called "kms_swrast", and is loaded by gbm as a
>     fallback, because it is only useful with the gbm platform (as no buffer
>     sharing is possible)
> 
>     To force select the driver set the environment variable
>     GBM_ALWAYS_SOFTWARE
> 
>     [Emil Velikov]
>      - Rebase on top of gallium megadriver.
>      - s/text/test/ in configure.ac (Spotted by Andreas Pokorny).
>      - Add scons support for winsys/sw/kms-dri and fix the build.
>      - Provide separate DriverAPI, due to different InitScreen hook.
> 
>     Signed-off-by: Emil Velikov <emil.l.velikov at gmail.com>
> 
> 
> 
> So for now, I can at least run cl programs again on my home system,
> which claims that the nextafter test still fails with
> llvm/clang/libclc head revisions with the two patches in question
> applied (enable vstore bitcode optimizations on r600 and then add
> float to the i32 load/store paths)...
> 

I was able to reproduce this failure and it is a bug in either the DAg
Legalizer or the  R600 backend.  concat_vectors is being lowered by
storing the vectors to the stack and then loading the result.

This is a very inefficient way to implement lowering, but it should still
work.  I'm working on a fix for this now.

-Tom

> So it doesn't look like Matt's alignment changes helped this scenario,
> or maybe we're still running into another bug (which the clcmacro.h
> refactor papers over).  At least on my system (pitcairn).
> 
> --Aaron
> 
> 
> > -Tom
> >
> >> If we can confirm that the llvm patches for alignment issues fixed the
> >> use of those 2 patches on their own, then I'm at least happy to drop
> >> the clcmacro.h refactoring.  I just can't actually test that myself at
> >> the moment.
> >>
> >> --Aaron
> >>
> >> > -Tom
> >> >
> >> >> I'll give a shot at updating llvm/clang when I get home and see if
> >> >> that helps things out.  I had noticed earlier today that Matt had
> >> >> recently committed a bunch of vector load/store and alignment changes
> >> >> (r214055 looks especially applicable), so maybe something in there did
> >> >> the trick.
> >> >>
> >> >> --Aaron
> >> >>
> >> >> On Wed, Jul 30, 2014 at 3:39 PM, Tom Stellard <tom at stellard.net> wrote:
> >> >> > On Sat, Jul 26, 2014 at 03:12:30PM -0500, Aaron Watry wrote:
> >> >> >> On Fri, Jul 25, 2014 at 9:40 PM, Tom Stellard <tom at stellard.net> wrote:
> >> >> >> > On Tue, Jul 22, 2014 at 08:46:42PM -0500, Aaron Watry wrote:
> >> >> >> >> There are odd things happening with 16x vectors in nextafter() and sign().
> >> >> >> >>
> >> >> >> >> When I changed float16 load/store to use the assembly path in later
> >> >> >> >> patches instead of the macro-vectorized version, nextafter and sign
> >> >> >> >> stopped working (next 2 commits/patches).
> >> >> >> >>
> >> >> >> >> As near as I can tell, we're getting correct results for
> >> >> >> >> elements 0-7, but then elements 8+ are wrong. The final result
> >> >> >> >> seems to be composed of the first 8 elements of the computed
> >> >> >> >> result, and then elements 16-23, which are likely uninitialized.
> >> >> >> >>
> >> >> >> >> I'd like to say the issue is in clang, but I have nothing to back
> >> >> >> >> that up at the moment and give that this patch fixes the issue, I’m
> >> >> >> >> not sure how much time I want to spend investigating right now.
> >> >> >> >>
> >> >> >> >> Explicitly splitting all of the vectorize macros the way that this patch
> >> >> >> >> does gets everything working again, but I have a feeling that we're
> >> >> >> >> papering over a bug somewhere, hence the RFC subject.
> >> >> >> >>
> >> >> >> >> I’m not sure what’s going on here, and it’s only the nextafter/sign
> >> >> >> >> functions that regressed. This patch fixes the test results in piglit.
> >> >> >> >>
> >> >> >> >> No significant change on number of instructions in bitcode
> >> >> >> >> for nextafter float16 (2-3 instructions savings over ~350 lines).
> >> >> >> >>
> >> >> >> >
> >> >> >> > Were you testing this on Evergreen?  The sign() test passes for me on
> >> >> >> > SI without this patch.
> >> >> >> >
> >> >> >>
> >> >> >> I don't have my EG card available at the moment, but I *think* that
> >> >> >> passed.  All I've got available at the moment is my pitcairn (si). For
> >> >> >> me on pitcairn, I get failures in
> >> >> >> piglit/generated_tests/cl/builtin/math/builtin-float-nextafter-1.0.generated.cl
> >> >> >> for only the float16 type (about half of them pass, half don't).
> >> >> >>
> >> >> >
> >> >> > This test passes for me too.  How current is your install of LLVM, I think there
> >> >> > were some shufflevector fixes/improvements recently that may have fixed this test.
> >> >> >
> >> >> > -Tom
> >> >> >
> >> >> >> What happens if you test with [1] and [2] applied (enable vstore
> >> >> >> optimizations and then add float to those optimizations), but without
> >> >> >> the clcmacro refactoring patch [3]?
> >> >> >>
> >> >> >> [1] http://www.pcc.me.uk/pipermail/libclc-dev/2014-July/000461.html
> >> >> >> [2] http://www.pcc.me.uk/pipermail/libclc-dev/2014-July/000462.html
> >> >> >> [3] http://www.pcc.me.uk/pipermail/libclc-dev/2014-July/000460.html
> >> >> >>
> >> >> >> --Aaron
> >> >> >>
> >> >> >> > -Tom
> >> >> >> >
> >> >> >> >> Signed-off-by: Aaron Watry <awatry at gmail.com>
> >> >> >> >> ---
> >> >> >> >>  generic/lib/clcmacro.h | 84 +++++++++++++++++++++++++++++++++++++++++++-------
> >> >> >> >>  1 file changed, 73 insertions(+), 11 deletions(-)
> >> >> >> >>
> >> >> >> >> diff --git a/generic/lib/clcmacro.h b/generic/lib/clcmacro.h
> >> >> >> >> index 730073a..64b1770 100644
> >> >> >> >> --- a/generic/lib/clcmacro.h
> >> >> >> >> +++ b/generic/lib/clcmacro.h
> >> >> >> >> @@ -1,44 +1,106 @@
> >> >> >> >>  #define _CLC_UNARY_VECTORIZE(DECLSPEC, RET_TYPE, FUNCTION, ARG1_TYPE) \
> >> >> >> >>    DECLSPEC RET_TYPE##2 FUNCTION(ARG1_TYPE##2 x) { \
> >> >> >> >> -    return (RET_TYPE##2)(FUNCTION(x.x), FUNCTION(x.y)); \
> >> >> >> >> +    return (RET_TYPE##2){FUNCTION(x.s0), FUNCTION(x.s1)}; \
> >> >> >> >>    } \
> >> >> >> >>  \
> >> >> >> >>    DECLSPEC RET_TYPE##3 FUNCTION(ARG1_TYPE##3 x) { \
> >> >> >> >> -    return (RET_TYPE##3)(FUNCTION(x.x), FUNCTION(x.y), FUNCTION(x.z)); \
> >> >> >> >> +    return (RET_TYPE##3){FUNCTION(x.s0), FUNCTION(x.s1), FUNCTION(x.s2)}; \
> >> >> >> >>    } \
> >> >> >> >>  \
> >> >> >> >>    DECLSPEC RET_TYPE##4 FUNCTION(ARG1_TYPE##4 x) { \
> >> >> >> >> -    return (RET_TYPE##4)(FUNCTION(x.lo), FUNCTION(x.hi)); \
> >> >> >> >> +    return (RET_TYPE##4){ \
> >> >> >> >> +      FUNCTION(x.s0), \
> >> >> >> >> +      FUNCTION(x.s1), \
> >> >> >> >> +      FUNCTION(x.s2), \
> >> >> >> >> +      FUNCTION(x.s3), \
> >> >> >> >> +    }; \
> >> >> >> >>    } \
> >> >> >> >>  \
> >> >> >> >>    DECLSPEC RET_TYPE##8 FUNCTION(ARG1_TYPE##8 x) { \
> >> >> >> >> -    return (RET_TYPE##8)(FUNCTION(x.lo), FUNCTION(x.hi)); \
> >> >> >> >> +    return (RET_TYPE##8){ \
> >> >> >> >> +      FUNCTION(x.s0), \
> >> >> >> >> +      FUNCTION(x.s1), \
> >> >> >> >> +      FUNCTION(x.s2), \
> >> >> >> >> +      FUNCTION(x.s3), \
> >> >> >> >> +      FUNCTION(x.s4), \
> >> >> >> >> +      FUNCTION(x.s5), \
> >> >> >> >> +      FUNCTION(x.s6), \
> >> >> >> >> +      FUNCTION(x.s7), \
> >> >> >> >> +    }; \
> >> >> >> >>    } \
> >> >> >> >>  \
> >> >> >> >>    DECLSPEC RET_TYPE##16 FUNCTION(ARG1_TYPE##16 x) { \
> >> >> >> >> -    return (RET_TYPE##16)(FUNCTION(x.lo), FUNCTION(x.hi)); \
> >> >> >> >> +    return (RET_TYPE##16){ \
> >> >> >> >> +      FUNCTION(x.s0), \
> >> >> >> >> +      FUNCTION(x.s1), \
> >> >> >> >> +      FUNCTION(x.s2), \
> >> >> >> >> +      FUNCTION(x.s3), \
> >> >> >> >> +      FUNCTION(x.s4), \
> >> >> >> >> +      FUNCTION(x.s5), \
> >> >> >> >> +      FUNCTION(x.s6), \
> >> >> >> >> +      FUNCTION(x.s7), \
> >> >> >> >> +      FUNCTION(x.s8), \
> >> >> >> >> +      FUNCTION(x.s9), \
> >> >> >> >> +      FUNCTION(x.sa), \
> >> >> >> >> +      FUNCTION(x.sb), \
> >> >> >> >> +      FUNCTION(x.sc), \
> >> >> >> >> +      FUNCTION(x.sd), \
> >> >> >> >> +      FUNCTION(x.se), \
> >> >> >> >> +      FUNCTION(x.sf) \
> >> >> >> >> +    }; \
> >> >> >> >>    }
> >> >> >> >>
> >> >> >> >>  #define _CLC_BINARY_VECTORIZE(DECLSPEC, RET_TYPE, FUNCTION, ARG1_TYPE, ARG2_TYPE) \
> >> >> >> >>    DECLSPEC RET_TYPE##2 FUNCTION(ARG1_TYPE##2 x, ARG2_TYPE##2 y) { \
> >> >> >> >> -    return (RET_TYPE##2)(FUNCTION(x.x, y.x), FUNCTION(x.y, y.y)); \
> >> >> >> >> +    return (RET_TYPE##2){FUNCTION(x.s0, y.s0), FUNCTION(x.s1, y.s1)}; \
> >> >> >> >>    } \
> >> >> >> >>  \
> >> >> >> >>    DECLSPEC RET_TYPE##3 FUNCTION(ARG1_TYPE##3 x, ARG2_TYPE##3 y) { \
> >> >> >> >> -    return (RET_TYPE##3)(FUNCTION(x.x, y.x), FUNCTION(x.y, y.y), \
> >> >> >> >> -                         FUNCTION(x.z, y.z)); \
> >> >> >> >> +    return (RET_TYPE##3){FUNCTION(x.s0, y.s0), FUNCTION(x.s1, y.s1), \
> >> >> >> >> +                         FUNCTION(x.s2, y.s2)}; \
> >> >> >> >>    } \
> >> >> >> >>  \
> >> >> >> >>    DECLSPEC RET_TYPE##4 FUNCTION(ARG1_TYPE##4 x, ARG2_TYPE##4 y) { \
> >> >> >> >> -    return (RET_TYPE##4)(FUNCTION(x.lo, y.lo), FUNCTION(x.hi, y.hi)); \
> >> >> >> >> +    return (RET_TYPE##4){ \
> >> >> >> >> +      FUNCTION(x.s0, y.s0), \
> >> >> >> >> +      FUNCTION(x.s1, y.s1), \
> >> >> >> >> +      FUNCTION(x.s2, y.s2), \
> >> >> >> >> +      FUNCTION(x.s3, y.s3), \
> >> >> >> >> +    }; \
> >> >> >> >>    } \
> >> >> >> >>  \
> >> >> >> >>    DECLSPEC RET_TYPE##8 FUNCTION(ARG1_TYPE##8 x, ARG2_TYPE##8 y) { \
> >> >> >> >> -    return (RET_TYPE##8)(FUNCTION(x.lo, y.lo), FUNCTION(x.hi, y.hi)); \
> >> >> >> >> +    return (RET_TYPE##8){ \
> >> >> >> >> +      FUNCTION(x.s0, y.s0), \
> >> >> >> >> +      FUNCTION(x.s1, y.s1), \
> >> >> >> >> +      FUNCTION(x.s2, y.s2), \
> >> >> >> >> +      FUNCTION(x.s3, y.s3), \
> >> >> >> >> +      FUNCTION(x.s4, y.s4), \
> >> >> >> >> +      FUNCTION(x.s5, y.s5), \
> >> >> >> >> +      FUNCTION(x.s6, y.s6), \
> >> >> >> >> +      FUNCTION(x.s7, y.s7), \
> >> >> >> >> +    }; \
> >> >> >> >>    } \
> >> >> >> >>  \
> >> >> >> >>    DECLSPEC RET_TYPE##16 FUNCTION(ARG1_TYPE##16 x, ARG2_TYPE##16 y) { \
> >> >> >> >> -    return (RET_TYPE##16)(FUNCTION(x.lo, y.lo), FUNCTION(x.hi, y.hi)); \
> >> >> >> >> +    return (RET_TYPE##16){ \
> >> >> >> >> +      FUNCTION(x.s0, y.s0), \
> >> >> >> >> +      FUNCTION(x.s1, y.s1), \
> >> >> >> >> +      FUNCTION(x.s2, y.s2), \
> >> >> >> >> +      FUNCTION(x.s3, y.s3), \
> >> >> >> >> +      FUNCTION(x.s4, y.s4), \
> >> >> >> >> +      FUNCTION(x.s5, y.s5), \
> >> >> >> >> +      FUNCTION(x.s6, y.s6), \
> >> >> >> >> +      FUNCTION(x.s7, y.s7), \
> >> >> >> >> +      FUNCTION(x.s8, y.s8), \
> >> >> >> >> +      FUNCTION(x.s9, y.s9), \
> >> >> >> >> +      FUNCTION(x.sa, y.sa), \
> >> >> >> >> +      FUNCTION(x.sb, y.sb), \
> >> >> >> >> +      FUNCTION(x.sc, y.sc), \
> >> >> >> >> +      FUNCTION(x.sd, y.sd), \
> >> >> >> >> +      FUNCTION(x.se, y.se), \
> >> >> >> >> +      FUNCTION(x.sf, y.sf) \
> >> >> >> >> +    }; \
> >> >> >> >>    }
> >> >> >> >>
> >> >> >> >>  #define _CLC_DEFINE_BINARY_BUILTIN(RET_TYPE, FUNCTION, BUILTIN, ARG1_TYPE, ARG2_TYPE) \
> >> >> >> >> --
> >> >> >> >> 1.9.1
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> _______________________________________________
> >> >> >> >> Libclc-dev mailing list
> >> >> >> >> Libclc-dev at pcc.me.uk
> >> >> >> >> http://www.pcc.me.uk/cgi-bin/mailman/listinfo/libclc-dev




More information about the Libclc-dev mailing list