Pitool Beta Test Release for Brainwarp 1.0


Need is relative. As some have had problems. Might be a good step to have headset disconnected during pitool installs.


Reinstalled everything but I still get flickering.

It’s related to performance (1080Ti), all I can do now is turn down graphic quality.
I think Brainwarp is trying to do something even when supposedly turned off.

Please fix this for the next version.


I’ve wondered about that as well.

Last night, while playing Elite Dangerous, I tried various graphics settings. The weird double images showed up whenever the framerate dropped to about half of the refresh rate (80 Hz). The reason I first noticed this is that I had bumped the in-game graphics setting, while in space (where the scenes are simpler) during my last session. A new session starts in a hanger (where the scene is more complex) and I was surprised to see the problem, because those settings had previously been fine.

I didn’t see this behavior in previous driver versions. It was strange; depending on the scene complexity, the double images would appear for a while and then disappear whenever the framerate increased above 40 FPS.


Even when you have smart smoothing disabled there are double images when you move your head left and right. Before this used to happen only when using smart smoothing.

Please remove this feature unless smart smoothing is enabled.


For now, I think I’ll set my refresh rate to 72 Hz, instead of 80 Hz, so that I’ll be less likely to drop below the halfway threshold. That way, I should be able to avoid the double images.


I had this happen when I was using virtual desktop the other day. Cpu and was pegged pretty high for some reason. Restarting pi services fixed it.
Quite often I have issues after running virtual desktop when launching something else. Seems like something is going on with pi services because a restart of those seems to fix things.


Have you tried changing piservice affinity as @Douglaster mentioned to last core with a higher priority?


No. But aren’t we losing these cores anyways do to the intel patch?


I’m not sure on the Intel side. I am running Amd.

Does this have to do with the isbit Zomb side load?

That would be a nasty blow to intel if it’s going after real cores versu hyper threading.


So I have been doing latency tests following a procedure and I think I have found an issue with the 72Hz mode that could explain why some people say the smart smoothing is not good in this beta 129 while others say smart smoothing works nicely.

Before sharing the test procedure and results here is my raw feedback on beta 129 that made me want to do the test I will share below:

  • On assetto corsa the smart smoothing didn’t work well at all for me. With smoothing active it is like the game is rendered at low refresh rate (= feels it runs “SLOW”), as if the interpolated images were not created and the game just being rendered at hal of the panel refresh.

  • The above creates this feeling of ghosting some others here have described, but it is not only ghosting, as said above assetto is felt running slow when smoothing is active, which is not the case with pitool 111.

  • Also doing a test of looking at my real wheel through the nose hole of the HMD while looking at the virtual wheel in the HMD at the same time, I noticed there was a HUGE latency between both when smoothing is active.

  • And last comment: testing a starting grip full of AI, being at the end of this grip to have all the cars in front of me, I noticed I could use much higher SS with pitool 111 than with pitool 129 before my fps starts to go below the panel refresh rate.

Now here is the tests I have made:

Initially I just wanted to test the latency. The results showed how smart smoothing was increasing the latency (so you really want to avoid using smoothing for any competitive gaming) but also an abnormal behaviour in 72Hz mode.

Test environment:

  • Game tested is assetto corsa, lotus evora GTC car, vallelunga track, practice session (only me on track), test made in pits.

  • Game options set all at minimum except AAx4 and AFx16.

  • GPU 980ti (G1 gaming) + 4770K CPU

  • all tests made at pitool 1.0 and with small FOV.

  • using fpsVR to gather additionnal datas

  • as I will be using different steamVR SS it is also important to note I have change the maxRecommendedResolution from 4096 to 8192 in the default.vrsettings file (this gives more refined steamVR SS setting).

Test procedure: @Sean.Huang

I use my camera to capture (@60fps) both the virtual rim (within HMD) and real rim at the same time, then do several quick rim rotations.

Then I analyze the video frame by frame to count the frames between real rim movement and virtual rim movement to obtain an estimated latency.

At the end of each video, after the separated rims rotations used for latency checking, I also do a continuous left/right rotation. This last part has been uploaded to YT and I’ll share the links below (videos are slowed down 6 times).

For each test I also gather those additionnal datas (from fpsVR): CPU & GPU utilization and frametimes, and FPS.

Test settings:

4 tests were made with pitool 111, then the same with pitool 129, and one with a htc vive to serve as reference (for latency).


Test1 - 72Hz - SS100 - smoothing Off:
CPU: 2-3ms (30%)
GPU: 6ms (45%)
Average Latency: 2-3 frames (=33-50ms)
Latency video: https://youtu.be/062xeN51tjY

