On Fri, Apr 29, 2016 at 11:42 AM, Ian Romanick wrote:
> On 02/09/2016 12:02 AM, Ian Romanick wrote:
>> I submitted a public spec bug for this issue:
>>
>> https://www.khronos.org/bugzilla/show_bug.cgi?id=1460
>>
>> I'm investigating whether a similar bug is needed for the SPIR-V
>> specification.
On 02/09/2016 12:02 AM, Ian Romanick wrote:
> I submitted a public spec bug for this issue:
>
> https://www.khronos.org/bugzilla/show_bug.cgi?id=1460
>
> I'm investigating whether a similar bug is needed for the SPIR-V
> specification.
>
> I think an argument can be made for either the flush-to-
> On Feb 9, 2016, at 11:23, Tom Stellard wrote:
>
> We should still add +fp64-denormals even if the backend doesn't do
> anything with it now.
This is the default, so it doesn’t really matter anyway.
-Matt___
mesa-dev mailing list
mesa-dev@lists.free
On Mon, Feb 08, 2016 at 09:38:32PM +0100, Marek Olšák wrote:
> On Mon, Feb 8, 2016 at 5:08 PM, Tom Stellard wrote:
> > On Sat, Feb 06, 2016 at 01:15:42PM +0100, Marek Olšák wrote:
> >> From: Marek Olšák
> >>
> >> This fixes FP16 conversion instructions for VI, which has 16-bit floats,
> >> but no
> On Feb 8, 2016, at 12:38, Marek Olšák wrote:
>
>>
>> We should tell the compiler we are enabling fp-64 denorms by adding
>> +fp64-denormals to the feature string. It would also be better to
>> read the float_mode value from the config registers emitted by the
>> compiler.
>
> Yes, I agree,
FWIW, D3D requires round-toward-zero for conversion to FP16 colorbuffers.
radeonsi does the same: round-toward-zero for colorbuffers and
round-to-nearest-even for the GLSL packing functions. This looks like
an inconsistency that may cause issues though.
Marek
On Tue, Feb 9, 2016 at 1:12 AM, Rola
Am 09.02.2016 um 00:53 schrieb Ian Romanick:
> On 02/08/2016 03:37 PM, Roland Scheidegger wrote:
>> Am 09.02.2016 um 00:02 schrieb Ian Romanick:
>>> On 02/08/2016 12:38 PM, Marek Olšák wrote:
On Mon, Feb 8, 2016 at 5:08 PM, Tom Stellard wrote:
> On Sat, Feb 06, 2016 at 01:15:42PM +0100, M
On 02/08/2016 03:37 PM, Roland Scheidegger wrote:
> Am 09.02.2016 um 00:02 schrieb Ian Romanick:
>> On 02/08/2016 12:38 PM, Marek Olšák wrote:
>>> On Mon, Feb 8, 2016 at 5:08 PM, Tom Stellard wrote:
On Sat, Feb 06, 2016 at 01:15:42PM +0100, Marek Olšák wrote:
> From: Marek Olšák
>
>>
Am 09.02.2016 um 00:02 schrieb Ian Romanick:
> On 02/08/2016 12:38 PM, Marek Olšák wrote:
>> On Mon, Feb 8, 2016 at 5:08 PM, Tom Stellard wrote:
>>> On Sat, Feb 06, 2016 at 01:15:42PM +0100, Marek Olšák wrote:
From: Marek Olšák
This fixes FP16 conversion instructions for VI, which
On 02/08/2016 12:38 PM, Marek Olšák wrote:
> On Mon, Feb 8, 2016 at 5:08 PM, Tom Stellard wrote:
>> On Sat, Feb 06, 2016 at 01:15:42PM +0100, Marek Olšák wrote:
>>> From: Marek Olšák
>>>
>>> This fixes FP16 conversion instructions for VI, which has 16-bit floats,
>>> but not SI & CI, which can't
On Mon, Feb 8, 2016 at 5:16 PM, Matt Arsenault wrote:
>
> On Feb 8, 2016, at 08:08, Tom Stellard wrote:
>
> Do SI/CI support fp64 denorms? If so, won't this hurt performance?
>
> We should tell the compiler we are enabling fp-64 denorms by adding
> +fp64-denormals to the feature string. It woul
On Mon, Feb 8, 2016 at 5:08 PM, Tom Stellard wrote:
> On Sat, Feb 06, 2016 at 01:15:42PM +0100, Marek Olšák wrote:
>> From: Marek Olšák
>>
>> This fixes FP16 conversion instructions for VI, which has 16-bit floats,
>> but not SI & CI, which can't disable denorms for those instructions.
>
> Do you
> On Feb 8, 2016, at 08:08, Tom Stellard wrote:
>
> Do SI/CI support fp64 denorms? If so, won't this hurt performance?
This is the only mode that should ever be used. I’m not sure why these are
options. There technically are separate flush on input or flush on output
options, but I’m not sure
> On Feb 8, 2016, at 08:08, Tom Stellard wrote:
>
> Do SI/CI support fp64 denorms? If so, won't this hurt performance?
>
> We should tell the compiler we are enabling fp-64 denorms by adding
> +fp64-denormals to the feature string. It would also be better to
> read the float_mode value from t
On Sat, Feb 06, 2016 at 01:15:42PM +0100, Marek Olšák wrote:
> From: Marek Olšák
>
> This fixes FP16 conversion instructions for VI, which has 16-bit floats,
> but not SI & CI, which can't disable denorms for those instructions.
Do you know why this fixes FP16 conversions? What does the OpenGL
On 06.02.2016 07:15, Marek Olšák wrote:
From: Marek Olšák
This fixes FP16 conversion instructions for VI, which has 16-bit floats,
but not SI & CI, which can't disable denorms for those instructions.
Reviewed-by: Nicolai Hähnle
---
src/gallium/drivers/radeonsi/si_shader.c| 14 +++
On Mon, Feb 8, 2016 at 1:11 PM, Roland Scheidegger wrote:
> This looks good to me, albeit I know nothing about the hw.
> So VI could do (just with some restrictios) even full-speed fp32 denorms
> whereas SI/CI can't? Interesting, I suppose that would be intended for
Yes, VI has full-speed fp32 de
This looks good to me, albeit I know nothing about the hw.
So VI could do (just with some restrictios) even full-speed fp32 denorms
whereas SI/CI can't? Interesting, I suppose that would be intended for
compute. intel x86 can't even do that (actually, I think skylake can),
though certainly other cp
From: Marek Olšák
This fixes FP16 conversion instructions for VI, which has 16-bit floats,
but not SI & CI, which can't disable denorms for those instructions.
---
src/gallium/drivers/radeonsi/si_shader.c| 14 ++
src/gallium/drivers/radeonsi/si_state_shaders.c | 18 ++
19 matches
Mail list logo
