On Thu, Jan 26, 2017 at 09:39:51AM -0800, Chad Versace wrote: > On Thu 26 Jan 2017, Chris Wilson wrote: > > Since the workaround bo is used strictly as a write-only buffer, we need > > only allocate one per screen and use the same one from all contexts. > > > > (The caveat here is during extension initialisation, where we write into > > and read back register values from the buffer, but that is performed only > > once for the first context - and baring synchronisation issues should not > > be a problem. Safer would be to move that also to the screen.) > > > > v2: Give the workaround bo its own init function and don't piggy back > > intel_bufmgr_init() since it is not that related. > > > > v3: Drop the reference count of the workaround bo for the context since > > the context itself is owned by the screen (and so we can rely on the bo > > existing for the lifetime of the context). > > I like this idea, but I have questions and comments about the details. > More questions than comments, really. > > Today, with only Mesa changes, could we effectively do the same as > drm_intel_gem_bo_disable_implicit_sync(screen->workaround_bo); > by hacking Mesa to set no read/write domain when emitting relocs for the > workaround_bo? (I admit I don't fully understand the kernel's domain > tracking). If that does work, then it just would require a small hack to > brw_emit_pipe_control_write(). However... There is a hack that requires the write hazard for gen6 pipecontrols unless you use the noreloc patches (hw limitation causing pipecontrols to always use ggtt offsets not the ppgtt you have normally). -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
