[Mesa-dev] TGSI 16-bit support

[Nicolai Hähnle]

On 23.08.2017 16:36, Ilia Mirkin wrote:
> On Wed, Aug 23, 2017 at 10:30 AM, Nicolai Hähnle <nhaehnle at gmail.com> wrote:
>> On 23.08.2017 15:15, Nicolai Hähnle wrote:
>>>
>>> On 22.08.2017 19:32, Marek Olšák wrote:
>>>>
>>>> On Tue, Aug 22, 2017 at 7:28 PM, Ilia Mirkin <imirkin at alum.mit.edu>
>>>> wrote:
>>>>>
>>>>> How do you propose defining the semantics for e.g. loading a 16-bit
>>>>> value from a constbuf/ssbo? Would those get separate instructions?
>>>>
>>>>
>>>> st/mesa should use UP2H, PK2H and similar opcodes for I16 and U16, and
>>>> drivers can replace them with MOV if HalfPrecision == 1.
>>>
>>>
>>> You mean, if HalfPrecision == 1 for subsequent operations?
>>>
>>> How *do* we implement this for LLVM, anyway? Downcast (fptrunc) from float
>>> to half whenever we're loading operands of a HalfPrecision == 1 instruction,
>>> and then casting (fpext) back up before storing the result?
>>>
>>> LLVM instcombine seems quite capable of seeing through that in simple
>>> code, but I worry about control flow.
>>
>>
>> Thinking about this some more, having the precision a property of the
>> temporaries like Ilia suggested would probably help with emitting LLVM IR
>> that behaves well across control flow, but complicate st_glsl_to_tgsi. Hard
>> to say what the tradeoff is there.
> 
> Why would it complicate glsl_to_tgsi? At the GLSL level, it's not the
> operations that have precision, but variables. And those variables map
> to temp's... we'd have to create a separate pool of high- vs
> low-precision temps, but that's about it.

Well, it may not be so bad in the end. But we definitely have to be more 
careful with things like temporary remapping, peephole, etc.

Also, at least OUT variables could also be affected, right?

Cheers,
Nicolai

> 
>    -ilia
> 


-- 
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.