Hey there folks! Today I bring you a smaller but new test I did recently with my system.
I wanted to see what the actual performance difference was when running Left 4 Dead 2 natively in Ubuntu 13.04 versus running it in Windows 8. To visually gauge this difference, I took a look at the frames per-second and recorded the outcome in the following video:
Needless to say, I was actually shocked when watching the videos and seeing the difference myself. This reassures me that Native gaming is a must over Wine gaming (although this is just my opinion).
Some may point out that Fraps is too heavy of a screen recorder to get an accurate reading of fps, however I tried other alternatives available to me such as XFire and MSI Afterburner and Fraps hands down is the only one giving Windows a fighting chance. [More info on this in the description of the video page].
Remember, that Windows is usually heralded as having better support and drivers compared to Linux in general. Taking this into consideration, both OS's were put under the duress of running L4D2 at maxed out settings while simultaneously performing the screen recording as well. I ran the Windows test multiple times to ensure similar results, and I ran the Ubuntu test twice with the same results.
Please pause the video at 0:08 to view the settings at which I played L4D2 (the settings are same across both OSs).
Ending notes:
I am only human, so it is very likely there were mistakes or things I may have overlooked. Please feel free to correct me, offer me guidance or even post your own results! The more tests we have, the greater the sample we can make judgement from.
A thank you to the kind folks who guided me on ways to better my future test videos based on my older videos, I hope to do a few more of these if people enjoy watching them.
Please note that the experience may be completely different for AMD graphics users and Intel graphics users. I do not claim that this will be what everyone experiences whether now, in the past or in the future. It is just what I have so far consistently experienced. Article taken from GamingOnLinux.com.
I wanted to see what the actual performance difference was when running Left 4 Dead 2 natively in Ubuntu 13.04 versus running it in Windows 8. To visually gauge this difference, I took a look at the frames per-second and recorded the outcome in the following video:
YouTube videos require cookies, you must accept their cookies to view. View cookie preferences.
Direct Link
Direct Link
Needless to say, I was actually shocked when watching the videos and seeing the difference myself. This reassures me that Native gaming is a must over Wine gaming (although this is just my opinion).
Some may point out that Fraps is too heavy of a screen recorder to get an accurate reading of fps, however I tried other alternatives available to me such as XFire and MSI Afterburner and Fraps hands down is the only one giving Windows a fighting chance. [More info on this in the description of the video page].
Remember, that Windows is usually heralded as having better support and drivers compared to Linux in general. Taking this into consideration, both OS's were put under the duress of running L4D2 at maxed out settings while simultaneously performing the screen recording as well. I ran the Windows test multiple times to ensure similar results, and I ran the Ubuntu test twice with the same results.
Please pause the video at 0:08 to view the settings at which I played L4D2 (the settings are same across both OSs).
Ending notes:
I am only human, so it is very likely there were mistakes or things I may have overlooked. Please feel free to correct me, offer me guidance or even post your own results! The more tests we have, the greater the sample we can make judgement from.
A thank you to the kind folks who guided me on ways to better my future test videos based on my older videos, I hope to do a few more of these if people enjoy watching them.
Please note that the experience may be completely different for AMD graphics users and Intel graphics users. I do not claim that this will be what everyone experiences whether now, in the past or in the future. It is just what I have so far consistently experienced. Article taken from GamingOnLinux.com.
0 Likes
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
Patreon
PayPal
- Fraps captures frames by intercepting API calls from OpenGL or Direct3D. SimpleScreenRecorder does the same if you use the OpenGL recording mode, but otherwise it uses X11 calls instead. The key difference is that the method used by fraps or SSR with OpenGL recording is synchronous (it blocks the game while a frame is captured) whereas the X11 calls are asynchronous (the game isn't blocked and as a result you can get tearing). So it doesn't surprise me that you saw a very noticeable drop in frame rate.
- SSR uses FFmpeg which has a large collection of codecs, and some of them are very fast (e.g. x264 and ffvhuff). Fraps has only one (custom) codec, and I don't think it is as fast as the ones in FFmpeg.
- SSR and some of the codecs (x264 and VP8) are designed to take advantage of multiple CPU cores. I'm not sure whether Fraps does this too. In fact, it is possible that Fraps does the encoding in the game itself rather than in a separate process - I don't know.
- SSR has a highly optimised RGB-to-YUV converter. It converts a full 1080p frame in 2ms on my CPU. The fastest other open-source implementation I have found needs 3ms. A plain C implementation needs 8ms. FFmpeg normally needs 16ms. If you record at high frame rates, this starts to add up. I don't know how well this part of Fraps is optimised.
Another thing to note is that no linux drivers other than the proprietary AMD driver currently support asynchronous readbacks from the GPU to RAM (NVidia has added asynchronous upload for newer cards, but not readback AFAIK). For this reason, SSR doesn't even try to do asynchronous readback. I hope this will improve in the future, but right now OpenGL recording will cause a big drop in FPS for this reason.
All this is a bit besides the point, because when you are recording a game, the goal shouldn't be to get the highest possible frame rate. The goal is to make the frame rate of the game match the frame rate of the final video exactly, so no CPU or GPU time is wasted and you get the highest possible quality. There is an option in SSR that does this if you use OpenGL recording. Doing so will also eliminate tearing and make the video smoother.
Still, it's an interesing test :).
It could even be a disadvantage for ubuntu compared to windows(Even though the result does seem to point the other way).
Why dont you also measure the fps without screen capture software and post it aswell?
I am editing a new video of L4D2 running in both Windows and Ubuntu without any screen recorder, and both using a demo file to ensure timing is the same. It is being done with a low end camera though, and I feel even with this video there will be quite a few people I cannot satisfy.
However, I am grateful for the guidance and advice many of you have given me. Hopefully this next video will better represent my experience on both platforms in terms of L4D2 (outside of screen capture that is). I should have the video uploaded in a couple of days, and one other test video in conjunction with this redone test.
Graphic card - nvidia geforce gt450, 1gb ram, latest nVidia drivers on both system
I don't see any difference between ubuntu and windows in terms of FPS, didn't run precise benchmark but if there would be even 20% difference I would noticed, but seems the same FPS on the same places, with the same averages and on the same scenes FPS drops, etc.
But generally on windows L4D run more smoothly - on linux I have periodical lags when game stops for 0.1-0.2 seconds each 5-15 seconds
Regarding the fps, it is indeed relatively the same on both Operating systems. I removed the screen recorders and used Source's Demo ability, so the following video better represents the performance between the two.
View video on youtube.com
Uploaded this days ago, but it got stuck in YouTube processing (happened before too).