CK III - Stutting performance

[xenobrain]

Short summary of your issue Stutting performance

Game Version 1.0.2

What OS are you playing on?
Linux

What platform are you using?
Steam

Do you have mods enabled? No

Have you tried verifying your game files (Steam only)?
Yes

How much "pain" is this causing you?
10

Please explain the issue you experienced in the most condensed way possible
Half second stutters every two seconds, including in menu. No difference fullscreen or windowed mode. No difference in performance settings.

Please explain how to reproduce the issue
Launch the game

Is there anything else you think could help us identify/replicate the issue?
System:
Arch Linux 64-bit. Intel Core i9-9900k. Nvidia Geforce RTX 2080Ti w/ proprietary drivers. KDE Plasma desktop. All software up to date as of 9/1/2020.

 

[salted-fry]

WORKAROUND: (warning: this is super hacky)
Remove your access to /dev/input. On my machine, I was able to do this by doing sudo chmod o-rx /dev/input/, thereby denying CK3 the permissions to read that directory.

After making this change, my computer seems to be a whole lot happier. (I still only get like 30FPS, but that's probably just because my machine is a bucket of rust these days)

This may break other stuff; in particular, I think it will probably break gamepad input in other games, if you care about that. If so, you should be able to restore to previous state by doing doing sudo chmod o+rx /dev/input/. You can also probably just reboot to restore it - I don't think this will persist across reboots.

 

[f00z]

WORKAROUND: (warning: this is super hacky)
Remove your access to /dev/input. On my machine, I was able to do this by doing sudo chmod o-rx /dev/input/, thereby denying CK3 the permissions to read that directory.

After making this change, my computer seems to be a whole lot happier. (I still only get like 30FPS, but that's probably just because my machine is a bucket of rust these days)

This may break other stuff; in particular, I think it will probably break gamepad input in other games, if you care about that. If so, you should be able to restore to previous state by doing doing sudo chmod o+rx /dev/input/. You can also probably just reboot to restore it - I don't think this will persist across reboots.

lol was just thinking of the implications of limiting access since the timing of the "fails" seemed minimal on the non-existent device paths it hit. Hoping the devs have enough to run with and fix the root cause. Thanks again for the leg work and workaround in the meantime!

 

[BrunoFilipe]

I'll be waiting a few days for a hotfix before refunding this one but I really expected to be able to play at release. Guess I shouldn't had high expectations considering how Paradox treats Linux.

 

[nikolayber3]

WORKAROUND: (warning: this is super hacky)
Remove your access to /dev/input. On my machine, I was able to do this by doing sudo chmod o-rx /dev/input/, thereby denying CK3 the permissions to read that directory.

After making this change, my computer seems to be a whole lot happier. (I still only get like 30FPS, but that's probably just because my machine is a bucket of rust these days)

This may break other stuff; in particular, I think it will probably break gamepad input in other games, if you care about that. If so, you should be able to restore to previous state by doing doing sudo chmod o+rx /dev/input/. You can also probably just reboot to restore it - I don't think this will persist across reboots.

Can you explain where do I do this? If I use this command in ck3 console it says "unknown command", if I use it in CMD, is sasys "no command starts with sudo". Help a computer noob to fix the game

 

[f00z]

Can you explain where do I do this? If I use this command in ck3 console it says "unknown command", if I use it in CMD, is sasys "no command starts with sudo". Help a computer noob to fix the game

if you are not on Linux this likely does not apply to your issue

 

[LuPoNe]

Can you explain where do I do this? If I use this command in ck3 console it says "unknown command", if I use it in CMD, is sasys "no command starts with sudo". Help a computer noob to fix the game

1) you should be on Linux
2) you should input these commands in the Linux terminal, not the CK3 console

 

[dex_sda]

I can confirm that I am having the exact same issue, and limiting access to /dev/input/ directory solves it instantly, as in, I can see the framerate dip every few seconds, then execute the command and have it lock at 144fps (the max on my display) as expected.

 

[Sturmreiter]

I can also confirm that the workaround worked for me as well. I haven't noticed any problems with anything else on my system, although I don't use gamepads normally so that probably doesn't mean much. Thank you for finding a solution, I would have had to play on Windows otherwise.

 

[Euphorya]

Removing my user from the 'input' group seems to have resolved the problem for me.

 

[ElricleNecro]

The workaround worked for me. Interesting to note : it also work for Imperator Rome (the problem is the same it seems).

In case of, I link my lshw.txt.

 

[Cederstronk]

Hey everyone,

Thank you so much for your lshw.txts and for uploading a video of the stuttering - this really helps our team as we've not been able to reproduce it fully on our end at this moment. Also, thanks for sharing the workarounds so that people can enjoy the game while we're trying to resolve the issue on our end.

We've logged this issue on our bug database and will continue to monitor the issue - I'll not lock the thread though, in case there's further developments with the workaround-troubleshooting.

Thanks again everyone,
Cederstronk

 

[Nellodee]

I've been having this issue as well and Euphorya's workaround works well for me.

It looks like the source of the slow /dev/input iteration is IsJoystick in SDL (see below). If SDL_USE_LIBUDEV is disabled this fallback implementation (which polls the /dev/input tree every 3 seconds) gets used over just checking for any available evdev events while detecting joystick devices. Maybe all that is needed to fix this is to build SDL with SDL_USE_LIBUDEV enabled?

Thanks for Linux support, hopefully this helps you narrow down a fix.

static void
LINUX_JoystickDetect(void)
{
#if SDL_USE_LIBUDEV
    SDL_UDEV_Poll();
#else
    const Uint32 SDL_JOY_DETECT_INTERVAL_MS = 3000;  /* Update every 3 seconds */
    Uint32 now = SDL_GetTicks();

    if (!last_joy_detect_time || SDL_TICKS_PASSED(now, last_joy_detect_time + SDL_JOY_DETECT_INTERVAL_MS)) {
        struct stat sb;

        /* Opening input devices can generate synchronous device I/O, so avoid it if we can */
        if (stat("/dev/input", &sb) == 0 && sb.st_mtime != last_input_dir_mtime) {
            DIR *folder;
            struct dirent *dent;

            folder = opendir("/dev/input");
            if (folder) {
                while ((dent = readdir(folder))) {
                    int len = SDL_strlen(dent->d_name);
                    if (len > 5 && SDL_strncmp(dent->d_name, "event", 5) == 0) {
                        char path[PATH_MAX];
                        SDL_snprintf(path, SDL_arraysize(path), "/dev/input/%s", dent->d_name);
                        MaybeAddDevice(path);
                    }
                }

                closedir(folder);
            }

            last_input_dir_mtime = sb.st_mtime;
        }

        last_joy_detect_time = now;
    }
#endif

    HandlePendingRemovals();

    SDL_UpdateSteamControllers();
}

static int
IsJoystick(int fd, char **name_return, SDL_JoystickGUID *guid)
{
    struct input_id inpid;
    Uint16 *guid16 = (Uint16 *)guid->data;
    char *name;
    char product_string[128];

#if !SDL_USE_LIBUDEV
    /* When udev is enabled we only get joystick devices here, so there's no need to test them */
    unsigned long evbit[NBITS(EV_MAX)] = { 0 };
    unsigned long keybit[NBITS(KEY_MAX)] = { 0 };
    unsigned long absbit[NBITS(ABS_MAX)] = { 0 };

    if ((ioctl(fd, EVIOCGBIT(0, sizeof(evbit)), evbit) < 0) ||
        (ioctl(fd, EVIOCGBIT(EV_KEY, sizeof(keybit)), keybit) < 0) ||
        (ioctl(fd, EVIOCGBIT(EV_ABS, sizeof(absbit)), absbit) < 0)) {
        return (0);
    }

    if (!(test_bit(EV_KEY, evbit) && test_bit(EV_ABS, evbit) &&
          test_bit(ABS_X, absbit) && test_bit(ABS_Y, absbit))) {
        return 0;
    }
#endif

    if (ioctl(fd, EVIOCGID, &inpid) < 0) {
        return 0;
    }

    if (ioctl(fd, EVIOCGNAME(sizeof(product_string)), product_string) < 0) {
        return 0;
    }

    name = SDL_CreateJoystickName(inpid.vendor, inpid.product, NULL, product_string);
    if (!name) {
        return 0;
    }

#ifdef SDL_JOYSTICK_HIDAPI
    if (!IsVirtualJoystick(inpid.vendor, inpid.product, inpid.version, name) &&
        HIDAPI_IsDevicePresent(inpid.vendor, inpid.product, inpid.version, name)) {
        /* The HIDAPI driver is taking care of this device */
        SDL_free(name);
        return 0;
    }
#endif

    FixupDeviceInfoForMapping(fd, &inpid);

#ifdef DEBUG_JOYSTICK
    printf("Joystick: %s, bustype = %d, vendor = 0x%.4x, product = 0x%.4x, version = %d\n", name, inpid.bustype, inpid.vendor, inpid.product, inpid.version);
#endif

    SDL_memset(guid->data, 0, sizeof(guid->data));

    /* We only need 16 bits for each of these; space them out to fill 128. */
    /* Byteswap so devices get same GUID on little/big endian platforms. */
    *guid16++ = SDL_SwapLE16(inpid.bustype);
    *guid16++ = 0;

    if (inpid.vendor && inpid.product) {
        *guid16++ = SDL_SwapLE16(inpid.vendor);
        *guid16++ = 0;
        *guid16++ = SDL_SwapLE16(inpid.product);
        *guid16++ = 0;
        *guid16++ = SDL_SwapLE16(inpid.version);
        *guid16++ = 0;
    } else {
        SDL_strlcpy((char*)guid16, name, sizeof(guid->data) - 4);
    }

    if (SDL_ShouldIgnoreJoystick(name, *guid)) {
        SDL_free(name);
        return 0;
    }
    *name_return = name;
    return 1;
}

 

[kekekeks]

Solved with this AppArmor profile that denies access to /dev/input/** specifically for CK3

/etc/apparmor.d/custom.ck3.202 :

# vim:syntax=apparmor

#include <tunables/global>


"/path/to/your/steam/steamapps/common/Crusader Kings III/binaries/ck3" {

  deny /dev/input rw,

  deny /dev/input/** rw,

  capability,

  network,

  mount,

  remount,

  umount,

  pivot_root,

  ptrace,

  signal,

  dbus,

  unix,

  file,

  deny /dev/input rw,

  deny /dev/input/** rw,

}

apply with

sudo apparmor_parser -r /etc/apparmor.d/custom.ck3.202

 

[mrcool830]

I've been having this issue as well and Euphorya's workaround works well for me.

It looks like the source of the slow /dev/input iteration is IsJoystick in SDL (see below). If SDL_USE_LIBUDEV is disabled this fallback implementation (which polls the /dev/input tree every 3 seconds) gets used over just checking for any available evdev events while detecting joystick devices. Maybe all that is needed to fix this is to build SDL with SDL_USE_LIBUDEV enabled?

Thanks for Linux support, hopefully this helps you narrow down a fix.

static void
LINUX_JoystickDetect(void)
{
#if SDL_USE_LIBUDEV
    SDL_UDEV_Poll();
#else
    const Uint32 SDL_JOY_DETECT_INTERVAL_MS = 3000;  /* Update every 3 seconds */
    Uint32 now = SDL_GetTicks();

    if (!last_joy_detect_time || SDL_TICKS_PASSED(now, last_joy_detect_time + SDL_JOY_DETECT_INTERVAL_MS)) {
        struct stat sb;

        /* Opening input devices can generate synchronous device I/O, so avoid it if we can */
        if (stat("/dev/input", &sb) == 0 && sb.st_mtime != last_input_dir_mtime) {
            DIR *folder;
            struct dirent *dent;

            folder = opendir("/dev/input");
            if (folder) {
                while ((dent = readdir(folder))) {
                    int len = SDL_strlen(dent->d_name);
                    if (len > 5 && SDL_strncmp(dent->d_name, "event", 5) == 0) {
                        char path[PATH_MAX];
                        SDL_snprintf(path, SDL_arraysize(path), "/dev/input/%s", dent->d_name);
                        MaybeAddDevice(path);
                    }
                }

                closedir(folder);
            }

            last_input_dir_mtime = sb.st_mtime;
        }

        last_joy_detect_time = now;
    }
#endif

    HandlePendingRemovals();

    SDL_UpdateSteamControllers();
}