Test2 - 90Hz - SS100 - smoothing Off:
CPU: 2-3ms (40%)
GPU: 6-7ms (60%)
Average Latency: 2-3 frames (=33-50ms)
Latency video: https://youtu.be/zGAXDPS-8iY

Test3 - 72Hz - SS300 - smoothing Off then On:
FPS: 62 (SMS off) / 36 (SMS on)
CPU: 2-3ms (42%) (SMS off) / 2-3ms (30%) (SMS on)
GPU: 14ms (85%) (SMS off) / 14ms (63%) (SMS on)
Average Latency (SMS on): 7 frames (=115ms)
Latency video: https://youtu.be/jJCu9G52ahw

Test4 - 90Hz - SS180 - smoothing Off then On:
FPS:83 (SMS off) / 45 (SMS on)
CPU: 2-3ms (36%) (SMS off) / 2-3ms (30%) (SMS on)
GPU: 10ms (80%) (SMS off) / 10ms (52%) (SMS on)
Average Latency (SMS on): 5 frames (=80ms)
Latency video: https://youtu.be/yJYQR4Ruhsc

Pitool129 (note test 3&4 have reversed order, 90Hz being made 1st this time):

Test1B - 72Hz - SS100 - smoothing Off:
CPU: 2-3ms (26%)
GPU: 6.5ms (45%)
Average Latency: 3-4 frames (=50-67ms)
Latency video: https://youtu.be/1S-COtgY-PQ

Test2B - 90Hz - SS100 - smoothing Off:
CPU: 2-3ms (27%)
GPU: 6-6.5ms (55%)
Average Latency: 3 frames (=50ms)
Latency video: https://youtu.be/yYaZWLKkDm8

Test3B - 90Hz - SS300 - smoothing Off then On:
FPS: 85 (SMS off) / 45 (SMS on)
CPU: 2-3ms (27%) (SMS off) / 2-3ms (25%) (SMS on)
GPU: 10ms (80%) (SMS off) / 10.5ms (56%) (SMS on)
Average Latency (SMS on): 5 frames (=80ms)
Latency video: https://youtu.be/dfn8ldj7SMM

Test4B - 72Hz - SS150 - smoothing Off then On:
FPS:59 (SMS off) / 36 (SMS on)
CPU: 2-3ms (24%) (SMS off) / 2-3ms (23%) (SMS on)
GPU: 15ms (85%) (SMS off) / 15ms (62%) (SMS on)
Average Latency (SMS on): 7 frames (=115ms)
Latency video: https://youtu.be/CK7N1eK9OqI

HTC vive reference - SS150:
CPU: 2-3ms (30%)
GPU: 5-6ms (44%)
Average Latency: 2 frames (=33ms)
Latency video: https://youtu.be/a2lG1mLGra8

Conclusion and comments:

  • a comment first: don’t take the latency in ms as super accurate, the methodoly can’t do that for several reasons (too big error margin due to 60fps video only, and you can’t start rotating the real wheel with enough accelaration to have a very clear (quick) rotation start that will reflect on the virtual rim). But the estimated latency is enough to spot real differences between tests (each rotations tests is done 4 to 6 times, and the number of frames of delay just vary by 1 at worst between each test iteration). And this difference clearly shows on the continuous left/right part of the test shown in the videos.

  • latency when you manage to have a steady fps reaching panel refresh is not that bad on the 5K+ but could be improved a bit if you compare with the vive result. Vive latency is below 30ms, while for the 5K+ it is around 40ms. Also the slowmo videos of the vive seem to show the virtual rim follows the real rim rotation closer (even though it has a small advantage as I could do as large rotations due to the smaller lenses, so the rotation speed doesn’t go as high as in the 5K+ videos).

  • latency with smoothing active is becoming huge, especially for competitive gaming. The tests also clearly shows the latency increase more in 72hz than 90hz mode (logical, but here you can see it quantified, you see you much worse it is in 72hz vs 90hz with smoothing On). Think a car running at 200km/h, every millisecond of latency represents 5cm. So 30ms is 1.5 meter, 80ms = 4m, and 115ms = almost 6m. This is a very big error when you have to drive tight against other cars, or have precise trajectory in a curve.

