[Mesa-dev] Mesa (shader-work): glsl: introduce ir_binop_all_equal and ir_binop_any_equal, allow vector cmps

[Ian Romanick]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Luca Barbieri wrote:
>> We intend to change the front-end for ARB fp/vp to generate GLSL IR directly.
> Nice.
> It's probably a good idea to extend GLSL IR to represent things like
> LOG and LIT directly and have optional lowering passes for them, so
> that DX9 hardware with native instructions for them can still easily
> generate them without complex matching.

I know several generations of hardware have a real LIT instruction, but
did anyone ever do a real LOG instruction?  In any case, it should be
easy enough to generate that instruction from:

	(expression float log2 (expression float abs (...))

The other difference of LOG vs LG2 is the precision.  This is a case
where ES-style precision qualifiers would help.  Hmm...

>> Then it would be compiled via whatever backend path your driver prefers.
>> Since we also intend to write direct GLSL IR->915 and GLSL IR->965 backends,
>> this would mean that Intel drivers won't use Mesa IR at all.  Ideally, Mesa IR
>> should go away eventually
> 
> There are non-Intel DRI drivers using Mesa IR though: r200, r300 and r600.
> While r300 and r600 seem likely to be eventually dropped in favor of
> the gallium drivers, r200 will likely stay.
> So it looks like that either r200 needs to be converted to use TGSI
> instead of Mesa IR, or vertex program support dropped on r200.

Going directly from GLSL IR to r200 assembly shouldn't be too difficult.
 I think I still have a Radeon 8500 around to do it on.  Once we've done
i965 and i915 (fragment shaders), we should have a solid set of "best
practices" for doing this.  Converting anything else should be easy
after that.

> Also, you will need to rewrite the fixed function program generator to
> generate GLSL IR.
> 
> That said, it seems a very good idea, especially because Mesa IR is
> mostly equivalent to TGSI, and would need a truly major update anyway
> to be able to represent modern assembly languages like NV_gpu_shader5
> and AMD IL.
> 
>> - if someone writes a GLSL IR->TGSI converter, none
>> of the Gallium drivers would need it...
> 
> Gallium could probably add GLSL IR as a shader input format, and
> eventually drop TGSI in favor of it, since most drivers don't really
> like it.
> However a GLSL IR->TGSI pass (which is relatively easy to write by
> just refactoring ir_to_mesa.cpp) will still be needed for a while,
> since a lot of code depends on TGSI.

Right.  This is the sort of incremental approach that we had in mind.
Rewriting things piece by piece, learning as you go, is just good
software engineering.

> BTW, it would be nice to support GL_EXT_separate_shader_objects soon,
> since hardware drivers and Gallium will tend to work in that mode
> anyway.

We probably won't do the EXT version.  It has some warts that make it
ugly to both app developers and driver developers.  Since the ARB
version is part of OpenGL 4.1, it will get implemented eventually.

> Later (or soon in a driver-initiated fashion), a further transition to
> LLVM could be advisable, but this is easy and GLSL IR is still going
> to be great as a frontend IR, because as you can see in the glsl2-llvm
> branch, converting it to LLVM IR is easy and can work quite well.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyIAwIACgkQX1gOwKyEAw+CUgCfcBQccgI6zwW/vOnwr9BVLf7F
T7YAn0fUOMYza3MumSafjEBaCjeCtSeW
=DkzB
-----END PGP SIGNATURE-----