Re: [PATCH v3 1/3] drm/xe: Split H2G and G2H into separate buffer objects

["Thomas Hellström" <thomas.hellstrom@linux.intel.com>]

On Tue, 2026-02-24 at 08:12 -0800, Matthew Brost wrote:
> On Tue, Feb 24, 2026 at 04:58:35PM +0100, Thomas Hellström wrote:
> > On Tue, 2026-02-17 at 20:33 -0800, Matthew Brost wrote:
> > > H2G and G2H buffers have different access patterns (H2G is CPU-
> > > write,
> > > GuC-read, while G2H is GPU-write, CPU-read). On dGPU, these
> > > patterns
> > > benefit from different memory placements: H2G in VRAM and G2H in
> > > system
> > > memory. Split the CT buffer into two separate buffers—one for H2G
> > > and
> > > one for G2H—and select the optimal placement for each.
> > > 
> > > This provides a significant performance improvement on the G2H
> > > read
> > > path, reducing a single read from ~20 µs to under 1 µs on BMG.
> > > 
> > > Signed-off-by: Matthew Brost <matthew.brost@intel.com>
> > 
> > Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> > 
> > Perhaps one could experiment with reading the data from the g2h bo
> > using MOVNTDQA, like the write-combining memcopy. That would avoid
> > caching the data and the GuC having to invalidate the cache line
> > while
> > snooping on the next write.
> 
> We can try that, but G2H messages are variable-sized, so I believe it
> will get a little tricky. Once these are system-memory reads, I
> recall
> G2H handling being something like 15 per µs of page faults (maybe
> that
> isn’t correct — I’ll double-check), and that included my not-yet-
> posted
> caching implementation, which also takes a spinlock, examines the
> page-fault cache, and chains the fault onto a list. So I don’t think
> this will end up in the critical path.

Actually DOCs say MOVNTDQA only has an effect on write-combining
mappings, so probably a dead end experimenting with that.
There's also PREFETCHNTA though, which may or may not have an effect.

/Thomas