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

[bugzilla-daemon at freedesktop.org]

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

--- Comment #9 from iive at yahoo.com ---
(In reply to Timothy Arceri from comment #8)
> Using SSE2 memcpy seems to avoid this problem"
> 
> Glib should select the SSE2 (or better) version of memcpy. If Slackware
> doesn't ship and SSE2 support for glibc I don't see how this is Mesas fault.
> 
> If I'm misunderstanding somthing please clarify. Otherwise I'm inclined to
> close this as won't fix.

Please,
I'm not done investigating this bug.
I also intent on writing some patches for it.

1.
The glibc memcpy() is optimized for system->system memory transfer. While it
might be faster than the problematic one, it still may not be the optimal one.

Also, nothing guarantees that glibc memcpy() will continue to work properly in
future. That's why it is good idea for Mesa to have its own implementation that
is known to always do the right thing, when going sys->vid mem transfer.

I can write the x86(_64), MMX/AVX assembly, I've written SIMD before.
Finding the all functions that have to use it, might be more tricky and need
help by experts.
(The memcpy I've reported is mostly used by Nine, but I'm getting the same
problem with other memcpy()s when using OpenGL.)
---
2.
Another issue that has to be checked is related to Write Combine caching.

In the past the XFree86 DDX driver was setting video memory region caching
through MTRR registers. That was removed in favor of using PAT (Page Attribute
Table, aka setting caching per memory page).

I have asked developers where is the PAT handling code. Is it in the kernel
kms, libdrm or Mesa3D itself? Where exactly? How do I check the caching status?

So far nobody was brave enough to answer. And if nobody has checked that code
recently, it might have silently stopped working some time ago.

(One reason why SSE2 code might be working better is that it usually employs
MOVNTQ. That instruction forces WC to avoid cache pollution.)


I want Mesa3D to always be fast. So help me help you.

-- 
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/20180831/24ab94f7/attachment.html>