Yes it stands for render thread which is the thread on the CPU that gives draw calls to the GPU among other things.
The more geometry the more draw calls and the draw time (frame render rate.)
the screenshot shows 6.6 fps which means a frame is taking around 150ms to fully render which is also displayed (1000ms/6.6s) - this is being caused by the render thread taking140ms to give the draw calls, physics calc’s etc to the GPU.
The frames will only be drawn as fast as any bottleneck allows.
If you have a low end GPU and high end CPU that will be the GPU but these days most people will be bottlenecked by the CPU.
I mentioned a few possible mitigating factors and workarounds but also I generally try to make the latency of my CPU and GPU comparable (Balanced) which I find gives me much less stutter etc.
So I basically look at how long it takes my CPU and GPU to render a frame and try to balance them with the settings and resolution changes.
To get a stable(ish) 60fps I look to have my CPU and GPU render at 15ms and cap at 60fps.
But because my GPU actually renders at about 10ms I either up the graphic settings or resolution to get closer to 15 which doesn’t hurt my fps.
We should actually adjust our stable fps expectations to the lowest common denominator so if we find our CPU is rendering 25ms and GPU at 8ms we should be looking for a stable 40fps and know we have free headroom on our GPU to up graphic or resolution settings.
Outside of some kind of bug spiking the CPU then Asobo/MS should really be, and likely are, concentrating on optimising the main thread as almost everyone is CPU bottlenecked rather than GPU and DX12 and Vulkan allow for this but as I see it this is not new engine, just the 2020 engine more optimised for DX12 with additional features and you really need to build a game from ground up with DX12 or Vulkan in mind to really utilise them.