Shader compilers within drivers questions

PeterAce

Regular
Can there be multible shader compliers per driver?

If not, then how does a IHV run optimal shader code on different generations of their cards?
 
Yes, that's generally how we do it. For something like GLSL or ARB_[f|v]p, you wouldn't want to have multiple complete compilers in. DX9 vs and ps asm are simpler, but in general we try to share as many components as possible.

Not the least reason is to provide more test coverage. All optimising compilers are hellishly chaotic systems and there's no such thing as too much or too widely spread testing.
 
If architectures are similar enough, than the different shading languages and assembly languages boil down a front-end for a common backend optimizer. There is the possibility of two high level languages requiring different intermediate representations or an intermediate representation not being semantically powerful enough to express the underlying HW in a way that is easy to optimize, but in general, compilers can share alot of common code.

Take GCC for example. It actually has frontends to compile C, C++, Objective-C, Fortran 77, ADA, Pascal, Java, CAML, and a bunch of others. On top of that, it has backends to target almost every CPU and virtual machine format ever made. Most of this is shared code.

Of course, GCC by striving to be so portable and general, loses against more vertically integrated compilers, but in general, it does reasonably well on most architectures.

Many compilers are being written today using code-generator-generators (in addition to compiler-compilers like YACC), which do the dirty work of implementing instruction selection and scheduling, using so-called Bottom-Up Rewrite-Systems or Bottom-up-rewrite-grammars. These allow you to target new architectures by altering a small config file. The config file specifies the costs of various combinations of operations, so that the compiler can choose the cheapest sequence.
 
Back
Top