On Thu, Jan 17, 2013 at 10:56:28AM +0000, Beauchesne, Gwenole wrote: > > On Fri, Jan 11, 2013 at 09:41:05AM +0100, Daniel Vetter wrote: > > I'm not against doing that, it'll shed more light/review/etc on the assembler (I > > assume patches would have to hit this list first). > > > > Xiang, Homer, Gwenole, what do you think of that idea? > > I think distributions would prefer smaller self-contained projects, > that don't need too many dependencies. If we make intel-gen4asm into > i-g-t, we'd need additional configure options to enable/disable > certain components, e.g. testdisplay with cairo/libudev deps. That point seems a bit moot to me, we already need to make some parts of i-g-t optional and the assembler would be one instance of that. I'm also willing to do the work to ensure that's done. > While we are at re-organizing intel-gen4asm, I would also suggest to > think about using Chris' libbrw as the actual backend to the GenX > assembler. There is a need to generate code both at run-time and > build-time, and it would be better to use the same assembler back-end, > so that to simplify validation and enablement of future generations. > IMHO, that'd a more sensible move than deciding on where to host > intel-gen4asm. :) Yes, I agree, and I think having that effort done in i-g-t makes sense as I'd like to chip away at things like a tool to analyse the last batch buffer after a hang for instance. Sharing that code better is definitely what is motivating to look at that. I've started a series to synchronize the brw_*[ch] files with Mesa's but I have to admit I did not look at Chris' libbrw. The changes I have so far are definitely a step towards the right direction though as Chris seems to have started with more recent versions of Mesa's files than the ones we have in the assembler. Hopefully I'll have a first pass done this week. I also had a looks at Chris' libbrw. It does look good but diverges a bit from Mesa now, what I'd love to have is the same thing everywhere, but I guess that's a long shot. -- Damien
