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://files.kde
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 rec
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 support
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 a
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 don
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 st
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 t
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 c
https://bugs.kde.org/show_bug.cgi?id=465548
Paul changed:
What|Removed |Added
CC||pip@gmx.com
--
You are receiving this mail because:
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
S
16 matches
Mail list logo
