Rawtherapee: Drop support for 32bit x86 builds

[heckflosse]

On irc, @Hombre57, @agriggio, @Beep6581 and I agreed to drop support for non SSE2 builds and for 32bit builds.

I would like to hear the opinion of other contributors and builders

[Floessie]

I'm against it. While 32b is debatable, non-SSE2 builds are essential IMHO. The world will shift away from Intel sooner or later. There are ARM, OpenPOWER and RISC-V on the rise, why should we cut them uncalled-for? Isn't that one of the reasons to prefer RT over DT?

Best,
Flössie

[heckflosse]

@Floessie Sorry, I meant non SSE2-builds for Intel/amd x86. I don't want to cut other architectures

[heckflosse]

@Floessie Let me rephrase: I would like to drop support for non-SSE2 builds on x86-architecture, as those builds are really slow. For x86/64 that's no problem because afaik all x86/64 cpus support SSE2.

Edit: Basically that would mean dropping support for x86_32

[Beep6581]

Concerning (our cessation of) shipping automated builds based on a stable i586/no-SSE toolchain:
https://www.reddit.com/r/openSUSE/comments/3d711c/will_leap_42_support_32bit_machines_given_that/ct2p2h9/
https://lists.opensuse.org/opensuse-buildservice/2018-01/msg00036.html

A growing number of distros are lacking the dependencies required to continue building 32-bit no-SSE RT, so this month I/we were already forced to drop support for a few i586 no-SSE build variants.

[Floessie]

@heckflosse

Let me rephrase: I would like to drop support for non-SSE2 builds on x86-architecture, as those builds are really slow. For x86/64 that's no problem because afaik all x86/64 cpus support SSE2.

😌 Phew, glad to hear that constraint!

Yes, SSE2 is a mandatory part of the x86-64 ISA. Whether "a build is really slow" qualifies as an argument for disabling it is questionable, though. Where's the benefit for us? To support other architectures, the #ifdef __SSE2__ must stay in place. If we raise some dependecies and those are no longer supported on a certain architecture or distribution, that's their problem, not ours. So, what's the intention here?

@Beep6581

A growing number of distros are lacking the dependencies required to continue building 32-bit no-SSE RT, so this month I/we were already forced to drop support for a few i586 no-SSE build variants.

Aha, that gives an answer: It's a question of management not of coding. I hope I interpreted it right.

I don't care which builds we ship as long as the code provides the means to compile everywhere.

Bottom line: Don't ship binaries that are hard to build automatically, and/but don't rely on unnecessary preconditions in the code.

Best,
Flössie

PS: A bit more background information would have prevented my grumbling...
PPS: There are distributions supporting i686 at least until 2022.

[agriggio]

@Floessie it's also a matter of how easy it is to test. If none of us ever tries to build for a i32/non-SSE target, parts of the code might just rot... this is an important reason IMHO.

[Floessie]

@agriggio That's exactly why it's important to support architectures other than x86-64: Better coverage. Indeed, I'm thankful for @mbajor to make us see beyond our own noses... 😃

[agriggio]

@Floessie I'd understand that if we had a clean code base. Unfortunately, we are very, very far from that. Widening our context is not going to make the situation better, I'm afraid.

[Floessie]

You're right with your criticism on the code quality (and I wish @adamreichold was still with us), but how can you make the code cleaner and thus more portable, if you don't have more platforms (compilers, architectures, ...) to confront it with? Monoculture won't help us to identify the soft spots.

[agriggio]

@Floessie, things like (for example -- but this is for real!)

if (condition) {
   do_this();
} else {
   do_this();
}

do not require any multiplatform support. I'm not talking about the fine details of writing the cleanest, most standards-compliant code out there. We are missing some basic stuff...

[heckflosse]

@Floessie

Where's the benefit for us?

I would like to get rid of all the __x86_64__ dependencies in code and I also don't want to make new ones just in case. We needed them in past to avoid crashes on 32bit SSE builds. Maybe we don't need them anymore because of fixes in gcc, maybe we still need them. I don't know and I can not test that.
Removing this dependencies could mean an automatic drop of 32 bit SSE support (because of crashes we can not test). Explicitely dropping support would be cleaner.

[Floessie]

@heckflosse So the title should really be "Drop support for 32bit x86 SSE builds". Then I'm with you. 👍 32b x86 builds should still be possible like every other 32b build.

[heckflosse]

@Floessie Yes, even 32b x86 SSE builds would be possible after removing the __x86_64__ dependencies (at least they should compile without problem) but may crash at runtime.

[gaaned92]

@all dev

What is your position regarding windows 32 bits builds?
I don't mind to build 32bit builds as I do for 64 bit, only if some dev are able to maintain them and so be able to run the build on windows 32 bits system and test.

When building for 32 bits I run the build on my 64bit windows, but I think it is not representative of the problems encountered on a 32bit system.

example: one of my last 32bit build runs ok here but does'nt start on user 32bit machine see
https://discuss.pixls.us/t/win-32-build-please/6388/25

[heckflosse]

Imho it does not make sense to make 32bit windows builds which run fine on Win64, but crash/don't start on Win32. Afaik none of the devs has access to a win32 system >= vista. Means, we can not test the builds in case crashes are reported.

[Floessie]

Has anyone ever tried ReactOS in qemu-system-i386?