[Mesa-dev] [PATCH 3/7] gallium: add FBFETCH opcode to retrieve the current sample value

[Ilia Mirkin]

On Mon, Jan 2, 2017 at 3:41 PM, Marek Olšák <maraeo at gmail.com> wrote:
> On Mon, Jan 2, 2017 at 7:01 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>> Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu>
>> ---
>>  src/gallium/auxiliary/tgsi/tgsi_info.c     |  2 +-
>>  src/gallium/docs/source/tgsi.rst           | 11 +++++++++++
>>  src/gallium/include/pipe/p_shader_tokens.h |  2 +-
>>  3 files changed, 13 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/gallium/auxiliary/tgsi/tgsi_info.c b/src/gallium/auxiliary/tgsi/tgsi_info.c
>> index 37549aa..e34b8c7 100644
>> --- a/src/gallium/auxiliary/tgsi/tgsi_info.c
>> +++ b/src/gallium/auxiliary/tgsi/tgsi_info.c
>> @@ -106,7 +106,7 @@ static const struct tgsi_opcode_info opcode_info[TGSI_OPCODE_LAST] =
>>     { 1, 3, 0, 0, 0, 0, 0, COMP, "CMP", TGSI_OPCODE_CMP },
>>     { 1, 1, 0, 0, 0, 0, 0, CHAN, "SCS", TGSI_OPCODE_SCS },
>>     { 1, 2, 1, 0, 0, 0, 0, OTHR, "TXB", TGSI_OPCODE_TXB },
>> -   { 0, 1, 0, 0, 0, 0, 1, NONE, "", 69 },      /* removed */
>> +   { 1, 1, 0, 0, 0, 0, 0, OTHR, "FBFETCH", TGSI_OPCODE_FBFETCH },
>>     { 1, 2, 0, 0, 0, 0, 0, COMP, "DIV", TGSI_OPCODE_DIV },
>>     { 1, 2, 0, 0, 0, 0, 0, REPL, "DP2", TGSI_OPCODE_DP2 },
>>     { 1, 2, 1, 0, 0, 0, 0, OTHR, "TXL", TGSI_OPCODE_TXL },
>> diff --git a/src/gallium/docs/source/tgsi.rst b/src/gallium/docs/source/tgsi.rst
>> index d2d30b4..accbe1d 100644
>> --- a/src/gallium/docs/source/tgsi.rst
>> +++ b/src/gallium/docs/source/tgsi.rst
>> @@ -2561,6 +2561,17 @@ Resource Access Opcodes
>>    image, while .w will contain the number of samples for multi-sampled
>>    images.
>>
>> +.. opcode:: FBFETCH - Load data from framebuffer
>> +
>> +  Syntax: ``FBFETCH dst, output``
>> +
>> +  Example: ``FBFETCH TEMP[0], OUT[0]``
>> +
>> +  Returns the color of the current position in the framebuffer from
>> +  before this fragment shader invocation. Always returns the same
>> +  value from multiple calls for a particular output within a single
>> +  invocation.
>
> If the value is always the same, can it be declared as a system value instead?

Yeah, that's probably better. I just didn't want to do it as an output
read, since that's currently defined and means something else
entirely; the sysval idea didn't occur to me. What would you think
about doing it as a sysval with semantic TGSI_SEMANTIC_COLOR?

Cheers,

  -ilia