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. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
