Bug#865721: openarena: Please add platform support for m68k

[John Paul Adrian Glaubitz]

On 06/24/2017 04:54 PM, Simon McVittie wrote:
> Instead of hard-coding yet more architectures, I'd prefer to submit the
> equivalent of https://github.com/ioquake/ioq3/pull/129 to OpenArena.
> Please tell this bug if you get there before I do. I sent the equivalent
> of that pull request to the ioquake3, iortcw and OpenJK game engines,
> but forgot to send a copy for the OpenArena game-code, which is what's
> in Debian's src:openarena.

I have looked at that but upstream changed their source code such that
this patch will not be necessary anymore. Architectures are not explicitly
listed in q_platform.h anymore [1].

>> openarena currently fails to build from source on m68k because
>> this architecture is not known within code/qcommon/q_platform.h
> 
> Has the game resulting from this change been tested and demonstrated
> to work?

No. But is this a requirement for each and single patch now?

> I would very much prefer not to hard-code explicit support for particular
> architectures without some demonstration that the architecture does,
> in fact, work.

I'm pretty sure no one tested openarena on s390x either, did one?

Same applies for ppc64el.

> If the build system is just running `uname -m` and hoping
> for the best, that doesn't make any particular statement about whether
> the result is functional on particular CPUs; but if the build system
> explicitly mentions __m68k__, that looks uncomfortably like a statement
> that it is known to work on m68k, which seems misleading if nobody has
> actually tried it.

I don't see how this is a problem. We don't do full tests of each
and every package in Debian on every architecture, do we? If
people run into issues, they report them and that's fine.

> I find it hard to believe that OpenArena is particularly useful on
> m68k. OpenArena uses the idTech3 engine from Quake III Arena (which
> needed up-to-date PC hardware with 3D acceleration circa 1999), and has a
> general technical direction of allowing larger textures / higher polygon
> counts than Quake III Arena itself. According to Wikipedia, m68k reached
> EOL in 1994. Is there any m68k hardware with enough performance and RAM
> capacity to actually run the idTech3 engine and achieve multiple frames
> per second?

There are FGPA-based m68k CPUs now with 600 MHz and more, so yes, I think
running OpenArena on m68k is possible. In fact, m68k has modern features
like Compare-And-Swap with two arguments which doesn't even exist
on modern x86_64 hardware. So, as long as the m68k CPU (or its emulation)
are fast enough and there is enough RAM, I don't see any particular
problem with running OpenArena on m68k.

> I'd suggest building only the dedicated server part, which needs less
> CPU/RAM and does not use or need 3D acceleration... but I'm finding it
> hard to imagine why anyone would choose to run their OpenArena dedicated
> server on m68k rather than on, for example, Debian armel or Raspbian
> armhf on a $5 Raspberry Pi Zero? (Or, more likely, a spare PC.)

I'm not sure what the problem with merging a trivial patch like this
is. The patch won't be necessary for future upstream versions anyway
and for now it just fixes the build.

> If dpkg supported marking packages as "Architecture: !m68k !powerpcspe"
> I'd consider doing that, but to the best of my knowledge it doesn't. If
> you don't want this game failing to build from source and messing up your
> percentage-built statistics, perhaps listing it as Not-For-Us would be
> a useful approach?

Why do you explicitly want to discriminate against ports architectures?

OpenArena would run perfectly fine on powerpcspe. The reason why the
build currently fails there is because upstream thought it's a good
idea to hardcode -maltivec on PowerPC even though not all PowerPC
targets automatically support AltiVec. PowerPCSPE doesn't have Altivec
instructions, it uses SPE. I will fix that as well, but I haven't come
up with a good solution yet. I fixed a similar bug in Firefox upstream
already and they didn't dismiss my patch with "No one runs Firefox
on PowerPCSPE anyway." FWIW, PowerPCSPE are just embedded PowerPC CPUs.

If you remove -maltivec on powerpcspe conditionally (you can apply
that particular patch only if $(dpkg --print-architecture) == powerpcspe,
the package will build just fine.

Here's one of my PowerPCSPE systems. You don't think this will run
a 3D shooter from 1999?

root at atlantis:~> cat /proc/cpuinfo
processor       : 0
cpu             : e500v2
clock           : 1199.880000MHz
revision        : 5.1 (pvr 8021 1151)
bogomips        : 99.99

processor       : 1
cpu             : e500v2
clock           : 1199.880000MHz
revision        : 5.1 (pvr 8021 1151)
bogomips        : 99.99

total bogomips  : 199.98
timebase        : 49995000
platform        : Tabor
model           : varisys,TABOR
Memory          : 4096 MB
root at atlantis:~>

Adrian

> [1] https://github.com/ioquake/ioq3/blob/master/code/qcommon/q_platform.h

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913