On Mon, Jan 21, 2019 at 2:09 AM Iago Toral wrote:
> On Fri, 2019-01-18 at 06:46 -0600, Jason Ekstrand wrote:
>
> On January 18, 2019 01:48:25 Iago Toral wrote:
>
> On Thu, 2019-01-17 at 13:42 -0600, Jason Ekstrand wrote:
>
> On Tue, Jan 15, 2019 at 7:54 AM Iago Toral Quiroga
> wrote
>
>
>
On Fri, 2019-01-18 at 06:46 -0600, Jason Ekstrand wrote:
> On January 18, 2019 01:48:25 Iago Toral wrote:
>
> > On Thu, 2019-01-17 at 13:42 -0600, Jason Ekstrand wrote:
> > > On Tue, Jan 15, 2019 at 7:54 AM Iago Toral Quiroga <
> > > ito...@igalia.com> wrote
(...)
> > > > + nir_ssa_def *tmp =
On January 18, 2019 01:48:25 Iago Toral wrote:
On Thu, 2019-01-17 at 13:42 -0600, Jason Ekstrand wrote:
On Tue, Jan 15, 2019 at 7:54 AM Iago Toral Quiroga wrote:
Some conversions are not directly supported in hardware and need to be
split in two conversion instructions going through an
On Thu, 2019-01-17 at 13:42 -0600, Jason Ekstrand wrote:
> On Tue, Jan 15, 2019 at 7:54 AM Iago Toral Quiroga > wrote:
> > Some conversions are not directly supported in hardware and need to
> > be
> >
> > split in two conversion instructions going through an intermediary
> > type.
> >
> >
On Tue, Jan 15, 2019 at 7:54 AM Iago Toral Quiroga
wrote:
> Some conversions are not directly supported in hardware and need to be
> split in two conversion instructions going through an intermediary type.
> Doing this at the NIR level simplifies a bit the complexity in the backend.
>
> v2:
> -
Some conversions are not directly supported in hardware and need to be
split in two conversion instructions going through an intermediary type.
Doing this at the NIR level simplifies a bit the complexity in the backend.
v2:
- Consider fp16 rounding conversion opcodes
- Properly handle swizzles
