[Mesa-dev] [PATCH v2] glsls: Modify exec_list to avoid strict-aliasing violations
eero.t.tamminen at intel.com
Thu Jun 25 06:32:50 PDT 2015
On 06/25/2015 03:53 PM, Davin McCall wrote:
> On 25/06/15 12:27, Eero Tamminen wrote:
>> On 06/25/2015 02:48 AM, Davin McCall wrote:
>>> In terms of performance:
>>> (export LIBGL_ALWAYS_SOFTWARE=1; time glmark2)
>> For Intel driver, INTEL_NO_HW=1 could be used.
>> (Do other drivers have something similar?)
> Unfortunately I do not have an Intel display set up.
If you can get libINTEL_DEVID_OVERRIDEdrm to use libdrm_intel, you can
InteL HW to Mesa with INTEL_DEVID_OVERRIDE environment variable.
Similarly to INTEL_NO_HW, it prevents batches from being submitted
> What exactly would INTEL_NO_HW=1 do?
"INTEL_NO_HW - if set to 1, prevents batches from being submitted to the
I.e. driver does only CPU / user-space side things and skips GPU /
kernel side work.
>>> Again, only a very small improvement when strict aliasing is enabled.
>>> With the above in mind it is reasonable to question whether this patch
>>> is worthwhile.
>> IMHO to evaluate that, we would need data for more drivers, not just
>> for SW rendering.
> Given that we are talking about using a compiler option when compiling
> Mesa itself, I do not imagine that we would see a more significant
> change in performance when using HW assisted rendering. The code that
> runs on the GPU is the same in either case.
When testing 3D driver CPU side optimizations, one should either use
test specifically written for testing driver CPU overhead (proprietary
benchmarks have such tests) or force test-case to be CPU bound e.g. with
> Using the R600 driver (and Radeon 6770 hardware) I get:
> With -fno-strict-aliasing:
> glmark2 Score: 1614
> real 5m31.729s
> user 0m43.828s
> sys 0m20.892s
> With strict aliasing:
> glmark2 Score: 1626
> real 5m31.725s
> user 0m43.496s
> sys 0m20.924s
> This is all on x86, 32-bit. It's possible that more of an improvement
> would be seen on less register-starved architectures (including Intel
> x86-64), since more register spills/loads can potentially be avoided. I
> don't have the capability to test that right now. It's entirely possible
> that compiling without -fno-strict-aliasing on x86-64 will not (at
> present, even with this patch applied) produce a working library.
More information about the mesa-dev