On Thu, 2017-11-09 at 09:13 +0100, Nicolai Hähnle wrote: > 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
This is a GCN instruction. does it apply to terascale1,2,3 as well? Jan > > 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 srol...@vmware.com: > > > From: Roland Scheidegger <srol...@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@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > > > >
signature.asc
Description: This is a digitally signed message part
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
