[Mesa-dev] [PATCH 2/4] r600: use mysterious DX10_CLAMP bit in pixel shader setup

Nicolai Hähnle nhaehnle at gmail.com
Thu Nov 9 08:13:42 UTC 2017


The internal docs are pretty much the same (i.e. confusing and 
non-explicit), but my layman's reading of the RTL is that DX10_CLAMP 
only affects clamping. So if you have a

   v_mul_f32 0, inf

that will generate a NaN just fine and is simply unaffected by 
DX10_CLAMP. However, if the clamp bit is set on the instruction, it will 
generate 0 instead of NaN.

I don't think it affects anything else.

Cheers,
Nicolai

On 09.11.2017 04:08, Roland Scheidegger wrote:
> FWIW I'd really appreciate it if someone could shed some light on that
> mystery bit there...
> 
> Roland
> 
> Am 09.11.2017 um 03:58 schrieb sroland at vmware.com:
>> From: Roland Scheidegger <sroland at vmware.com>
>>
>> I don't know what this bit really does. The docs are somewhere between
>> misleading and wrong however, as at least the newer ones (that bit exists with
>> GCN as well) imply all NaNs would get converted to zeros, which is definitely
>> NOT the case (and that would not be dx10 compliant neither), the r600 ones are
>> also talking about "dx10 style" vs "dx9 style" clamp, whatever that means for
>> dx9... Makes no difference at all with piglit's isinf-and-isnan tests, so very
>> obviously NaNs are still generated just fine.
>> radeonsi also seems to set this bit nowadays (the llvm amdgpu code comment
>> now says "Make clamp modifier on NaN input returns 0" instead of "Do not
>> clamp NAN to 0" since it was changed).
>>
>> This prevents misrenderings in This War of Mine since using ieee
>> muls (ce7a045feeef8cad155f1c9aa07f166e146e3d00), without having to use
>> clamped rcp opcode, which would also fix this.
>>
>> AMD, it would be really really nice if there would be useful/correct/accurate
>> information about this bit...
>> The bit can be set for all shader stages, and maybe it should be set but I
>> really have no idea...
>>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103544
>> ---
>>   src/gallium/drivers/r600/evergreen_state.c | 1 +
>>   src/gallium/drivers/r600/r600_state.c      | 1 +
>>   2 files changed, 2 insertions(+)
>>
>> diff --git a/src/gallium/drivers/r600/evergreen_state.c b/src/gallium/drivers/r600/evergreen_state.c
>> index 96eb35a981..ddd59dc0b5 100644
>> --- a/src/gallium/drivers/r600/evergreen_state.c
>> +++ b/src/gallium/drivers/r600/evergreen_state.c
>> @@ -3235,6 +3235,7 @@ void evergreen_update_ps_state(struct pipe_context *ctx, struct r600_pipe_shader
>>   	r600_store_value(cb, /* R_028844_SQ_PGM_RESOURCES_PS */
>>   			 S_028844_NUM_GPRS(rshader->bc.ngpr) |
>>   			 S_028844_PRIME_CACHE_ON_DRAW(1) |
>> +			 S_028844_DX10_CLAMP(1) |
>>   			 S_028844_STACK_SIZE(rshader->bc.nstack));
>>   	/* After that, the NOP relocation packet must be emitted (shader->bo, RADEON_USAGE_READ). */
>>   
>> diff --git a/src/gallium/drivers/r600/r600_state.c b/src/gallium/drivers/r600/r600_state.c
>> index c21e8dabb1..c0d0b1667a 100644
>> --- a/src/gallium/drivers/r600/r600_state.c
>> +++ b/src/gallium/drivers/r600/r600_state.c
>> @@ -2548,6 +2548,7 @@ void r600_update_ps_state(struct pipe_context *ctx, struct r600_pipe_shader *sha
>>   	r600_store_context_reg_seq(cb, R_028850_SQ_PGM_RESOURCES_PS, 2);
>>   	r600_store_value(cb, /* R_028850_SQ_PGM_RESOURCES_PS*/
>>   			 S_028850_NUM_GPRS(rshader->bc.ngpr) |
>> +			 S_028850_DX10_CLAMP(1) |
>>   			 S_028850_STACK_SIZE(rshader->bc.nstack) |
>>   			 S_028850_UNCACHED_FIRST_INST(ufi));
>>   	r600_store_value(cb, exports_ps); /* R_028854_SQ_PGM_EXPORTS_PS */
>>
> 
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 


-- 
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.


More information about the mesa-dev mailing list