On Mon, Jul 13, 2015 at 04:00:08PM +0100, Siluvery, Arun wrote: > On 11/07/2015 20:09, Chris Wilson wrote: > >On Sat, Jul 11, 2015 at 08:05:05PM +0100, Chris Wilson wrote: > >>On Fri, Jul 10, 2015 at 06:35:18PM +0100, Arun Siluvery wrote: > >>>These patches enabled Pooled EU support for BXT, they are implemented > >>>by Armin Reese. I am sending these patches in its current form for comments. > >>> > >>>These patches modify Golden batch to have a set of modification values > >>>where we can change the commands based on Gen. The commands to enable > >>>Pooled EU are inserted after MI_BATCH_BUFFER_END. If the given Gen > >>>supports this feature, modification values are used to replace > >>>MI_BATCH_BUFFER_END so we send commands to enable Pooled EU. These > >>>commands need to be part of this batch because they are to be > >>>initialized only once. Userspace will have option to query the > >>>availability of this feature, those changes are not included in > >>>this series. > >> > >>Would it not just be simpler to execute 2 batches? First holding the > >>basic and common state for the gen, the second using subgen. That we > >>have a chunk of binary data is nasty, but at least we can point to the > >>generator and be able to decipher it and recreate it as required. Doing > >>binary patching on top, on that path lies madness. > > I like this idea of sending 2 batches if that is acceptable. In this > case we don't have to touch the golden batch and hence the generator > tool and also not worry about using the correct binary blob as > header. > > the setup in this case would be, > > 1. send golden batch > 2. prepare and send batch to configure pooled EU as per subslice and > EU count > > Why we have a separate tool in the first place, is it not possible > to carry all of them in code or are there any restrictions in doing > so? Basically we really didn't want to have to carry all the 3dstate defintions and generators in the kernel. We thought that carrying a small binary blob (autogenerated from a clear source) would be easier to maintain and keep the complexity (and code size) out of the kernel. We may have got the balance wrong, it just takes a bit of trial and error over the years to decide if the original decision was the correct one. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
