On Thu, Oct 29, 2015 at 8:07 AM, Ilia Mirkin <imir...@alum.mit.edu> wrote: > On Thu, Oct 29, 2015 at 2:52 AM, Ilia Mirkin <imir...@alum.mit.edu> wrote: >> ARB_gpu_shader5 should be a decent proxy for whether those instructions >> are supported. >> >> Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> >> --- >> >> Not actually ready to be committed, since r600/radeonsi need support >> for these ops as well. Should be easy to implement, but want to get >> the OK before I do so. > > Oh, and to pre-empt the question of "why not the other pack/unpack > primitives", it's because nouveau codegen is able to optimize them > into reasonable forms (it does better with unpack than with pack), esp > after I adjusted the lowering passes to use BFI/BFE. Not ideal, but > the manual f32 <-> f16 stuff was a bit much. I wouldn't be opposed to > the other opcodes getting added too, just didn't seem too important.
Yeah, the integer packing opcodes are a lot easier to recognize in driver backends. Patches 1 & 3 are: Reviewed-by: Marek Olšák <marek.ol...@amd.com> Of course, r600 and radeonsi support needs to be done before pushing this patch. radeonsi has 2 ways of converting float->half: Using these LLVM intrinsics, which are translated to instructions that obey round mode rules: llvm.convert.to.fp16 llvm.convert.from.fp16 Using this SI LLVM intrinsic, which rounds towards zero and is used for converting fragment color outputs: llvm.SI.packf16 I think we should use the former for consistency, even though the GLSL 4.4 spec states that the rounding mode is undefined. Marek _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
