[Mesa-dev] [PATCH v2] glsls: Modify exec_list to avoid strict-aliasing violations

[Eero Tamminen]

Hi,

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 
fake desired
InteL HW to Mesa with INTEL_DEVID_OVERRIDE environment variable.

Similarly to INTEL_NO_HW, it prevents batches from being submitted
to GPU.


> What exactly would INTEL_NO_HW=1 do?

http://www.mesa3d.org/envvars.html

"INTEL_NO_HW - if set to 1, prevents batches from being submitted to the 
hardware."

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 
INTEL_NO_HW.


> 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.


	- Eero