https://bugs.kde.org/show_bug.cgi?id=465548
caulier.gil...@gmail.com changed:
What|Removed |Added
Resolution|--- |FIXED
Status|CONFIRMED
https://bugs.kde.org/show_bug.cgi?id=465548
--- Comment #18 from Graeme Hewson ---
I'm the original reporter of the problem. I'm pleased to say the AppImage works
fine on an AMD Athlon II under Kubuntu 23.04.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=465548
--- Comment #17 from caulier.gil...@gmail.com ---
Note : here only Intel CPU based computer are available to test. So i cannot
validate myself the fixes.
Gilles Caulier
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=465548
--- Comment #16 from caulier.gil...@gmail.com ---
Hi all,
The current code of future 8.1.0 is patched. I recompiled the Linux AppImage
pre-release to see if problem is reproducible (it's compiled under Ubuntu
18.04). Files are there :
https://bugs.kde.org/show_bug.cgi?id=465548
--- Comment #11 from caulier.gil...@gmail.com ---
To Erich Eickmeyer comment 4:
This is how original QtAV deal with SSE instructions. I only port all QtAV
rules to a modern CMake implementation. C++ codes still the same.
Gilles Caulier
--
You are
https://bugs.kde.org/show_bug.cgi?id=465548
--- Comment #15 from caulier.gil...@gmail.com ---
Git commit 799953eef9f43fb38d781cff8bea8eb201bb78bb by Gilles Caulier.
Committed on 26/05/2023 at 07:09.
Pushed by cgilles into branch 'master'.
Handle SSE2 and SSE4 combination, not as separated
https://bugs.kde.org/show_bug.cgi?id=465548
--- Comment #14 from caulier.gil...@gmail.com ---
In fact the wrong logic can be seen in C++ code :
https://invent.kde.org/graphics/digikam/-/blob/master/core/libs/video/qtav/utils/GPUMemCopy.cpp#L108
The cache used to copy with SSE is initialized if
https://bugs.kde.org/show_bug.cgi?id=465548
--- Comment #13 from caulier.gil...@gmail.com ---
To Fabian Vogt comment 9:
This is completly wrong. Both SSE 2 or 4 are detected, definition are set and
ALSO the CPU flags. Read well the cmake code AND the cmake Media player
configuration report
https://bugs.kde.org/show_bug.cgi?id=465548
--- Comment #12 from Erich Eickmeyer ---
(In reply to caulier.gilles from comment #11)
> To Erich Eickmeyer comment 4:
>
> This is how original QtAV deal with SSE instructions. I only port all QtAV
> rules to a modern CMake implementation. C++ codes
https://bugs.kde.org/show_bug.cgi?id=465548
--- Comment #10 from caulier.gil...@gmail.com ---
As explained here :
https://stackoverflow.com/questions/6901369/how-to-detect-sse-availability-in-cmake
The VS code from github include the OptimizeForArchitecture.cmake, which come
from KDE in fact. I
https://bugs.kde.org/show_bug.cgi?id=465548
--- Comment #9 from Fabian Vogt ---
QtAV upstream does this correctly already: src/utils/CopyFrame_SSE4.cpp is
built with -msse4.1, src/utils/CopyFrame_SSE2.cpp is built with -msse2 and
src/utils/GPUMemCopy.cpp decides during runtime which of those to
https://bugs.kde.org/show_bug.cgi?id=465548
Paul changed:
What|Removed |Added
CC||pip@gmx.com
--
You are receiving this mail
https://bugs.kde.org/show_bug.cgi?id=465548
--- Comment #8 from Fabian Vogt ---
(In reply to Antonio Rojas from comment #7)
> You can set -DSSE4_1_FOUND=OFF at configure time.
As a workaround that's certainly possible, but it's not a proper solution. This
will break e.g. once checks for AVX are
https://bugs.kde.org/show_bug.cgi?id=465548
--- Comment #7 from Antonio Rojas ---
You can set -DSSE4_1_FOUND=OFF at configure time.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=465548
Fabian Vogt changed:
What|Removed |Added
Severity|normal |crash
Ever confirmed|0
https://bugs.kde.org/show_bug.cgi?id=465548
caulier.gil...@gmail.com changed:
What|Removed |Added
CC||caulier.gil...@gmail.com
https://bugs.kde.org/show_bug.cgi?id=465548
--- Comment #5 from Maik Qualmann ---
Yes, we may have to reconsider that. But it only affects our internal QtAV. It
affects the function to copy frames, but it is also checked at runtime whether
SSE4 is actually available.
Maik
--
You are receiving
https://bugs.kde.org/show_bug.cgi?id=465548
--- Comment #4 from Erich Eickmeyer ---
Inspecting the code with another, it seems as though you've got an issue here:
https://invent.kde.org/graphics/digikam/-/blob/master/core/cmake/macros/MacroSSE.cmake#L40
You're getting the SSE info from the
https://bugs.kde.org/show_bug.cgi?id=465548
Fabian Vogt changed:
What|Removed |Added
CC||fab...@ritter-vogt.de
--
You are receiving this
https://bugs.kde.org/show_bug.cgi?id=465548
Erich Eickmeyer changed:
What|Removed |Added
CC||mity...@gmail.com
--- Comment #3 from Erich
https://bugs.kde.org/show_bug.cgi?id=465548
Maik Qualmann changed:
What|Removed |Added
CC||metzping...@gmail.com
--- Comment #2 from Maik
https://bugs.kde.org/show_bug.cgi?id=465548
Graeme Hewson changed:
What|Removed |Added
CC||b...@wormhole.me.uk
--- Comment #1 from Graeme
22 matches
Mail list logo
