[Mesa-dev] [PATCH 09/13] SQUASH: i965/fs: Rework fs_visitor::lower_load_payload
mattst88 at gmail.com
Tue May 5 16:20:40 PDT 2015
On Tue, May 5, 2015 at 4:13 PM, Jason Ekstrand <jason at jlekstrand.net> wrote:
> On Wed, Apr 15, 2015 at 6:44 PM, Matt Turner <mattst88 at gmail.com> wrote:
>> On Wed, Apr 15, 2015 at 5:13 PM, Jason Ekstrand <jason at jlekstrand.net> wrote:
>>> On Wed, Apr 15, 2015 at 1:31 PM, Matt Turner <mattst88 at gmail.com> wrote:
>>>> On Wed, Apr 1, 2015 at 6:19 PM, Jason Ekstrand <jason at jlekstrand.net> wrote:
>>>>> Instead of the complicated and broken-by-design pile of heuristics we had
>>>>> before, we now have a straightforward lowering:
>>>>> 1) All header sources are copied directly using force_writemask_all and,
>>>>> since they are guaranteed to be a single register, there are no
>>>>> force_sechalf issues.
>>>>> 2) All non-header sources are copied using the exact same force_sechalf
>>>>> and saturate modifiers as the LOAD_PAYLOAD operation itself.
>>>> Let's not do this. Nothing puts a saturate modifier on LOAD_PAYLOAD
>>>> today, and it is kind of confusing about what it means. Can't we have
>>>> fbwrites that write depth as well. I wouldn't think we wanted to
>>>> saturate that.
>>> Sure. I can drop saturate and just assert that it's not set. We do
>>> want to keep force_sechalf and force_writemask_all though.
>> I didn't think about those before, but I don't know how a load_payload
>> could have force_writemask_all set. Have I missed something?
> No, no one (to my knowlege) sets force_writemask_all on it but I see
> no reason why it shouldn't be respected. As for saturate, we do for
> fb_writes when key->clamp_fragment_color is set.
In your last email in this thread, I thought we'd agreed not to do
anything (i.e., not allow) saturate on load_payload. Handling it seems
confusing and moreover, unnecessary.
More information about the mesa-dev