Am 11.04.2013 22:52, schrieb Zack Rusin:
>> - Original Message -
>>> - Original Message -
Ah.. This indeed rings a bell. I don't recall the details but I'm pretty
sure
I was against dual semantics. And the fact that this problem is again
showing its ugly head is
- Original Message -
> > - Original Message -
> > > - Original Message -
> > > > Ah.. This indeed rings a bell. I don't recall the details but I'm
> > > > pretty
> > > > sure
> > > > I was against dual semantics. And the fact that this problem is again
> > > > showing its
Actually our svga driver seems to think that the IF opcode works like
that. Since it will translate it into a SVGA3DOP_IFC (which corresponds
to shader model 2 if_comp which compares to sources and specifies a
comparison function - my guess is this is what the unused
TGSI_OPCODE_IFC was meant for,
> - Original Message -
> > - Original Message -
> > > Ah.. This indeed rings a bell. I don't recall the details but I'm pretty
> > > sure
> > > I was against dual semantics. And the fact that this problem is again
> > > showing its ugly head is the proof of it.
> > >
> > > We reall
- Original Message -
> - Original Message -
> > Ah.. This indeed rings a bell. I don't recall the details but I'm pretty
> > sure
> > I was against dual semantics. And the fact that this problem is again
> > showing its ugly head is the proof of it.
> >
> > We really should have
- Original Message -
> Ah.. This indeed rings a bell. I don't recall the details but I'm pretty sure
> I was against dual semantics. And the fact that this problem is again
> showing its ugly head is the proof of it.
>
> We really should have two IF opcodes. And the state tracker should ch
SM3 hardware does have NaNs. Anyway, I'd like to have this SM3-specific
behavior of TGSI_OPCODE_IF properly documented. We already generate
different TGSI code for SM3 and SM4+ and there'll be much more differences
in how things are done in the future (e.g. temporaries could be used in
place of add
Ah.. This indeed rings a bell. I don't recall the details but I'm pretty sure I
was against dual semantics. And the fact that this problem is again showing its
ugly head is the proof of it.
We really should have two IF opcodes. And the state tracker should choose which
one it wants.
Jose
> What about drivers without integer support? The IF instruction should have 2
> definitions: one for the drivers which support PIPE_SHADER_CAP_INTEGERS, and
> the other one for those which don't. Obviously, there is no way to change
> the behavior of the IF opcode if you only have floats.
I think
Everything emitting those opcodes always assumed this is some sort of
boolean until now, so treating them as floats always was sketchy. Note
that the differences to treating them as uints or floats for comparisons
to zero isn't large, it's the same for everything except -0.0 and NaNs,
and I suspect
What about drivers without integer support? The IF instruction should have
2 definitions: one for the drivers which support PIPE_SHADER_CAP_INTEGERS,
and the other one for those which don't. Obviously, there is no way to
change the behavior of the IF opcode if you only have floats.
Marek
On Thu,
Am 11.04.2013 19:09, schrieb Zack Rusin:
> - Original Message -
>> Am 11.04.2013 05:20, schrieb Zack Rusin:
>>> As implemented in tgsi_exec they both test src operands on the bit
>>> level and don't do floating point comperisons as some thought.
>>> This documents them as such to avoid futu
- Original Message -
> Am 11.04.2013 05:20, schrieb Zack Rusin:
> > As implemented in tgsi_exec they both test src operands on the bit
> > level and don't do floating point comperisons as some thought.
> > This documents them as such to avoid future confusion and fixes
> > their implementat
Am 11.04.2013 05:20, schrieb Zack Rusin:
> As implemented in tgsi_exec they both test src operands on the bit
> level and don't do floating point comperisons as some thought.
> This documents them as such to avoid future confusion and fixes
> their implementation in llvmpipe.
>
> Could gallium dri
Am 11.04.2013 05:20, schrieb Zack Rusin:
> As implemented in tgsi_exec they both test src operands on the bit
> level and don't do floating point comperisons as some thought.
> This documents them as such to avoid future confusion and fixes
> their implementation in llvmpipe.
>
> Could gallium dri
As implemented in tgsi_exec they both test src operands on the bit
level and don't do floating point comperisons as some thought.
This documents them as such to avoid future confusion and fixes
their implementation in llvmpipe.
Could gallium driver developers make sure that they're handling
those
16 matches
Mail list logo
