On Wed, Jul 01, 2015 at 08:14:30AM -0700, Jesse Barnes wrote: > On 07/01/2015 06:53 AM, Peter Antoine wrote: > > On Wed, 1 Jul 2015, Francisco Jerez wrote: > > > >> Peter Antoine <peter.antoine@xxxxxxxxx> writes: > >> > >>> On Tue, 30 Jun 2015, Francisco Jerez wrote: > >>> > >>>> Francisco Jerez <currojerez@xxxxxxxxxx> writes: > >>>> > >>>>> Peter Antoine <peter.antoine@xxxxxxxxx> writes: > >>>>> > >>>>>> On Mon, 29 Jun 2015, Peter Antoine wrote: > >>>>>> > >>>>>>> On Thu, 25 Jun 2015, Francisco Jerez wrote: > >>>>>>> > >>>>>>>> Peter Antoine <peter.antoine@xxxxxxxxx> writes: > >>>>>>>> Mesa will want an additional entry with TC=LLC/eLLC, LeCC=PTE, > >>>>>>>> L3CC=WB, > >>>>>>>> everything else unset, I'll reply with a userspace patch making > >>>>>>>> use of > >>>>>>>> your change if you add such an entry. > >>>>>> Ok. I think what you want is, same as entry two, but use the > >>>>>> underlying > >>>>>> pagetable settings and not specify the EDRAM settings. Please > >>>>>> confirm in > >>>>>> the new patchset. > >>>>> > >>>>> Yeah, that sounds good. > >>>>> > >>>>>>>> > >>>>>>>> Another thing worth mentioning is that entries 0, 2 and 5 seem > >>>>>>>> to do the > >>>>>>>> same thing suspiciously, the only difference is the LRUM field > >>>>>>>> which > >>>>>>>> AFAIK doesn't have any effect for LeCC=UC. Is my understanding > >>>>>>>> correct? > >>>>>>>> > >>>>>>> These tables are generated via requests and then boiled down to > >>>>>>> the above. > >>>>>>> So some of the entries are by request. Swings and roundabouts, > >>>>>>> can remove > >>>>>>> the ones that look redundant but then the tuning that has been > >>>>>>> done wont > >>>>>>> match. I'll add the new entry at the end of the table. > >>>> > >>>> Are you planning to propagate the entry you just added back to the > >>>> original table this was generated from? What about new entries we may > >>>> need to add in the future? What should be the process to make sure > >>>> that > >>>> our table and the master table don't diverge and end up with > >>>> conflicting > >>>> entries we cannot remove because of ABI compatibility? I guess there > >>>> should be a comment on the top warning that the table is part of the > >>>> kernel ABI and supposed to be kept in sync with your table, so other > >>>> people don't change it unknowingly? > >>>> > >>>> Thanks. > >>> I am talking to the team that handles this and see if they will add this > >>> (so future gens this is baked in) but it is unlikely that the other > >>> tables > >>> will stay in step as getting in changes will cause too much grief > >>> getting > >>> them upstreamed and as the table is auto-generated we will not be > >>> able to > >>> guarantee the ordering. It will have to be manual job for anyone doing > >>> this. It is required for other platforms for the tables to match the > >>> userspace for performance reasons, but on Linux it will be by request if > >>> there is a problem. We will see what happens. > >>> > >> I think it only makes sense for Linux to maintain compatibility with > >> Android's tables if we agree on some straightforward process for us to > >> allocate new entries without causing conflicts (otherwise people are > >> likely to ignore the issue completely and let the tables diverge, as you > >> mentioned yourself), and have some guarantee that any entries ever > >> contributed by your team to the Linux kernel (and therefore part of our > >> stable ABI) will never be changed or reordered in the future. > >> > > I think internally (and informally) that we cannot keep sync between > > Android > > and Linux. We need to keep compatibility with userspace and there is no > > guarantee of ordering as these tables are generated at runtime. The tables > > that are in Linux are a snapshot. These changes are supposed to > > stabilise at > > PV so they don't change in the future, but if a bug or good performance > > enhancement occurs I can't imagine that they wont make the changes. > > Wow this discussion just keeps going. Who'd have thought such a simple > table would cause so much trouble? :) > > What you mention above is a key point: "these tables are generated at > runtime. The tables that are in Linux are a snapshot. These changes are > supposed to stabilise at PV so they don't change in the future, but if a > bug or good performance enhancement occurs I can't imagine that they > wont make the changes." > > That really argues for a runtime API that allows the userland drivers to > load in MOCS values. I'm not sure if it's practical to make the table > effectively part of the context (lazily applying new values if we detect > a change vs the defaults), but that would at least let the different > user level drivers do whatever they think is ideal... runtime api needs an open-source user. And it sounds like mesa will be happy for a long time with just 3 fixed entries. I guess this mocs upstreaming went nowhere unfortunately :( Imo better to concentrate efforts in areas where we can get somewhere (guc, preempt, tdr, whatever). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
