[Mesa-dev] Blorp blit compiler to use FS LIR

[Pohjolainen, Topi]

On Fri, Dec 20, 2013 at 04:38:29PM +0200, Topi Pohjolainen wrote:
> This is a rather long series but I suspect it will be eventually
> squashed into fewer patches. The motivation for the work is to
> prepare for gen8 blorp support.
> 
> Currently the compiler for the blorp blit programs is written to
> emit EU-level instructions directly. This is not a big deal at
> the time being as blorp is supported only from gen6 onwards meaning
> that there are not that many hw-specific choices to be taken. But
> as one moves on to gen8 that will not be the case anymore.
> The plan is to lift the core of the blit compiler one level higher,
> i.e., to emit FS LIR which can be subsequently fed into gen-specific
> generator.
> 
> This series aims to keep the generated EU-stream exactly the same
> as before. In order to increase the confidence that this is really
> the case I wrote a series of unit tests. I identified some 20 odd
> individual code blocks in the compiler that emit instructions for
> some special purpose. Then I started running piglit tests and
> hand-picked some dozen cases that together exercised each of the code
> blocks in question at least once. I dumped the key used to drive the
> compiler along with the original assembly in human readbale format.
> Then I simply placed each such pair as its own unit test case.
> I had to modify the existing assembly dumping infra a bit in order to
> have it in designated files instead of just stdout. Some care had to
> be taken to take the dump in correct phase - after jump instruction
> patching but before instruction stream compression. I suppose it
> could have been done after the compression as well but I thought
> safer to do it just after the generator phase instead.
> 
> I also spent some time understanding how the execution size is
> controlled in the compiler (also referred to as compression control).
> I grouped instructions needing special care into their own
> subroutines which I'm hoping to explain better what is going on when
> one switches from direct control to higher level.
> 
> Similar treatment was required for combining comparisons and for
> conditional assignments (predicate control).
> 
> Message sending itself (texture fetch, render target write) is going
> to be different in gen8 but the message contents look to be more or
> less the same. Hence I chose to keep the message building in place
> and let the generators to handle only the issuing of the send
> command itself.
> 
> Finally about the split in general. There is clearly the possibility
> of doing all the logic replacement in the compiler core itself
> instead of the split. However, that will need to be done more or less
> in one go and I thought that the split makes it clearer at least for
> initial review what sort of things are involved making it easier to
> discuss about the changes.
> 
> I'll run tests on SNB also once I get my hands on one.

I didn't see any regressions there either - ran piglit-all just out of
curiosity.