summaryrefslogtreecommitdiffstats
path: root/src/mesa/main/streaming-load-memcpy.c
Commit message (Collapse)AuthorAgeFilesLines
* mesa: Add missing _mm_mfence() before streaming loads.Matt Turner2015-10-051-0/+3
| | | | | | | | | | | | | | | | | According to the Intel Software Development Manual (Volume 1: Basic Architecture, 12.10.3 Streaming Load Hint Instruction): Streaming loads may be weakly ordered and may appear to software to execute out of order with respect to other memory operations. Software must explicitly use fences (e.g. MFENCE) if it needs to preserve order among streaming loads or between streaming loads and other memory operations. That is, a memory fence is needed to preserve the order between the GPU writing the buffer and the streaming loads reading it back. Reported-by: Joseph Nuzman <joseph.nuzman@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* Revert "mesa: Wrap SSE4.1 code in #ifdef __SSE4_1__."Emil Velikov2014-11-151-3/+0
| | | | | | | | | | | | | | | | | This reverts commit 8d3f739383fbdf671752fdec707f1c2b9b2aa6a3. In the last commit we've updated our check to determine if the actual code is buildable, rather than if the compiler acknowledges the option. I.e. did anyone provide -mno-sse4.1 vs is my compiler too old. Now this code will never be attemped to be build, in both cases. Confirmed by building mesa with export CFLAGS='-march=native -mno-sse4.1' ./configure && make Tested-by: David Heidelberg <david@ixit.cz> Reviewed-by: Matt Turner <mattst88@gmail.com>
* mesa: Wrap SSE4.1 code in #ifdef __SSE4_1__.Matt Turner2014-03-061-0/+3
| | | | | | | | Because people insist on doing things like explicitly disabling SSE 4.1. Cc: "10.0 10.1" <mesa-stable@lists.freedesktop.org> Tested-by: David Heidelberger <david.heidelberger@ixit.cz> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71547
* mesa: Add a streaming load memcpy implementation.Matt Turner2013-11-071-0/+85
Uses SSE 4.1's MOVNTDQA instruction (streaming load) to read from uncached memory without polluting the cache. Reviewed-by: Chad Versace <chad.versace@linux.intel.com>