static int
IsJoystick(int fd, char **name_return, SDL_JoystickGUID *guid)
{
    struct input_id inpid;
    Uint16 *guid16 = (Uint16 *)guid->data;
    char *name;
    char product_string[128];

#if !SDL_USE_LIBUDEV
    /* When udev is enabled we only get joystick devices here, so there's no need to test them */
    unsigned long evbit[NBITS(EV_MAX)] = { 0 };
    unsigned long keybit[NBITS(KEY_MAX)] = { 0 };
    unsigned long absbit[NBITS(ABS_MAX)] = { 0 };

    if ((ioctl(fd, EVIOCGBIT(0, sizeof(evbit)), evbit) < 0) ||
        (ioctl(fd, EVIOCGBIT(EV_KEY, sizeof(keybit)), keybit) < 0) ||
        (ioctl(fd, EVIOCGBIT(EV_ABS, sizeof(absbit)), absbit) < 0)) {
        return (0);
    }

    if (!(test_bit(EV_KEY, evbit) && test_bit(EV_ABS, evbit) &&
          test_bit(ABS_X, absbit) && test_bit(ABS_Y, absbit))) {
        return 0;
    }
#endif

    if (ioctl(fd, EVIOCGID, &inpid) < 0) {
        return 0;
    }

    if (ioctl(fd, EVIOCGNAME(sizeof(product_string)), product_string) < 0) {
        return 0;
    }

    name = SDL_CreateJoystickName(inpid.vendor, inpid.product, NULL, product_string);
    if (!name) {
        return 0;
    }

#ifdef SDL_JOYSTICK_HIDAPI
    if (!IsVirtualJoystick(inpid.vendor, inpid.product, inpid.version, name) &&
        HIDAPI_IsDevicePresent(inpid.vendor, inpid.product, inpid.version, name)) {
        /* The HIDAPI driver is taking care of this device */
        SDL_free(name);
        return 0;
    }
#endif

    FixupDeviceInfoForMapping(fd, &inpid);

#ifdef DEBUG_JOYSTICK
    printf("Joystick: %s, bustype = %d, vendor = 0x%.4x, product = 0x%.4x, version = %d\n", name, inpid.bustype, inpid.vendor, inpid.product, inpid.version);
#endif

    SDL_memset(guid->data, 0, sizeof(guid->data));

    /* We only need 16 bits for each of these; space them out to fill 128. */
    /* Byteswap so devices get same GUID on little/big endian platforms. */
    *guid16++ = SDL_SwapLE16(inpid.bustype);
    *guid16++ = 0;

    if (inpid.vendor && inpid.product) {
        *guid16++ = SDL_SwapLE16(inpid.vendor);
        *guid16++ = 0;
        *guid16++ = SDL_SwapLE16(inpid.product);
        *guid16++ = 0;
        *guid16++ = SDL_SwapLE16(inpid.version);
        *guid16++ = 0;
    } else {
        SDL_strlcpy((char*)guid16, name, sizeof(guid->data) - 4);
    }

    if (SDL_ShouldIgnoreJoystick(name, *guid)) {
        SDL_free(name);
        return 0;
    }
    *name_return = name;
    return 1;
}

