Am 12.01.2017 um 17:20 schrieb Ilia Mirkin:
> On Thu, Jan 12, 2017 at 11:13 AM, Roland Scheidegger
> wrote:
>> Am 12.01.2017 um 02:12 schrieb Marek Olšák:
>>> On Thu, Jan 12, 2017 at 12:33 AM, Ilia Mirkin wrote:
On Wed, Jan 11, 2017 at 4:00 PM, Roland Scheidegger
wrote:
> Am 11.0
Am 12.01.2017 um 17:13 schrieb Roland Scheidegger:
> Am 12.01.2017 um 02:12 schrieb Marek Olšák:
>> On Thu, Jan 12, 2017 at 12:33 AM, Ilia Mirkin wrote:
>>> On Wed, Jan 11, 2017 at 4:00 PM, Roland Scheidegger
>>> wrote:
Am 11.01.2017 um 21:08 schrieb Samuel Pitoiset:
>
>
> On 01
On Thu, Jan 12, 2017 at 11:13 AM, Roland Scheidegger wrote:
> Am 12.01.2017 um 02:12 schrieb Marek Olšák:
>> On Thu, Jan 12, 2017 at 12:33 AM, Ilia Mirkin wrote:
>>> On Wed, Jan 11, 2017 at 4:00 PM, Roland Scheidegger
>>> wrote:
Am 11.01.2017 um 21:08 schrieb Samuel Pitoiset:
>
>
>
Am 12.01.2017 um 02:12 schrieb Marek Olšák:
> On Thu, Jan 12, 2017 at 12:33 AM, Ilia Mirkin wrote:
>> On Wed, Jan 11, 2017 at 4:00 PM, Roland Scheidegger
>> wrote:
>>> Am 11.01.2017 um 21:08 schrieb Samuel Pitoiset:
On 01/11/2017 07:00 PM, Roland Scheidegger wrote:
> I don't t
On 01/12/2017 12:55 PM, Marek Olšák wrote:
I think v_mad always flushes denorms.
I would just ignore this failure. It's not required to fix every silly
test on the planet. If you opencode v_max, you'll have the same problem,
and then you'd have to fix v_cmp. It's just silly.
Your call.
That
I think v_mad always flushes denorms.
I would just ignore this failure. It's not required to fix every silly test
on the planet. If you opencode v_max, you'll have the same problem, and
then you'd have to fix v_cmp. It's just silly.
Marek
On Jan 12, 2017 11:59 AM, "Nicolai Hähnle" wrote:
> On
On 12.01.2017 09:24, Samuel Pitoiset wrote:
On 01/12/2017 02:12 AM, Marek Olšák wrote:
On Thu, Jan 12, 2017 at 12:33 AM, Ilia Mirkin
wrote:
On Wed, Jan 11, 2017 at 4:00 PM, Roland Scheidegger
wrote:
Am 11.01.2017 um 21:08 schrieb Samuel Pitoiset:
On 01/11/2017 07:00 PM, Roland Scheidegg
On 01/12/2017 02:12 AM, Marek Olšák wrote:
On Thu, Jan 12, 2017 at 12:33 AM, Ilia Mirkin wrote:
On Wed, Jan 11, 2017 at 4:00 PM, Roland Scheidegger wrote:
Am 11.01.2017 um 21:08 schrieb Samuel Pitoiset:
On 01/11/2017 07:00 PM, Roland Scheidegger wrote:
I don't think there's any glsl, es
On Thu, Jan 12, 2017 at 12:33 AM, Ilia Mirkin wrote:
> On Wed, Jan 11, 2017 at 4:00 PM, Roland Scheidegger
> wrote:
>> Am 11.01.2017 um 21:08 schrieb Samuel Pitoiset:
>>>
>>>
>>> On 01/11/2017 07:00 PM, Roland Scheidegger wrote:
I don't think there's any glsl, es or otherwise, specification
On Wed, Jan 11, 2017 at 4:00 PM, Roland Scheidegger wrote:
> Am 11.01.2017 um 21:08 schrieb Samuel Pitoiset:
>>
>>
>> On 01/11/2017 07:00 PM, Roland Scheidegger wrote:
>>> I don't think there's any glsl, es or otherwise, specification which
>>> would require denorms (since obviously lots of hw can
Am 11.01.2017 um 21:08 schrieb Samuel Pitoiset:
>
>
> On 01/11/2017 07:00 PM, Roland Scheidegger wrote:
>> I don't think there's any glsl, es or otherwise, specification which
>> would require denorms (since obviously lots of hw can't do it, d3d10
>> forbids them), with any precision qualifier. H
On Wed, Jan 11, 2017 at 12:08 PM, Samuel Pitoiset wrote:
>
>
> On 01/11/2017 07:00 PM, Roland Scheidegger wrote:
>
>> I don't think there's any glsl, es or otherwise, specification which
>> would require denorms (since obviously lots of hw can't do it, d3d10
>> forbids them), with any precision q
On 01/11/2017 07:00 PM, Roland Scheidegger wrote:
I don't think there's any glsl, es or otherwise, specification which
would require denorms (since obviously lots of hw can't do it, d3d10
forbids them), with any precision qualifier. Hence these look like bugs
of the test suite to me?
(Irrespect
On 01/11/2017 07:49 PM, Marek Olšák wrote:
I've realized there is a small problem with this. MAD never supports
denorms, but MUL+ADD do. That can cause issues, because the compiler
assumes that MAD = MUL+ADD.
We need to use MAD for good performance, which means we should
probably never enable
On 01/11/2017 07:18 PM, Ilia Mirkin wrote:
So, I don't know whether this affects more than compute shaders
without reading the code, but I explicitly had to enable denorm
flushing on nvc0 in order to fix some sad artifacts in Unigine Heaven.
Right now nouveau only does denorm flushes on graphi
On 01/11/2017 07:09 PM, Marek Olšák wrote:
Reviewed-by: Marek Olšák
Would you please run a GPU-bound benchmark of your choice to make sure
it doesn't affect performance?
I tried Furmark and Pixmark Piano on my rx 480. With 3 runs before and
after that change, the number of FPS as well as t
I've realized there is a small problem with this. MAD never supports
denorms, but MUL+ADD do. That can cause issues, because the compiler
assumes that MAD = MUL+ADD.
We need to use MAD for good performance, which means we should
probably never enable FP32 denorms.
Marek
On Wed, Jan 11, 2017 at 6
So, I don't know whether this affects more than compute shaders
without reading the code, but I explicitly had to enable denorm
flushing on nvc0 in order to fix some sad artifacts in Unigine Heaven.
Right now nouveau only does denorm flushes on graphics shaders, but
the reason I did that originall
I don't think there's any glsl, es or otherwise, specification which
would require denorms (since obviously lots of hw can't do it, d3d10
forbids them), with any precision qualifier. Hence these look like bugs
of the test suite to me?
(Irrespective if it's a good idea or not to enable denormals, wh
Reviewed-by: Marek Olšák
Would you please run a GPU-bound benchmark of your choice to make sure
it doesn't affect performance?
Thanks,
Marek
On Wed, Jan 11, 2017 at 6:29 PM, Samuel Pitoiset
wrote:
> Only VI can do 32-bit denormals at full rate while previous
> generations can do it only for 64
Only VI can do 32-bit denormals at full rate while previous
generations can do it only for 64-bit and 16-bit.
This fixes some dEQP tests with the highp type qualifier.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99343
Signed-off-by: Samuel Pitoiset
---
src/gallium/drivers/radeonsi/si
21 matches
Mail list logo
