On 02/06/15 19:36, Siluvery, Arun wrote: > On 01/06/2015 11:22, Daniel, Thomas wrote: >>> >>> Indeed, allocating an extra scratch page in the context would simplify >>> vma/mm management. A trick might be to allocate the scratch page at the >>> start, then offset the lrc regs etc - that would then be consistent >>> amongst gen and be easy enough to extend if we need more per-context >>> scratch space in future. >>> -Chris >> >> Yes, I think we already have another use for more per-context space at >> the start. The GuC is planning to do this. Arun, you probably should >> work with Alex Dai and Dave Gordon to avoid conflicts here. >> >> Thomas. >> > > Thanks for the heads-up Thomas. > I have discussed with Dave and agreed to share this page; > GuC probably doesn't need whole page so first half is reserved for it's > use and second half is used for WA. > > I have modified my patches to use context page for applying these WA and > don't see any issues. > > During the discussions Dave proposed another approach. Even though these > WA are called per context they are only initialized once and not changed > afterwards, same set of WA are applied for each context so instead of > adding them in each context, does it make sense to create a separate > page and share across all contexts? but of course GuC will anyway add a > new page to context so I might as well share that page. > > Chris/Dave, do you see any problems with sharing page with GuC or you > prefer to allocate a separate page for these WA and share across all > contexts? Please give your comments. > > regards > Arun I think we have to consider which is more future-proof i.e. which is least likely: (1) the area shared with the GuC grows (definitely still in flux), or (2) workarounds need to be context-specific (possible, but unlikely) So I'd prefer a single area set up just once to contain the pre- and post-context restore workaround batches. If necessary, the one area could contain multiple batches at different offsets, so we could point different contexts at different (shared) batches as required. I think they're unlikely to actually need per-context customisation[*], but there might be a need for different workarounds according to workload type or privilege level or some other criterion ... ? .Dave. [*] unless they need per-context memory addresses coded into them? _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
