[Mesa-dev] [Bug 107670] Massive slowdown under specific memcpy implementations (32bit, no-SIMD, backward copy).

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Fri Aug 24 12:48:52 UTC 2018


https://bugs.freedesktop.org/show_bug.cgi?id=107670

--- Comment #5 from iive at yahoo.com ---
(In reply to Roland Scheidegger from comment #3)
> Isn't this mapped as WC?
> In this case I'd expect the direction to make little difference, since write
> combine of any decent cpu should be able to combine the writes regardless
> the order?
> Although if it's UC I suppose someone needs to ensure that the maximum
> possible size is picked...

The theory that this is a caching issue has a merit since the distribution
version and my build seem to use the exact same memcpy(), one that goes
backwards, yet the distribution one is not triggering the massive slowdown.
The memmove() uses `rep movsb` and direction flag.

The question is, what controls the cache? How userland Mesa3D controls the PAT
cache flags? Because I am just changing the libraries, without rebooting
machine or restarting Xorg, I don't even stop the steam client. This means that
MTRR registers are not changed and the exact same kernel module and
configuration is used.

I do use modified build script, that disables support for hardware I don't
have, like intel and nvidia. Some of my options might cause the cache problem,
but I need to know what I am looking for.
BTW, the system libdrm is latest version (2.4.92).

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20180824/120077da/attachment.html>


More information about the mesa-dev mailing list