[Mesa-dev] [PATCH 1/6] gallium: add some more double opcodes to avoid unnecessary lowering

Ilia Mirkin imirkin at alum.mit.edu
Fri Feb 20 11:18:53 PST 2015


On Fri, Feb 20, 2015 at 9:37 AM, Roland Scheidegger <sroland at vmware.com> wrote:
> Just some minor nits.
>
> Am 20.02.2015 um 00:52 schrieb Ilia Mirkin:
>> Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu>
>> ---
>>  src/gallium/auxiliary/tgsi/tgsi_info.c     |  5 ++++
>>  src/gallium/docs/source/tgsi.rst           | 39 ++++++++++++++++++++++++++++++
>>  src/gallium/include/pipe/p_shader_tokens.h |  7 +++++-
>>  3 files changed, 50 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/gallium/auxiliary/tgsi/tgsi_info.c b/src/gallium/auxiliary/tgsi/tgsi_info.c
>> index d04f9da..4d838fd 100644
>> --- a/src/gallium/auxiliary/tgsi/tgsi_info.c
>> +++ b/src/gallium/auxiliary/tgsi/tgsi_info.c
>> @@ -257,6 +257,11 @@ static const struct tgsi_opcode_info opcode_info[TGSI_OPCODE_LAST] =
>>     { 1, 1, 0, 0, 0, 0, COMP, "D2U", TGSI_OPCODE_D2U },
>>     { 1, 1, 0, 0, 0, 0, COMP, "U2D", TGSI_OPCODE_U2D },
>>     { 1, 1, 0, 0 ,0, 0, COMP, "DRSQ", TGSI_OPCODE_DRSQ },
>> +   { 1, 1, 0, 0, 0, 0, COMP, "DTRUNC", TGSI_OPCODE_DTRUNC },
>> +   { 1, 1, 0, 0, 0, 0, COMP, "DCEIL", TGSI_OPCODE_DCEIL },
>> +   { 1, 1, 0, 0, 0, 0, COMP, "DFLR", TGSI_OPCODE_DFLR },
>> +   { 1, 1, 0, 0, 0, 0, COMP, "DROUND", TGSI_OPCODE_DROUND },
>> +   { 1, 1, 0, 0, 0, 0, COMP, "DSSG", TGSI_OPCODE_DSSG },
>>  };
>>
>>  const struct tgsi_opcode_info *
>> diff --git a/src/gallium/docs/source/tgsi.rst b/src/gallium/docs/source/tgsi.rst
>> index e20af79..15f1e9f 100644
>> --- a/src/gallium/docs/source/tgsi.rst
>> +++ b/src/gallium/docs/source/tgsi.rst
>> @@ -1861,6 +1861,45 @@ two-component vectors with doubled precision in each component.
>>
>>    dst.zw = src.zw - \lfloor src.zw\rfloor
>>
>> +.. opcode:: DTRUNC - Truncate
>> +
>> +.. math::
>> +
>> +  dst.xy = trunc(src.xy)
>> +
>> +  dst.zw = trunc(src.zw)
>> +
>> +.. opcode:: DCEIL - Ceiling
>> +
>> +.. math::
>> +
>> +  dst.xy = \lceil src.xy\rceil
>> +
>> +  dst.zw = \lceil src.zw\rceil
>> +
>> +.. opcode:: DFLR - Floor
>> +
>> +.. math::
>> +
>> +  dst.xy = \lfloor src.xy\rfloor
>> +
>> +  dst.zw = \lfloor src.zw\rfloor
>> +
>> +.. opcode:: DROUND - Fraction
>> +
>> +.. math::
>> +
>> +  dst.xy = round(src.xy)
>> +
>> +  dst.zw = round(src.zw)
>> +
>> +.. opcode:: DSSG - Set Sign
>> +
>> +.. math::
>> +
>> +  dst.xy = (src.xy > 0) ? 1 : (src.xy < 0) ? -1 : 0
>> +
>> +  dst.zw = (src.zw > 0) ? 1 : (src.zw < 0) ? -1 : 0
> I think this would be more obvious written as 1.0/-1.0/0.0 (same goes
> for the non-double version, of course).

Yep, that was Dave's comment too. I've fixed it here, left SSG alone.

> (As a side note, I'm wondering if this actually has defined NaN
> behavior, the glsl language sort of implies a number has to be exactly
> one of these 3 cases, and doesn't give an answer what should be returned
> for a NaN - maybe a NaN?)

I'll leave that for another day :)

>
>>
>>  .. opcode:: DFRACEXP - Convert Number to Fractional and Integral Components
>>
>> diff --git a/src/gallium/include/pipe/p_shader_tokens.h b/src/gallium/include/pipe/p_shader_tokens.h
>> index fc41cc9..95ac590 100644
>> --- a/src/gallium/include/pipe/p_shader_tokens.h
>> +++ b/src/gallium/include/pipe/p_shader_tokens.h
>> @@ -519,7 +519,12 @@ struct tgsi_property_data {
>>  #define TGSI_OPCODE_D2U                 215
>>  #define TGSI_OPCODE_U2D                 216
>>  #define TGSI_OPCODE_DRSQ                217 /* eg, cayman also has DRSQ */
>> -#define TGSI_OPCODE_LAST                218
>> +#define TGSI_OPCODE_DTRUNC              218 /* nvc0 */
>> +#define TGSI_OPCODE_DCEIL               219 /* nvc0 */
>> +#define TGSI_OPCODE_DFLR                220 /* nvc0 */
>> +#define TGSI_OPCODE_DROUND              221 /* nvc0 */
>> +#define TGSI_OPCODE_DSSG                222
>> +#define TGSI_OPCODE_LAST                223
>
> I don't think these hw-specific references (nvc0) really fit in there -
> the same can be said about some existing ones (cayman...)

I went with the flow... started by Dave, I believe. Happy to remove
them all too. Dave -- thoughts?

  -ilia


More information about the mesa-dev mailing list