[Mesa-dev] [PATCH 09/13] SQUASH: i965/fs: Rework fs_visitor::lower_load_payload

[Matt Turner]

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

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.