[Mesa-dev] [PATCH 2/2] i965/tiled_memcpy: Protect against wrong alignments

[Roland Scheidegger]

Am 05.04.2016 um 19:19 schrieb Jason Ekstrand:
> 
> 
> On Tue, Apr 5, 2016 at 10:12 AM, Roland Scheidegger <sroland at vmware.com
> <mailto:sroland at vmware.com>> wrote:
> 
>     Am 05.04.2016 um 03:04 schrieb Jason Ekstrand:
>     > It's possible, when doing an x-tiled copy, to end up with a case
>     where the
>     > bytes parameter is equal to 16 but the pointer is not actually
>     aligned.
>     > This causes asserts in debug mode and segfaults in release builds
>     due to
>     > doing an aligned operation on an unaligned pointer.
>     >
>     > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93962
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.freedesktop.org_show-5Fbug.cgi-3Fid-3D93962&d=BQMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=Vjtt0vs_iqoI31UfJxBl7yv9I2FeiaeAYgMTLKRBc_I&m=_xsmWZKLTDm4kyo4jJX90KzCwvvz6XJhkigwJp558UU&s=KduSs0cTg64diPn0dBoQ6F_qwZFq2EiQTs79qdAg_TM&e=>
>     > ---
>     >  src/mesa/drivers/dri/i965/intel_tiled_memcpy.c | 48
>     +++++++++++++-------------
>     >  1 file changed, 24 insertions(+), 24 deletions(-)
>     >
>     > diff --git a/src/mesa/drivers/dri/i965/intel_tiled_memcpy.c
>     b/src/mesa/drivers/dri/i965/intel_tiled_memcpy.c
>     > index 19079d0..823d8b0 100644
>     > --- a/src/mesa/drivers/dri/i965/intel_tiled_memcpy.c
>     > +++ b/src/mesa/drivers/dri/i965/intel_tiled_memcpy.c
>     > @@ -85,19 +85,19 @@ rgba8_copy_aligned_dst(void *dst, const void
>     *src, size_t bytes)
>     >     uint8_t const *s = src;
>     >
>     >  #ifdef __SSSE3__
>     > -   if (bytes == 16) {
>     > -      assert(!(((uintptr_t)dst) & 0xf));
>     > -      rgba8_copy_16_aligned_dst(d+ 0, s+ 0);
>     > -      return dst;
>     > -   }
>     > +   if ((((uintptr_t)dst) & 0xf) == 0) {
>     > +      if (bytes == 16) {
>     > +         rgba8_copy_16_aligned_dst(d+ 0, s+ 0);
>     > +         return dst;
>     > +      }
>     >
>     > -   if (bytes == 64) {
>     > -      assert(!(((uintptr_t)dst) & 0xf));
>     > -      rgba8_copy_16_aligned_dst(d+ 0, s+ 0);
>     > -      rgba8_copy_16_aligned_dst(d+16, s+16);
>     > -      rgba8_copy_16_aligned_dst(d+32, s+32);
>     > -      rgba8_copy_16_aligned_dst(d+48, s+48);
>     > -      return dst;
>     > +      if (bytes == 64) {
>     > +         rgba8_copy_16_aligned_dst(d+ 0, s+ 0);
>     > +         rgba8_copy_16_aligned_dst(d+16, s+16);
>     > +         rgba8_copy_16_aligned_dst(d+32, s+32);
>     > +         rgba8_copy_16_aligned_dst(d+48, s+48);
>     > +         return dst;
>     > +      }
>     >     }
>     >  #endif
>     >
>     > @@ -123,19 +123,19 @@ rgba8_copy_aligned_src(void *dst, const void
>     *src, size_t bytes)
>     >     uint8_t const *s = src;
>     >
>     >  #ifdef __SSSE3__
>     > -   if (bytes == 16) {
>     > -      assert(!(((uintptr_t)src) & 0xf));
>     > -      rgba8_copy_16_aligned_src(d+ 0, s+ 0);
>     > -      return dst;
>     > -   }
>     > +   if ((((uintptr_t)src) & 0xf) == 0) {
>     > +      if (bytes == 16) {
>     > +         rgba8_copy_16_aligned_src(d+ 0, s+ 0);
>     > +         return dst;
>     > +      }
>     >
>     > -   if (bytes == 64) {
>     > -      assert(!(((uintptr_t)src) & 0xf));
>     > -      rgba8_copy_16_aligned_src(d+ 0, s+ 0);
>     > -      rgba8_copy_16_aligned_src(d+16, s+16);
>     > -      rgba8_copy_16_aligned_src(d+32, s+32);
>     > -      rgba8_copy_16_aligned_src(d+48, s+48);
>     > -      return dst;
>     > +      if (bytes == 64) {
>     > +         rgba8_copy_16_aligned_src(d+ 0, s+ 0);
>     > +         rgba8_copy_16_aligned_src(d+16, s+16);
>     > +         rgba8_copy_16_aligned_src(d+32, s+32);
>     > +         rgba8_copy_16_aligned_src(d+48, s+48);
>     > +         return dst;
>     > +      }
>     >     }
>     >  #endif
>     >
>     >
> 
>     Looks alright to me.
> 
> 
> Does that count as a revie? :-)
Yes. That said, I didn't know if you're actually supposed to hit that
code when things aren't aligned (which is why I didn't just change it).


>  
> 
>     Do you plan on reapplying the code which was
>     reverted due to bug 93962 mentioned there?
>     (Though honestly that code was part 2 of a 4-part series and I was only
>     really interested in parts 3 and 4 which noone ever reviewed... I think
>     they'd still have value today but maybe that's just me...)
> 
> 
> Yes, that was my plan.  The real bug still existed if you built with
> -mssse3.  Now that we've gotten it sorted out, the sse2 code should be
> fine as long as we make the corresponding change there..  It'd be nice
> to get that merged since I think you'd have to work pretty hard to find
> a machine with a GPU that works with the i965 driver and doesn't support
> SSE2.
Yes indeed.

Roland