New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

building altivec support on ppc64e results in color corruption in end products #3428

Closed

SDLBugzilla opened this issue Feb 11, 2021 · 0 comments · Fixed by #7684

Labels

waiting

Collaborator

SDLBugzilla commented Feb 11, 2021

This bug report was migrated from our old Bugzilla tracker.

Reported in version: 2.0.10
Reported for operating system, platform: Linux, PowerPC

Comments on the original bug report:

On 2019-10-20 12:36:38 +0000, wrote:

Observed running Wesnoth on Gentoo ppc64le, if libsdl2 is built with altivec enabled there is color corruption in the game. Simply rebuilding without the altivec support the problem goes away.

It appears there is an endianness assumption in the altivec code.

On 2019-10-20 14:10:36 +0000, Ozkan Sezer wrote:

How does 2.0.11 (current hg) behave? A fix was merged
for altivec with ppc64le about a month or so ago:
https://hg.libsdl.org/SDL/rev/9aa7aea27dec

On 2019-10-23 08:51:53 +0000, wrote:

I built 2.0.10 with the patch linked applied, and the patch on it's own doesn't seem to fix the issue.

I will investigate building from hg.

On 2019-12-01 23:59:13 +0000, wrote:

I have built libsdl2 from hg and it is still exhibiting the color corruption if built with altivec support enabled.

On 2019-12-02 00:17:34 +0000, Ozkan Sezer wrote:

