On Mon, Feb 24, 2020 at 8:21 PM Ilia Mirkin wrote:
>
> On Mon, Feb 24, 2020 at 1:10 PM Ian Romanick wrote:
> >
> > On 2/23/20 5:57 PM, Ilia Mirkin wrote:
> > > ---
> > >
> > > We talked about something like this a while back, but the end result
> > > was inconclusive. I added a TGSI MUL_ZERO_WINS
e the commit message to account for
that (maybe make it more general?) but in any case, and FWIW:
Tested-by: Matteo Bruni
I also have a nitpick which you can entirely ignore, below.
> + if (var->get_interface_type() != existing->get_interface_type())
2017-01-24 19:15 GMT+01:00 Ilia Mirkin :
> On Tue, Jan 24, 2017 at 1:11 PM, Matteo Bruni
> wrote:
>> 2017-01-24 3:18 GMT+01:00 Ilia Mirkin :
>>> This matches the behavior of most other drivers, including nouveau.
>>
>> Doesn't this break all the appli
2017-01-24 3:18 GMT+01:00 Ilia Mirkin :
> This matches the behavior of most other drivers, including nouveau.
Doesn't this break all the applications depending on d3d9 NaN behavior
(including, but not limited to, d3d9 games in Wine) on r600g?
If I got this right, flipping around the two patches i
2017-01-13 3:37 GMT+01:00 Ilia Mirkin :
> On Thu, Jan 12, 2017 at 9:13 PM, Jason Ekstrand wrote:
>> Unless, of course, it's controlled by the same hardware bit... Clearly, we
>> can can give you abs on rsq without denorm flushing (easy shader hacks) but
>> not the other way around.
>
> OK, so some
2017-01-12 23:41 GMT+01:00 Axel Davy :
>> Do you refer to the d3d9 MAD or the hardware instruction? If the
>> former, just generating MUL and ADD separately should do the trick. In
>> the latter case, I guess that means the "NaN switch" should also
>> affect code generation (although I think that s
2017-01-12 22:54 GMT+01:00 Axel Davy :
>
> Preventing NaN from being generated is not sufficient to fix the 0*inf = 0
> issue.
>
> For example radeonsi does convert all NaN to zeros via a hardware setting.
>
> But 0*inf = 0 behaviour should be also in mad, and with the NaN to zero
> conversion, you
surprising to me. On top of my mind, there's the behavior when
sampling from a texture unit with no texture bound but if you're
interested you can just look at the d3d9 tests in Wine to find a bunch
more...
> In any case, being able to select NaN behavior looks potentially quite
nt behavior
from one shader to the next.
Is anyone interested in / favorable to something like this? It would
solve the issue with defining NaN behavior in GLSL while making things
a bit more compatible with "other API a lot of games are ported from
which happens to be supported by
ists.freedesktop.org
I also wrote a patch for this bug, essentially identical except yours
has that couple of additional ES changes. Your patch looks good and it
works for me so, FWIW, have my
Reviewed-by: Matteo Bruni
Tested-by: Matteo Bruni
__
2014-12-01 14:04 GMT+01:00 Eduardo Lima Mitev :
> The OpenGL ES Shading Language specification describes the
> values that may be output by a fragment shader. These are
> gl_FragColor and gl_FragData[0]. Multiple render targets
> are not supported in GLES.
>
> Fixes dEQP test:
> * dEQP-GLES3.func
11 matches
Mail list logo
