On Thu, 30 Apr 2020 at 03:24, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote: > > We need to keep the default context state around to instantiate new > contexts (aka golden rendercontext), and we also keep it pinned while > the engine is active so that we can quickly reset a hanging context. > However, the default contexts are large enough to merit keeping in > swappable memory as opposed to kernel memory, so we store them inside > shmemfs. Currently, we use the normal GEM objects to create the default > context image, but we can throw away all but the shmemfs file. > > This greatly simplifies the tricky power management code which wants to > run underneath the normal GT locking, and we definitely do not want to > use any high level objects that may appear to recurse back into the GT. > Though perhaps the primary advantage of the complex GEM object is that > we aggressively cache the mapping, but here we are recreating the > vm_area everytime time we unpark. At the worst, we add a lightweight > cache, but first find a microbenchmark that is impacted. > > Having started to create some utility functions to make working with > shmemfs objects easier, we can start putting them to wider use, where > GEM objects are overkill, such as storing persistent error state. > The current DG1 patchset is missing something around here. The driver creates in intel_lrc.c the contexts in LMEM, but then it gets to this patch and gets an EBUSY trying to pin_map it. Dave. _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