(In reply to robert from comment # 3)

I have built libsdl2 from hg and it is still exhibiting the color
corruption if built with altivec support enabled.

Do you have a patch?

On 2019-12-02 00:41:34 +0000, wrote:

I haven't actually looked at the source code at this point. I am building from mercurial using a live ebuild in Gentoo.

On 2019-12-04 06:13:58 +0000, Sam Lantinga wrote:

We don't have a test environment to reproduce this. Can you investigate the code and provide a tested patch that fixes the issue for you?

Thanks!

On 2019-12-04 18:53:20 +0000, Ryan C. Gordon wrote:

(In reply to Sam Lantinga from comment # 6)

We don't have a test environment to reproduce this. Can you investigate the
code and provide a tested patch that fixes the issue for you?

Out of curiosity, where does one get a machine that supports this? Can it just be installed on an old G5 Mac and the OS will flip the CPU into littleendian mode at startup?

--ryan.

On 2019-12-04 22:53:30 +0000, wrote:

I have a Talos 2 from Raptor Computing Systems which uses POWER9 CPUs, and is bi-endian so can be run as either ppc64 or ppc64le. I opted to run ppc64le as it has less issues with endianness assumptions. Their website is https://www.raptorcs.com/ .

AIUI the PowerPC 970 CPU used in the Apple G5 systems was big endian only, as were most if not all IBM chips before the POWER7.

SDLBugzilla added bug waiting labels

Feb 11, 2021

slouken removed the bug label

May 11, 2022

JeremyRand pushed a commit to JeremyRand/SDL that referenced this issue

May 6, 2023


          SDL_blit_N.c: Move ppc64le swizzle outside of loop

2b6f423

An in-place swizzle mutation was erroneously inside of a loop, which
caused each consecutive 4-pixel vector to alternate between correct and
incorrect endianness.

The bug was introduced in 715e070.

Thanks to RobbieAB for reporting the bug.

Fixes libsdl-org#3428

JeremyRand mentioned this issue

May 6, 2023

SDL_blit_N.c: Move ppc64le swizzle outside of loop #7684

Merged

JeremyRand pushed a commit to JeremyRand/SDL that referenced this issue

May 6, 2023


          SDL_blit_N.c: Move ppc64le swizzle outside of loop

d021233

An in-place swizzle mutation was erroneously inside of a loop, which
caused each consecutive 4-pixel vector to alternate between correct and
incorrect endianness.

The bug was introduced in 715e070.

Thanks to RobbieAB for reporting the bug.

Fixes libsdl-org#3428

JeremyRand pushed a commit to JeremyRand/SDL that referenced this issue

May 6, 2023


          SDL_blit_N.c: Move ppc64le swizzle outside of loop

50c41ad

An in-place swizzle mutation was erroneously inside of a loop, which
caused each consecutive 4-pixel vector to alternate between correct and
incorrect endianness.

The bug was introduced in 715e070.

Thanks to RobbieAB for reporting the bug.

Fixes libsdl-org#3428

icculus closed this as completed in #7684

May 6, 2023

icculus pushed a commit that referenced this issue

May 6, 2023


          SDL_blit_N.c: Move ppc64le swizzle outside of loop

An in-place swizzle mutation was erroneously inside of a loop, which
caused each consecutive 4-pixel vector to alternate between correct and
incorrect endianness.

The bug was introduced in 715e070.

Thanks to RobbieAB for reporting the bug.

Fixes #3428

slouken pushed a commit that referenced this issue

May 6, 2023


          SDL_blit_N.c: Move ppc64le swizzle outside of loop

5e74365

An in-place swizzle mutation was erroneously inside of a loop, which
caused each consecutive 4-pixel vector to alternate between correct and
incorrect endianness.

The bug was introduced in 715e070.

Thanks to RobbieAB for reporting the bug.

Fixes #3428

(cherry picked from commit 9142292)

sezero pushed a commit to libsdl-org/SDL-1.2 that referenced this issue

May 6, 2023


          SDL_blit_N.c: Move ppc64le swizzle outside of loop

788e1b9

An in-place swizzle mutation was erroneously inside of a loop, which
caused each consecutive 4-pixel vector to alternate between correct and
incorrect endianness.

The bug was introduced in libsdl-org/SDL@715e070
(77a2237).

Thanks to RobbieAB for reporting the bug.

Fixes libsdl-org/SDL#3428

(cherry picked from commit libsdl-org/SDL@9142292)

icculus pushed a commit to icculus/SDL that referenced this issue

May 12, 2023


          SDL_blit_N.c: Move ppc64le swizzle outside of loop

00c6af5

An in-place swizzle mutation was erroneously inside of a loop, which
caused each consecutive 4-pixel vector to alternate between correct and
incorrect endianness.

The bug was introduced in 715e070.

Thanks to RobbieAB for reporting the bug.

Fixes libsdl-org#3428

sezero pushed a commit to sezero/SDL that referenced this issue

May 17, 2023


          SDL_blit_N.c: Move ppc64le swizzle outside of loop

b1c1754

An in-place swizzle mutation was erroneously inside of a loop, which
caused each consecutive 4-pixel vector to alternate between correct and
incorrect endianness.

The bug was introduced in 715e070.

Thanks to RobbieAB for reporting the bug.

Fixes libsdl-org#3428

(cherry picked from commit 9142292)

lexi-the-cute pushed a commit to lexi-the-cute/SDL that referenced this issue

May 22, 2023


          SDL_blit_N.c: Move ppc64le swizzle outside of loop

7242ab9

An in-place swizzle mutation was erroneously inside of a loop, which
caused each consecutive 4-pixel vector to alternate between correct and
incorrect endianness.

The bug was introduced in 715e070.

Thanks to RobbieAB for reporting the bug.

Fixes libsdl-org#3428

(cherry picked from commit 9142292)

mikrosk pushed a commit to mikrosk/SDL-1.2 that referenced this issue

Dec 21, 2023


          SDL_blit_N.c: Move ppc64le swizzle outside of loop

a649c7c

An in-place swizzle mutation was erroneously inside of a loop, which
caused each consecutive 4-pixel vector to alternate between correct and
incorrect endianness.

The bug was introduced in libsdl-org/SDL@715e070
(libsdl-org@77a2237).

Thanks to RobbieAB for reporting the bug.

Fixes libsdl-org/SDL#3428

(cherry picked from commit libsdl-org/SDL@9142292)

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

building altivec support on ppc64e results in color corruption in end products #3428

building altivec support on ppc64e results in color corruption in end products #3428

SDLBugzilla commented Feb 11, 2021