On Monday, April 26, 2021 2:38:53 AM PDT Matthew Auld wrote: > +Existing uAPI issues > +==================== > +Some potential issues we still need to resolve. > + > +I915 MMAP > +--------- > +In i915 there are multiple ways to MMAP GEM object, including mapping the same > +object using different mapping types(WC vs WB), i.e multiple active mmaps per > +object. TTM expects one MMAP at most for the lifetime of the object. If it > +turns out that we have to backpedal here, there might be some potential > +userspace fallout. > + > +I915 SET/GET CACHING > +-------------------- > +In i915 we have set/get_caching ioctl. TTM doesn't let us to change this, but > +DG1 doesn't support non-snooped pcie transactions, so we can just always > +allocate as WB for smem-only buffers. If/when our hw gains support for > +non-snooped pcie transactions then we must fix this mode at allocation time as > +a new GEM extension. > + > +This is related to the mmap problem, because in general (meaning, when we're > +not running on intel cpus) the cpu mmap must not, ever, be inconsistent with > +allocation mode. > + > +Possible idea is to let the kernel picks the mmap mode for userspace from the > +following table: > + > +smem-only: WB. Userspace does not need to call clflush. > + > +smem+lmem: We allocate uncached memory, and give userspace a WC mapping > +for when the buffer is in smem, and WC when it's in lmem. GPU does snooped > +access, which is a bit inefficient. I think you meant to write something different here. What I read was: - If it's in SMEM, give them WC - If it's in LMEM, give them WC Presumably one of those should have been something else, since otherwise you would have written "always WC" :) > + > +lmem only: always WC > + > +This means on discrete you only get a single mmap mode, all others must be > +rejected. That's probably going to be a new default mode or something like > +that. > + > +Links > +===== > +[1] https://patchwork.freedesktop.org/series/86798/ > + > +[2] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5599#note_553791
Attachment:
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
