On RADV, we already support fp16 with the LLVM backend (not saying it's
always optimized though) and with ACO it should be mostly working but
not yet enabled because I think we would like fast packed math support
first and I'm not sure if fp16 I/O are implemented.
There is also some missing
On Intel, mesa currently supports fp16 as well as int16 and int8 for
Vulkan. We support them for ALU ops as well as UBOs, SSBOs, and
shared memory.
We have hardware for some texture instructions with fp16 sources or
destinations but it's all over the map in terms of what ops support
what. In
On Mon, May 4, 2020 at 5:09 PM Marek Olšák wrote:
>
> 16-bit varyings only make sense if they are packed, i.e. we need to fit 2
> 16-bit 4D varyings into 1 vec4 slot to save memory for IO. Without that, AMD
> (and most others?) won't benefit from 16-bit IO much.
>
I guess for !flat varyings
16-bit varyings only make sense if they are packed, i.e. we need to fit 2
16-bit 4D varyings into 1 vec4 slot to save memory for IO. Without that,
AMD (and most others?) won't benefit from 16-bit IO much.
16-bit uniforms would help everybody, because there is potential for
uniform packing, saving
On Mon, May 4, 2020 at 11:44 AM Marek Olšák wrote:
>
> Hi,
>
> This is the status of mediump support in Mesa. What I listed is what AMD GPUs
> can do. "Yes" means what Mesa supports.
>
> Feature FP16 support Int16 support
> ALU Yes No
> Uniforms No No
> VS in No No
> VS out / FS in No No
> FS
Hi,
This is the status of mediump support in Mesa. What I listed is what AMD
GPUs can do. "Yes" means what Mesa supports.
*Feature* *FP16 support* *Int16 support*
ALU Yes No
Uniforms No No
VS in No No
VS out / FS in No No
FS out No No
TCS, TES, GS out / in No No
Sampler coordinates (only coord,
