RIFT & Multicore - some graphs

Hi,

So I would like to share some graphs. These graphs were generated using a Microsoft program called GPUView you can download in the Windows Performance Toolkit from Microsoft. It is a programmers tool designed to assist developers to tweak and fix performance problems in their graphical apps but anyone can run it. I decided to run it on RIFT.

First up some specs of my machine:
SPECS
Windows 10 64Bit
16GB of memory
Intel Core i5 - 4670K
AMD Radeon 7890 - 1680x1050
All settings at max in RIFT video settings

Standing in Margle Palace, pretty empty, not many people around.

NOTE: UI was DISABLED

SINGLE CORE

So this graph might seem pretty confusing but it's not really.

1. Vsync
The blue vertical lines indicate vsync, I have vsync turned off, so it won't actually line up on them but they are good for timing. This graph shows 3 whole frames.

2. Hardware Queue
The first darker blue row is the Hardware Queue, this indicates how "busy" the graphics card is. Each rectangle block indicates a packet of data that the video card is rendering or otherwise computing. 2 rows indicate the card is working on item while another is waiting to be processed.

The hashed block indicates a "present" packet, basically an application/windows asking the video card to display what it has onscreen.

It's also interesting to note some of the hashes start and go "over" a vsync. This means that you'll lose a frame and get tearing because the frame couldn't be fully displayed in that flip (see the next section on flip queues).

Note that any number of apps could be rendering data to the card at the same time RIFT is, especially if you run in Windowed mode (like I do), this queue represents TOTAL work submitted to the GPU.

Gaps in this queue indicate the GPU was idle as it had no work!

3. Flip Queue
Doing smooth graphics requires something called buffer flipping.

This queue indicates how long it took for the image to be sent to the screen and generally lines up with Vsync. Gaps indicate lower FPS and tearing (if vsync was off).
In this graph there is a huge loss between two vsyncs.

4. rift.exe - Device Context
This is the amount of work RIFT is sending to the card.

Items from this queue are moved to the hardware queue to render.

Gaps in this queue indicate periods where RIFT was not sending anything to the card!

Again, the hashed block indicates a "present" packet, indicating RIFT has finished and is asking the video card to display what it has onscreen.

5. GPU Work
The amount of work the GPU is doing. As you can see, the low points correspond to gaps in the Device Context and Hardware queue.

6. Application threads.
This picture isn't big enough to show all the threads, but the the lower 3 rows show actual thread usage.

Conclusion
As you can see, in single thread mode, RIFT is pretty clearly CPU bound, the graphics card is sitting idle for large amounts of time.

It is also not shown here, but the CPU is actual idle most of this time as well. Only one core was not idle during the gaps.

Not shown here, but if you were to zoom out, and look at the Flip Queue it shows that i'm getting about 4-5 frames good and then missing one. This shows that even though it is CPU bound, i'm still getting a pretty consistent FPS because most of the time, the renders are still fitting within a a single frame.

MULTI-CORE

You can clearly see 2 large changes. The Hardware Queue and the Device Context are almost devoid of gaps, this indicates the GPU is being utilized much more effectively.

You can also see the hashed blocks are almost back to back, frames are being pushed out almost immediately once the last one is finished, compare to the SINGLE core where there was a large delay between present packets.

And the flip queue is almost always full, a great sign showing frames are being rendered quickly!

Not shown here, but the CPU is not idle most of this time as well, all 4 cores are used quite alot.

Conclusion
As you can see, in MULTICORE mode, RIFT is pretty close to being GPU bound on my machine and the CPU is pushing out so much data the the video card is having trouble keeping up.

The FPS difference to Single core isn't that different, but it is alot more consistent and smooth.

MULTI-CORE - Ojingeodon

And finally a graph showing a fight against Ojingeodon. This was full UI enabled with spells and effects being thrown around.

This graph is curious, as you can see, a HUGE amount of data being sent by RIFT, and the card barely keeping up. But you can also see small gaps in the GpuWork (right at the bottom).

Also, notice the huge gaps between the vsync lines showing I'm losing every second frame, an indication i'm only getting about half the FPS!

Not shown is the IDLE listing showing the CPU was mostly idle, again indicating again, RIFT is GPU bound.

Overall Conclusion
For me, multi-threaded rendering is a winner, but I think I need a faster video card

ON THE OTHER HAND

And then, contrary to everything above, and almost making a mockery of it, we have this:

This graph was taken while in Margle palace. There are quite a few people around, but I had been alt-tabbed for a while.

Huge gaps in rendering, not only is the GPU idliling, but RIFT itself is having trouble with rendering. FPS has tanked, and half the cores are IDLE.

Multi-core is on, and no settings in RIFT have changed.

I don't really know what to make of this. It could be driver or RIFT related, but it might be something the RIFT developers would want to look at.

Looking at the thread usage of RIFT, it almost looks like it has reverted to single core!

Addendum/edit:
While I was attempting to replicate the last, I noticed someone move in front of me and teleport away and my FPS instantly jumped to 55! I'm going to keep an eye on this some more and see if I can pin it down.

Let's block ads! (Why?)

RIFT & Multicore - some graphs