[Mesa-dev] mediump support: future work

[Rob Clark]

On Mon, May 4, 2020 at 11:44 AM Marek Olšák <maraeo at gmail.com> 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 out No No
> TCS, TES, GS out / in No No
> Sampler coordinates (only coord, derivs, lod, bias; not offset and compare) No ---
> Image coordinates --- No
> Return value from samplers (incl. sampler buffers) Yes
> No
> Return value from image loads (incl. image buffers) No No
> Data source for image stores (incl. image buffers) No No
> If 16-bit sampler/image instructions are surrounded by conversions, promote them to 32 bits No No
>
> Please let me know if you don't see the table correctly.
>
> I'd like to know if I can enable some of them using the existing FP16 CAP. The only drivers supporting FP16 are currently Freedreno and Panfrost.
>

I think in general it should be ok.

I think for ir3 we want 32b inputs/outputs for geom stages
(vs/hs/ds/gs).  For frag outs we use nir_lower_mediump_outputs.. maybe
this is a good approach to continue, to use a simple nir lowering pass
for cases where a shader stage can directly take 16b input/output.
For frag inputs we fold the narrowing conversion in to the varying
fetch instruction in backend.

int16 would be pretty useful, for loop counters especially.. these can
have a long live-range and currently wastefully occupy a full 32b reg.

Uniforms we haven't cared too much about, since we can (usually) read
a 32b uniform as a 16b and fold that directly into alu instructions..
we handle that in the backend.

Pushing mediump support further would be great, and we can definitely
help if it ends up needing changes in freedreno backend.  The deqp
coverage in CI should give us pretty good confidence about whether or
not we are breaking things in the ir3 backend.

BR,
-R