@Sean.Huang (see below)

  • in 72Hz mode I think there is a problem with pitool129: as you can see I have increased the steamVR SS to be able to test the smoothing. I was increasing it to force the smoothing to remain active but first I checked with smoothing off to be sure I don’t go too far below the refresh mode with the fps (so there is some “ressource room” for the smoothing feature).
    For the test4B I found the fps without smoothing was a bit too low (too far from 72fps). So I decided to lower the steamVR SS to leave more room (ressource) for the smoothing feature. But I couldn’t get closer to 72fps. At SS210 I had a steady 72fps, but then at 220 it already dropped massively to 42fps ! And SS250 was giving 46fps. And SS300 (as seen in the test results above) I get 59fps.
    So it seems there is something wrong there. And I wonder if the bad smoothing I reported at the beginning of this post as my general feedback after testing this lastest pitool, with the game being rendered at “slow speed” when smoothing was active (that was in 72hz mode) could be the result of a bug eating a lot of ressources and leaving not enough for the smoothing feature to work (or work properly). I will have to test the smoothing ingame (while driving) in 90hz mode (that one doesn’t seem to bug, I was able to reduce the steamVR SS to make this test @90hz remain closer to 90fps with smoothing desactivated. As you see I was able to set the SS to maintain a steady 85fps, while in 72hz there is a huge fps drop from the SS that gives a steady 72fps and the SS+10 that makes the fps drop almost half !). You can already see in video 4B the smoothing is not good at all, while it seems ok in video 3B. In 4B the rotated rim&hand move with “jumps”.


JFYI - Hellblade worked great last night. A little choppy but very playable on 8K.

No Parallel Projection
FOV Large
80 hz
No Smart Smoothing
Pitool Rendering 1.0
Game graphics setting High preset.

Using an i9 9900k RTX 2080 Ti btw.


Skyrim VR looks absolutely phenomenal on this version with the latest Steam Beta @ Pitool rendering 1, Steam 130% (The latest Steam Beta is also now reporting resolution differently? Seems an improvement), and with an ENB that fixes the tone mapping and adds a sharpening filter. I can’t honestly believe how crisp and defined everything looks. It’s like i’ve bought a new HMD. The upper limits of this 5K+ are really high.

3D depth seems much better too.

However, as noticed by others, there seems to be a latency issue. Ghosting image, even with Smart Smoothing turned off and a high framerate. You are definitely going in the right direction though!


Will need to recheck my settings on new pitool. But had hellblade running pretty good on my 1080ti.



72hz issue:

So I have now tried smoothing in 90hz mode using an assetto corsa replay, bumping steamVR SS just enough so that smoothing is always on, and I don’t have this “slow motion” issue as in 72hz mode. In 90hz mode, 45fps interpolated to 90fps really look like 90fps.

So there is really an issue with 72hz mode (at least with assetto corsa), where as soon as you reach the point the GPU can’t maintain constant 72fps the fps will have a huge drop (=like +10SS and you go from constant 72fps to 40fps), and then smart smoothing can’t work properly at all, smoothing feature is like bottlenecked and doesn’t manage to create the interpolated frames, so you only have the 36 real frames rendered by the GPU and it feels like playing in slow motion.

And I think this massive fps drop in 72hz may also explains why I can use much higher settings (like more SS) for the same scene (like being at the back of a full starting grid) with pitool 111 than with this lastest pitool (for 72hz mode only).


I have now also seen this ghosting often mentionned here, with smoothing active in 90hz mode. Following a car, in every turn I can see the rear side of the car ghosted. It is like we can see t-1 frame with 50% transparency overlayed onto the current frame. For exemple you see the front car back tyre + a ghost of this tyre a few pixels aside.


My SteamVR beta did an update yesterday and it re-set the maxRecommendedResolution to default, so those that have changed from default 4096 may want to check it.


To correlate with other’s findings. I can eliminate perceptual ghosting in the previous 121 beta by not using smart smoothing. Latency seems much better.


Is there a way like you can with oculus ovr command line parameters to emulate 30hz mode with the latest beta tool or sdk? (useful for things like xplane11)


what settings do you use with xplane 11?


Well done with your latency testing @neelrocker thats extremely comprehensive. Your videos clearly show how badly pimax is behind in regards to immersion. I think this is the number one reason for the sentiment of the Pimax looking “not quite right” compared to rift/vive.

I did high-speed video of the rotational latency of the pimax which you can see in this thread:
(or here: youtube link)

I used to think the pimax rotational latency was caused by IMU buffer lag, but after seeing your videos which show the extra latency without rotation, I’m more inclined to believe there’s a lag in pimax’s rendering pipeline. This is good news as its more likely to be solvable in software rather than firmware.


you don’t have to, pimax does it for a while now, look at the config file for the steamvr plugin
C:\Program Files\Pimax\SteamVRSupport\drivers\aapvr\resources\settings\default.vrsettings