From looking at the ck3 binary and patching it for this issue specifically, I can confirm LINUX_JoystickDetect (can be found through the /dev/input string ref) is the function it was getting stuck inside. If I put a ret instruction at the start of it, the game runs just fine.

 

[Morholt]

Same problem, also affects main menu and loading screens. Attached two sample screen captures to show the problem. Running Manjaro Linux.

 

[LuPoNe]

I have been playing the whole weekend on my laptop to try and reproduce the issue, but I haven't noticed any stuttering (unless it's so quick I didn't recall it happening) while running my portable Linux SSD with Manjaro (latest updates), with KDE Plasma and latest NVidia hybrid drivers (NVidia/Intel) installed from the Manjaro repositories.

The laptop is an MSI P65 Creator 9SE (it has Windows on its default drives as it's the daily driver for work).

I'll try to post my lshw.txt as soon as possible and I'd like to try and reproduce the issue possibly (I had this thread open when I first ran the game to have the commands at hand in case of stuttering).

 

[Chairman Noob]

Did you check with strace wether it tries to do stuff in /dev/input/* all the time but gets "Access denied" or similar on all of them? That's what it does for me. Apparently if the game doesn't have access to these files (because they've been manually restricted and/or the user isn't in the input group) the check won't noticeably affect performance.

 

[LuPoNe]

Did you check with strace wether it tries to do stuff in /dev/input/* all the time but gets "Access denied" or similar on all of them? That's what it does for me. Apparently if the game doesn't have access to these files (because they've been manually restricted and/or the user isn't in the input group) the check won't noticeably affect performance.

I've just started again to entertain myself in Linux, so I wouldn't know how to keep an eye for that / how to check that (I really would like to help however I can, given my newfound love for Linux in general)

 

[Chairman Noob]

Run

sudo strace -p "$(pidof ck3)" 2>&1 | grep '/dev/input'

in a terminal while playing.

 

[LuPoNe]

I confirm the issue being present also on my side, although I don't seem to get any performance hit.
I am running both Linux and the game off an external USB-C SSD, and following you can find both the STRACE and LSHW