Hide Forgot
Description of problem: Currently the code needlessly tries to check if SSE2 is available and then use it. However, in all supported QEMU CPUs, we expose SSE2. In addition, it looks like this hack has #ifndef _WIN64 , which means in WIN64 we don't use the fast (manually implemented) memcpy. The compiler knows how to do it memcpy fast using SSE2 if we have the flag in the compiler to target SSE2. (Note: need to see if it can do it even if the memory is not aligned, but in any case this can't hurt). Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
too much pressure on the current qxl driver for beta. need to stabilize the driver first, set delel_ack-
Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.
Don't want this closed won't fix, moving to rhev-m future. David we should revisit this potentially before 3.1
The driver doesn't use memcopy but rather RtlCopyMemory, which I think is not affected by this flag. Implementing SSE for win64 will probably help video performance there.
ack the bug. we can re-compile, the new binary has to be certified
(In reply to comment #11) > ack the bug. we can re-compile, the new binary has to be certified This means WHQL process again?
(In reply to comment #11) > ack the bug. we can re-compile, the new binary has to be certified Please see comment #8. This flag is not relevant for kernel drivers. We implement the SSE2 memory copy by ourselves for the 32-bit driver. But we are missing this implementation for the 64-bit driver. I would have tried to compare hd video on windows 7 32-guest to windoes 7 64-guest, and if there is a major difference, consider implementing the SSE2 code for 64-guest. Or wait till we have a user space driver...
I highly doubt win7 does not use SSE for memcpy, in kernel. In any case, I don't see the harm in adding this compilation switch. Regardless, the fact we don't have it for Win7/64 is documented at https://bugs.freedesktop.org/show_bug.cgi?id=37457
(In reply to comment #13) > (In reply to comment #11) > > ack the bug. we can re-compile, the new binary has to be certified > > Please see comment #8. This flag is not relevant for kernel drivers. 1. In this case we need to close this bug, or change the subject to "Implement the SSE2 code for the 64-bit kernel space driver" >We > implement the SSE2 memory copy by ourselves for the 32-bit driver. 2. Was it worse doing it? Any performance improvements were observed on Win32? >But we are > missing this implementation for the 64-bit driver. I would have tried to > compare hd video on windows 7 32-guest to windoes 7 64-guest, 3. it is reasonable and easy step. > and if there is a > major difference, consider implementing the SSE2 code for 64-guest. 4. if difference, then the implementation is justified! > Or wait > till we have a user space driver...
set devel_ack? and will re-visit in the rhevm-future
Let's keep it for rhev-future, There is no rush to add to the rhevm release.
posted patches on spice-devel removing all SSE2 using fast_memcpy_* code after benchmarks showed it was slower then the internal RtlCopyMemory (which is ifdeffed to memcpy in current Windows development kits). http://patchwork.freedesktop.org/patch/25265/
Patch series was sent to spice-devel in http://lists.freedesktop.org/archives/spice-devel/2014-April/016774.html but this never made it upstream for some reason :(
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions
This bug has not been marked as blocker for oVirt 4.3.0. Since we are releasing it tomorrow, January 29th, this bug has been re-targeted to 4.3.1.
4.3.1 has been released, please re-target this bug as soon as possible.
Closing, no one really did any effort to look at this since 2014 (comment 19 or so).