Github messages for voidlinux
 help / color / mirror / Atom feed
From: Akaricchi <Akaricchi@users.noreply.github.com>
To: ml@inbox.vuxu.org
Subject: Re: taisei: update to 1.4.1
Date: Wed, 27 Mar 2024 17:01:42 +0100	[thread overview]
Message-ID: <20240327160142.B86102212A@inbox.vuxu.org> (raw)
In-Reply-To: <gh-mailinglist-notifications-41a7ca26-5023-4802-975b-f1789d68868e-void-packages-49348@inbox.vuxu.org>

[-- Attachment #1: Type: text/plain, Size: 2301 bytes --]

New comment by Akaricchi on void-packages repository

https://github.com/void-linux/void-packages/pull/49348#issuecomment-2023140980

Comment:
> An easy way is to check out this branch, then do

I'm not a Void user, so I think I'll just set up the i686 version of Void in a container for testing.

> Isn't that a good reason to build with sse2 by default?

I don't mind bumping it up to `-msse2` upstream. I only went with `-msse` by default because that's the minimum requirement for `-mfpmath=sse`, and I was somewhat more conservative about i686 support back then.

> You can achieve a similar result without sse using -ffloat-store (at a cost).

Not really. `-ffloat-store` only prevents individual variables from being stored in registers. It won't break up calculations in expressions, e.g. `float x = a * b / (c - d);` the whole thing will be computed in extended precision unless you move every calculation into a separate variable, which is not acceptable for Taisei. Even then, a calculation performed at 80-bit precision truncated to 64 bits may still have a slightly different result. Not to mention the overhead introduced by placing every single float variable into RAM.

> BTW, do you really need level=20 for zstd? That's supposed to use a lot of memory. Maybe 19 is good enough (or you could use something like 20 if sys.maxsize > 2**32 else 19).

The script definitely wasn't written with limited memory/address space in mind. I'll try 19 on i686 and see if it helps.

There's an alternative solution though: you could split the package into `taisei` and `taisei-data`. The latter would be noarch and can be built just once, on a 64-bit userspace.

```sh
# taisei without data
cd /the/build/dir
ninja src/taisei doc/GAME.html doc/ENVIRON.html doc/STORY.txt doc/README.txt
meson install --destdir=/whatever --no-rebuild --tags runtime,doc,license,xdg
```

```sh
# taisei-data only
cd /the/build/dir
ninja resources/00-taisei.zip
meson install --destdir=/whatever --no-rebuild --tags resources
```

Unfortunately `meson install` isn't smart enough to only rebuild what's needed according to `--tags`, so the build targets have to be specified manually for now. I can alleviate this problem upstream by adding some shorthand alias build targets, though.

  parent reply	other threads:[~2024-03-27 16:01 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-18 11:00 [PR PATCH] taisei 1.4.1 version bump aryalaadi
2024-03-25 16:35 ` [PR PATCH] [Updated] " aryalaadi
2024-03-25 16:51 ` aryalaadi
2024-03-25 16:55 ` [PR REVIEW] taisei: update to 1.4.1 tornaria
2024-03-25 16:56 ` tornaria
2024-03-25 17:00 ` [PR PATCH] [Updated] " aryalaadi
2024-03-25 17:04 ` aryalaadi
2024-03-25 17:16 ` aryalaadi
2024-03-26 14:07 ` [PR REVIEW] " tornaria
2024-03-26 16:17 ` [PR PATCH] [Updated] " aryalaadi
2024-03-26 16:29 ` tornaria
2024-03-26 23:54 ` ahesford
2024-03-27  3:38 ` tornaria
2024-03-27  3:54 ` [PR PATCH] [Updated] " aryalaadi
2024-03-27  3:56 ` aryalaadi
2024-03-27  3:57 ` [PR PATCH] [Updated] " aryalaadi
2024-03-27  4:27 ` aryalaadi
2024-03-27  4:32 ` aryalaadi
2024-03-27 11:01 ` [PR REVIEW] " tornaria
2024-03-27 11:10 ` tornaria
2024-03-27 11:24 ` ahesford
2024-03-27 11:24 ` ahesford
2024-03-27 11:30 ` ahesford
2024-03-27 13:05 ` [PR REVIEW] " Akaricchi
2024-03-27 13:29 ` Akaricchi
2024-03-27 13:29 ` Akaricchi
2024-03-27 13:30 ` Akaricchi
2024-03-27 14:24 ` tornaria
2024-03-27 14:49 ` [PR PATCH] [Updated] " aryalaadi
2024-03-27 14:51 ` aryalaadi
2024-03-27 14:57 ` aryalaadi
2024-03-27 16:01 ` Akaricchi [this message]
2024-03-27 16:07 ` Akaricchi
2024-03-27 16:07 ` Akaricchi
2024-03-27 17:01 ` ahesford
2024-03-27 20:10 ` tornaria
2024-03-28  9:30 ` [PR PATCH] [Updated] " aryalaadi
2024-03-28  9:38 ` aryalaadi
2024-03-28  9:40 ` aryalaadi
2024-03-28  9:42 ` aryalaadi
2024-03-29 16:19 ` [PR PATCH] [Updated] " aryalaadi
2024-03-29 23:11 ` tornaria
2024-03-30  0:21 ` tornaria
2024-03-30 13:28 ` unspecd
2024-03-31 20:49 ` recp
2024-04-01 15:14 ` recp
2024-04-02  6:00 ` aryalaadi
2024-04-02  6:35 ` [PR PATCH] [Updated] " aryalaadi
2024-04-02  6:41 ` aryalaadi
2024-04-02  6:49 ` aryalaadi
2024-04-02  6:52 ` aryalaadi
2024-04-02  7:07 ` aryalaadi
2024-04-02  7:53 ` aryalaadi
2024-04-02 11:44 ` [PR REVIEW] " ahesford
2024-04-02 13:02 ` [PR PATCH] [Updated] " aryalaadi
2024-04-02 13:03 ` [PR REVIEW] " aryalaadi
2024-04-03 21:24 ` tornaria

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240327160142.B86102212A@inbox.vuxu.org \
    --to=akaricchi@users.noreply.github.com \
    --cc=ml@inbox.vuxu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).