I do wonder what the target machine is (I haven't seen one that would not have ARCH_X86_HAVE_SSE4_1 true, both 32bit and 64bit) but falling back to memcpy makes perfect sense without USE_SSE4_1;

Reviewed-by: Tapani Pälli <tapani.pa...@intel.com>

On 08/11/2017 08:52 AM, Kenneth Graunke wrote:
This should hopefully fix build issues on 32-bit Android-x86.

Cc: Mauro Rossi <issor.or...@gmail.com>
Cc: Tapani Pälli <tapani.pa...@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102050
  src/mesa/drivers/dri/i965/intel_buffer_objects.c | 2 ++
  1 file changed, 2 insertions(+)

Mauro, hopefully this helps?

diff --git a/src/mesa/drivers/dri/i965/intel_buffer_objects.c 
index ee591168283..9afd98edb87 100644
--- a/src/mesa/drivers/dri/i965/intel_buffer_objects.c
+++ b/src/mesa/drivers/dri/i965/intel_buffer_objects.c
@@ -342,6 +342,7 @@ brw_get_buffer_subdata(struct gl_context *ctx,
unsigned int map_flags = MAP_READ;
     mem_copy_fn memcpy_fn = memcpy;
+#ifdef USE_SSE4_1
     if (!intel_obj->buffer->cache_coherent && cpu_has_sse4_1) {
        /* Rather than acquire a new WB mmaping of the buffer object and pull
         * it into the CPU cache, keep using the WC mmap that we have for 
@@ -350,6 +351,7 @@ brw_get_buffer_subdata(struct gl_context *ctx,
        map_flags |= MAP_COHERENT;
        memcpy_fn = (mem_copy_fn) _mesa_streaming_load_memcpy;
void *map = brw_bo_map(brw, intel_obj->buffer, map_flags);
     if (unlikely(!map)) {

mesa-dev mailing list

Reply via email to