There can be many different reasons. As others have noted, the by far most likely cause is that the game is CPU bottlenecked. Ark is built with Unreal Engine, so that’s a quite likely explanation, given that Unreal’s architecture really likes to put all the game logic on a single CPU core.
Ark exposes Unreal’s stat unitgraph console command. Run that in the in-game console to see what part of the game takes how long for each frame. (See: https://ark.fandom.com/wiki/Console_commands#Stat) If either Game or Draw (or RHI, but I don’t think Ark has an RHI thread, it’s Unreal version is too old afaik) is taking longer than GPU, then you have your explanation, namely that the GPU is waiting for the CPU to catch up.
There would also be other possible explanations, for instance CPU/GPU waiting for each other. This can for instance happen if the game uses scene captures. (I don’t play Ark, so I don’t know if they do - typical use-cases for scene captures would be mirrors, or rendered player portraits). The CPU might request a Scene Capture, is then waiting for the GPU to complete it, then does CPU stuff with its result while the GPU is waiting for work, and only later submits the next frame for rendering… I don’t know how to diagnose this in Unreal without having access to a development build though.
What I could also imagine is that the numbers shown by the program you are using aren’t taking every kind of GPU activity into account. Might be that they only show load on Vector/Scalar units, and count stalls caused by (GPU-)memory access as “idle”. But that’s just a guess… With the radeontop command you can get a bit more information. (https://archlinux.org/packages/extra/x86_64/radeontop/). Just make sure to run it on a second screen, or to access it via ssh, such that the game has mouse/keyboard focus - otherwise Unreal might reduce framerate.
And last, but not least: There is always the possibility of a driver bottleneck. I have faint memories (but no link any more…) that the AMD Linux drivers bottleneck at very high FPS. I might remember wrong, but iirc the FPS numbers at which that shows were extremely high - way above of what any display could process, and way above what any actual game could realistically deliver.
This sounds pretty much like the opposite of what the GDPR aims for.
IANAL, but as I understand Article 5(1)(e), shipping companies need to give good reasons why they would be storing data after they have delivered the package:
My best guess is for handling of complaints. Like, people receive the package, but only open it some time later, just to realize that the contents have been damaged during transport.