Bug 101562 - Fetching from imageBuffer creates very poor GEN assembly
Summary: Fetching from imageBuffer creates very poor GEN assembly
Status: RESOLVED MOVED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: 17.1
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Intel 3D Bugs Mailing List
QA Contact: Intel 3D Bugs Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-06-23 07:30 UTC by Kevin Rogovin
Modified: 2019-09-25 19:02 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
tarball of results: .shader.txt is input shader, .asm.txt is outout of INTEL_DEBUG=fs (92.67 KB, application/gzip)
2017-06-23 07:30 UTC, Kevin Rogovin
Details

Description Kevin Rogovin 2017-06-23 07:30:47 UTC
Created attachment 132153 [details]
tarball of results: .shader.txt is input shader, .asm.txt is outout of INTEL_DEBUG=fs

If one uses an imageBuffer to fetch values and add them in either of the forms:

 value = start_value + get_value(0) + get_value(1) + ... 
or
 value = ((((((...(start_value + get_value(0)) + get_value(1)) + ... )

then the generated assembly is quite poor. It reserves O(n) registers (where n is the number of constants to fetch) at shader start, with those values placed into the registers having a large number of duplicates.

However, if the shader is:

 value = start_value;
 value += get_value(0);
 value += get_value(1); 

or if the constants are fetched though other means (UBO, TBO, SSBO) then the generated assembly is fine. This is in spite of the fact that the above is equivalent to the 2nd form of a one line add.

Attached is a battery of machine generated shaders and the output of INTEL_DEBUG=fs when compiling such shaders with a matching, but trivial, vertex shader.
Comment 1 GitLab Migration User 2019-09-25 19:02:52 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/1604.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.