I was able to use parallel SSH sessions to monitor changes in =
the files
suggested by Max Staudt, which I did by using the command:

watch -n 1 cat filename

The relevant files that existed and I was able to watch are:

/sys/kernel/debug/dri/0/clients
/sys/kernel/debug/dri/0/gem_names
/sys/kernel/debug/dri/0/radeon_gtt_mm
/sys/kernel/debug/dri/0/radeon_vram_mm
/sys/kernel/debug/dri/0/ttm_dma_page_pool
/sys/kernel/debug/dri/0/ttm_page_pool

I will attach the captures of each output, each showing its file <=3D 1 =
second
before the freeze. I understand those files should retain information about
VRAM, which indicates whether this could be a progressive memory leak.

Very important note: It has taken me hours to obtain those outputs, and for=
 a
while I thought the freeze was fixed by an update altogether. For over 2 ho=
urs
I was able to run all game engines that produced this crash without getting=
 any
freeze whatsoever, which has never happened before! However the freeze retu=
rned
after I restarted my machine, meaning it's still present. I have no idea
whether there's a switch in my system that causes it to happen only sometim=
es,
but hopefully those files will say something.