Recording seems to disable the GPU

[brmbrmcar]

When I am recording in Ubuntu 16.04, the GPU stops running at all, but stopping or pausing recording puts it straight back on. FPS go back down to near enough exactly where they were when no graphics card was installed. The GPU temperatures also go down. This is a sign that it is stopping. If you want any terminal outputs just ask.

[QuImUfu]

What GPU, CPU and what graphics driver are you using? What do you try to record?

Maybe the power state of you GPU gets set wrongly (i don't think so) or you CPU is bottlenecking (depending on your encoding settings and CPU this is pretty likely).

If the RX460 mentioned here is the GPU you are using you could try using "GALLIUM_HUD=fps,cpu,VRAM-usage,GPU-load" set as environment variable to test whether the CPU or GPU bottlenecks.

Just to make sure: Do you use "Record the entire Screen" or "Record OpenGL"?

[brmbrmcar]

Yes, that is my GPU. I have been using record the entire screen (custom makes no difference) but I haven't tried with OpenGL record. My CPU is AMD A8-7670K Radeon R7 and I am using the open source Linux drivers from AMD. I'll try that command soon

[brmbrmcar]

How do I run that command?

[QuImUfu]

ok. Recording the whole screen cripples performance. If you want to record some OpenGL Application (minecraft is great for testing), use "Record OpenGL". Than launch the Game from command line via (you can leave the "GALLIUM_HUD=..." part out when you finish testing)

GALLIUM_HUD=fps,cpu,VRAM-usage,GPU-load ssr-glinject [insert command to launch whatever you want to record here]

if you actually want to record the whole screen, i think you'll have to live with that performance.

[brmbrmcar]

The performance cripple was almost non-existent when I had no GPU...

[QuImUfu]

You had a GPU. A iGPU. And maybe the speed when recording the whole screen is limited by memory speed and CPU speed. I don't know. The only thing i know it was slow in every test i made on every computer i own when recording OpenGL applications. You really want to record the whole screen and no OpenGL (or Wine DirectX) app?

Does recording the Desktop lag without one demanding program open at the same time? I, with a much worse Computer can record it at stable 75fps without demanding program open at the same time. Maybe someone else knows how to speed this up.

[brmbrmcar]

The system didn't treat it like a GPU, and I am near enough certain the "real" graphics card is being deactivated somewhere.

[QuImUfu]

That is, in my knowledge not even possible. There are, in my experience two things that can cause very slow recording with ssr:

One thing that can happen is that, if you use the "Record the entire Screen" you GPU becomes a little bit less useful and doesn't get stressed that much because something else slows down. I don't think this can be improved very much. This way of recording is slower on Windows, too. That is why there is the "Record OpenGL" option, that enables you GPU to be used better while recording (reducing the CPU-usage and stopping tearing and lags in the video).

The other reason could be suboptimal encoding settings. In my experience the YouTube preset works very well. Other encoding settings might stress the CPU too much or, much more funny can even surpass you HDD speed (uncompressed).

It would help very much if you could tell me what you want to record so i can try to reproduce.

Some comparison values for you what performance you can expect: I use the YouTube preset for encoding and record with 30fps.
On my PC (Radeon HD 4550, Intel(R) Core(TM) i5 CPU 750 @ 2.67GHz) i can record Minecraft using both methods in 30fps and the "Record the entire Screen" is actually faster because my GPU is so bad. If this does not work on you PC something is going wrong. On my other, much worse PC with a much worse CPU but a little bit better GPU the "Record the entire Screen" produces a terrible (tearing) 10fps ish Video and slows MC down (CPU wise) while the "Record OpenGL" produces a pretty good 15-20fps Video without tearing.

You could however test your theory that you GPU is not being used at all by running

GALLIUM_HUD=fps,cpu,VRAM-usage,GPU-load glxgears

while recording and by looking at the GPU-load graph.

[brmbrmcar]

I use lossless recording (noooo) with an SSD (rekt).

I use the H.264 codec losslessly in MP4. On any game that is assisted by the GPU (like it makes a big difference) has a significant drop in FPS, to roughly where it was with no GPU.

Here is the output from that command:

19967 frames in 5.0 seconds = 3993.386 FPS
17758 frames in 5.0 seconds = 3551.442 FPS
17705 frames in 5.0 seconds = 3540.904 FPS
15853 frames in 5.0 seconds = 3170.589 FPS
18230 frames in 5.0 seconds = 3645.924 FPS
18733 frames in 5.0 seconds = 3746.520 FPS
15986 frames in 5.0 seconds = 3195.779 FPS
(started recording)
4433 frames in 5.0 seconds = 882.945 FPS
3739 frames in 5.0 seconds = 746.029 FPS
4124 frames in 5.0 seconds = 824.796 FPS
(stopped recording)
8309 frames in 5.0 seconds = 1661.777 FPS
19526 frames in 5.0 seconds = 3905.095 FPS
21277 frames in 5.0 seconds = 4255.326 FPS
19555 frames in 5.0 seconds = 3910.868 FPS
19994 frames in 5.0 seconds = 3998.664 FPS

[StripedMonkey]

Lossless recording. at ~3k fps....

I don't think you quite understand how massive the data transfer rate must be.

at 60fps that would be the equivalent of 50 miniutes. You are putting 50 minutes of footage on your SSD per SECOND. I'm sorry but I don't think you can transfer that much data every second.

On Wed, Dec 28, 2016 at 6:55 PM, brmbrmcar notifications@github.com wrote:

I use lossless recording (noooo) with an SSD (rekt).

I use the H.264 codec losslessly in MP4. On any game that is assisted by the GPU (like it makes a big difference) has a significant drop in FPS, to roughly where it was with no GPU.

Here is the output from that command:

19967 frames in 5.0 seconds = 3993.386 FPS 17758 frames in 5.0 seconds = 3551.442 FPS 17705 frames in 5.0 seconds = 3540.904 FPS 15853 frames in 5.0 seconds = 3170.589 FPS 18230 frames in 5.0 seconds = 3645.924 FPS 18733 frames in 5.0 seconds = 3746.520 FPS 15986 frames in 5.0 seconds = 3195.779 FPS (started recording) 4433 frames in 5.0 seconds = 882.945 FPS 3739 frames in 5.0 seconds = 746.029 FPS 4124 frames in 5.0 seconds = 824.796 FPS (stopped recording) 8309 frames in 5.0 seconds = 1661.777 FPS 19526 frames in 5.0 seconds = 3905.095 FPS 21277 frames in 5.0 seconds = 4255.326 FPS 19555 frames in 5.0 seconds = 3910.868 FPS 19994 frames in 5.0 seconds = 3998.664 FPS

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/MaartenBaert/ssr/issues/518#issuecomment-269560705, or mute the thread https://github.com/notifications/unsubscribe-auth/AHo2RHsr-7xXOJHfo1Q64YUcapkHL0OAks5rMvb5gaJpZM4LWMpT .

[StripedMonkey]

I'm a massive derp, thats 50 seconds of footage. not miniutes. >.< In any case thats still a lot of data transfer especially when I assume you have a 1080p screen that you are recording.

On Wed, Dec 28, 2016 at 8:15 PM, Noah notifications@github.com wrote:

Lossless recording. at ~3k fps....

I don't think you quite understand how massive the data transfer rate must be.

at 60fps that would be the equivalent of 50 miniutes. You are putting 50 minutes of footage on your SSD per SECOND. I'm sorry but I don't think you can transfer that much data every second.

On Wed, Dec 28, 2016 at 6:55 PM, brmbrmcar notifications@github.com wrote:

I use lossless recording (noooo) with an SSD (rekt).

I use the H.264 codec losslessly in MP4. On any game that is assisted by the GPU (like it makes a big difference) has a significant drop in FPS, to roughly where it was with no GPU.

Here is the output from that command:

19967 frames in 5.0 seconds = 3993.386 FPS 17758 frames in 5.0 seconds = 3551.442 FPS 17705 frames in 5.0 seconds = 3540.904 FPS 15853 frames in 5.0 seconds = 3170.589 FPS 18230 frames in 5.0 seconds = 3645.924 FPS 18733 frames in 5.0 seconds = 3746.520 FPS 15986 frames in 5.0 seconds = 3195.779 FPS (started recording) 4433 frames in 5.0 seconds = 882.945 FPS 3739 frames in 5.0 seconds = 746.029 FPS 4124 frames in 5.0 seconds = 824.796 FPS (stopped recording) 8309 frames in 5.0 seconds = 1661.777 FPS 19526 frames in 5.0 seconds = 3905.095 FPS 21277 frames in 5.0 seconds = 4255.326 FPS 19555 frames in 5.0 seconds = 3910.868 FPS 19994 frames in 5.0 seconds = 3998.664 FPS

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/MaartenBaert/ssr/issues/518#issuecomment-269560705, or mute the thread https://github.com/notifications/unsubscribe-auth/AHo2RHsr- 7xXOJHfo1Q64YUcapkHL0OAks5rMvb5gaJpZM4LWMpT

.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/MaartenBaert/ssr/issues/518#issuecomment-269567100, or mute the thread https://github.com/notifications/unsubscribe-auth/AHo2RKYti47D8WyHmmNDYMIpF378nOzeks5rMwnMgaJpZM4LWMpT .

[brmbrmcar]

That isn't SSR fps. That is the output of a different command. I record at 61 fps.

[QuImUfu]

i don't think that recording lossless is possible even with a ssd. The ssd had to write something like 6000MB/s for 60fps at 4096×2160 and would be full (i assume the ssd is max one TB big) in ca 2-3 min. if you reduce your fps to 30 and record at only 1920x1080, it might be possible with a RAID system ("only" 750MB/s and 20-25 min) but still very much not a good idea. !note that i did not test these values! I just assumed h264 can losslessy reach 0.3 the raw file size.(that is pretty good) Lossy conversion is absolute necessary. You can make it lossy with a low -cfr value (ca 20) and you won't notice a difference. You eye just can't see it. There is no reason to ever encode lossless (except for testing or fun or in a huge archive).

[StripedMonkey]

Also note: probably not a good idea to record onto an SSD as that will burn it out very quickly with all the read/write that you are doing.

On Thu, Dec 29, 2016 at 7:49 AM, QuImUfu notifications@github.com wrote:

i don't think that recording lossless is possible even with a ssd. The ssd had to write something like 6000MB/s for 60fps at 4096×2160 and would be full (i assume the ssd is max one TB big) in ca 2-3 min. if you reduce your fps to 30 and record at only 1920x1080, it might be possible with a RAID system ("only" 750MB/s and 20-25 min) but still very much not a good idea. !note that i did not test these values! I just assumed h264 can losslessy reach 0.3 the raw file size.(that is pretty good) Lossy conversion is absolute necessary. You can make it lossy with a low -cfr value (ca 20) and you won't notice a difference. You eye just can't see it. There is no reason to ever encode lossless (except for testing or fun or in a huge archive).

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/MaartenBaert/ssr/issues/518#issuecomment-269625975, or mute the thread https://github.com/notifications/unsubscribe-auth/AHo2RNZXMib0okBCTS5gzBKZMN5bVPSSks5rM6xTgaJpZM4LWMpT .

[brmbrmcar]

I only get maximum of 2GB/minute generally. It is lossless, not entirely uncompressed. Anyway changing that doesn't change anything much on the performance side.

[QuImUfu]

So you got the same problem with the unaltered YouTube preset? And again. What do you want to record? A Game? The Desktop? Some material can be compressed losslesly very well, it might produce reasonably small files. then the problem is somewhere else.

[brmbrmcar]

I want to record games.

[MaartenBaert]

1080p YUV420 at 60fps is ~178 MB/s. That's feasible with an SSD but it will be full rather quickly. In fact I just tried it, it works, at least for a few minutes.

On topic: Your GPU is not 'stopping', if it had stopped then your screen would be frozen or completely black. Also, I highly doubt that you had no GPU before, you probably meant no dedicated GPU (NVIDIA/AMD) but an integrated CPU (Intel).

What you are seeing is that the recording is stalling the GPU while it reads back the frames. This is unavoidable. Dedicated GPUs store their frames in video memory, but SSR needs them in RAM, so there is a copy involved. Consumer-grade GPUs are not capable of copying data between GPU memory and RAM while simultaneously rendering things - it's either one or the other. So while SSR copies frames from the GPU to RAM, the GPU is doing nothing. You don't see this bottleneck with integrated GPUs because they use the RAM as their video memory, so there is no copy necessary.

In the case of OpenGL recording (ssr-glinject) there is another bottleneck related to how OpenGL works. The way ssr-glinject currently captures frames isn't terribly efficient and can cause the GPU to be idle for a short time after every frame, this is really noticeable with some modern GPU-heavy games. I was working on a new implementation that improves this, but it's not finished yet.

There's also some inexplicable bottleneck related to reading back images from NVIDIA cards, something which isn't unique to SSR (I know bumblebee is affected by it too). For some reason the PCI Express bus utilization is much higher than the raw bit rate of the data that is actually being read back, and this can become a bottleneck in laptops that don't have enough PCI Express lanes. Desktops typically have 16 PCIe v3 lanes, which is about 16GB/s. Unfortunately some new laptops have only 4 PCIe v2 lanes (probably to save power), which is only 2GB/s. The raw bitrate of 1080p 60fps RGB32 video is about 500MB/s, so in theory that should be enough, but for some reason the actual PCIe bus utilization is much higher than that. With regular screen recording, it's around 800MB/s. With OpenGL recording, it's around 3.5GB/s. When I'm not recording and just running glxgears in fullscreen at 60 fps, it's close to zero. If you are also running Bumblebee, this number doubles. I have no idea why this is happening, so I can't do much to fix it.

[QuImUfu]

What games?

After some reading and testing i do think i was wrong (sorry for that) and the transfair rare on any point of the system is high enough and the thing that created i/o problems on my PC was recording completely uncompressed.

Some ideas what might help you performance:

1. Use Vsync or similar (some games allow you to limit their CPU usage). As far as i understand from glxgears output you have disabled Vsync. This makes a lot of games use as much system resources as possible (without having any positive effect). This does slow down you CPU and GPU and might be the reason your recording gets slower. Additionally the Vsync the opensource Radeon driver uses never made any problems for me and is working very well. If you use the OpenGL record method you can instead use the "OpenGL Settings -> limit application frame rate" setting.

2. Use nice to force smooth encoding Something else that helped me recording was using nice to force the game to run on 3 cores and use the last one only for ssr. This slowed down the game a bit but made the recording much faster.

3. Think about using a faster codec If you really want to use lossless encoding use ffvHuff or make sure to use the veryfast preset with h264 lossless because every other preset uses way to much CPU power. In my own tests the h264 encoder uses about 20-35% of my CPU in its fastest setting and would use 400% at its slowest setting (reduces speed to 15 fps), it will use even more on you PC because you most likely use a higher resolution than i. The ffvHuff encoder uses only 10-13% (nearly constant) and produces ~6 (my test in Minecraft) times as big files (300-350Mbit/s) as h264 (~1Mbit/s on nearly frozen images and ~150Mbit/s on fast moving pictures). If you have got enough free space (300 GB for two hours at 1280x1024@60fps) and find it acceptable to re-encode the file later on, using ffvHuff might be a good idea.

Other than that i have, without further information (game you want to Record, exact settings you are using...) no other idea.

[brmbrmcar]

I use ultrafast H.264 losslessly! I always said that! I don't really understand nice, and it would become a pain. Some games also don't have integrated vsync options, which is another pain.

(It is "simple"screenrecorder you know 😊)

I run at 1920x1080 at 61fps. My container is MP4 and my audio is Vorbis at 128 quality. I have allowed frame skipping.

[QuImUfu]

Looking again at you glxgears output i found something pretty weird: My PC is not much slower than yours while it should be more than 10x slower and when you start recording you framerate becomes worse than mine. :astonished:

This might however be caused by you resizing the glxgears window or because you use a different resolution or have other programs open at the same time.

So i want to ask you if you could set you desktop and recording resolution to 1280x1024 and to close all other programs. Only ssr and one terminal executing

vblank_mode=0 glxgears

should be open. Make sure nothing overlaps the glxgears window and do not resize it Then test it again while recording and while not recording. Record with the settings you used before, except the resolution. (i.e: record whole screen; 1280x1024@61fps; video: H.264 losslessly, ultrafast preset; audio: Vorbis, 128 bitrate; container: mp4)

These are, if you are interested, my values with exactly this environment: 18856 frames in 5.0 seconds = 3771.097 FPS 19223 frames in 5.0 seconds = 3844.556 FPS 18818 frames in 5.0 seconds = 3763.418 FPS 18574 frames in 5.0 seconds = 3714.699 FPS 18333 frames in 5.0 seconds = 3666.455 FPS 18491 frames in 5.0 seconds = 3698.103 FPS 18518 frames in 5.0 seconds = 3703.442 FPS 18209 frames in 5.0 seconds = 3641.623 FPS 18427 frames in 5.0 seconds = 3685.272 FPS 18454 frames in 5.0 seconds = 3690.731 FPS 18847 frames in 5.0 seconds = 3769.232 FPS (started recording) 14391 frames in 5.0 seconds = 2878.169 FPS 14184 frames in 5.0 seconds = 2836.705 FPS 14063 frames in 5.0 seconds = 2812.552 FPS 14010 frames in 5.0 seconds = 2801.908 FPS 13978 frames in 5.0 seconds = 2795.473 FPS 14439 frames in 5.0 seconds = 2887.718 FPS 14389 frames in 5.0 seconds = 2877.747 FPS 13979 frames in 5.0 seconds = 2795.711 FPS (stopped recording) 17441 frames in 5.0 seconds = 3487.976 FPS 18568 frames in 5.0 seconds = 3713.459 FPS 18410 frames in 5.0 seconds = 3681.833 FPS 17539 frames in 5.0 seconds = 3507.772 FPS

[brmbrmcar]

19240 frames in 5.0 seconds = 3847.943 FPS 18205 frames in 5.0 seconds = 3640.876 FPS 18243 frames in 5.0 seconds = 3648.533 FPS 18200 frames in 5.0 seconds = 3639.940 FPS 18252 frames in 5.0 seconds = 3650.244 FPS 13267 frames in 5.0 seconds = 2653.389 FPS (started recording) 7970 frames in 5.0 seconds = 1593.958 FPS 7837 frames in 5.0 seconds = 1567.374 FPS 7867 frames in 5.0 seconds = 1573.374 FPS 7915 frames in 5.0 seconds = 1582.929 FPS 7700 frames in 5.0 seconds = 1539.914 FPS (stopped recording) 13079 frames in 5.0 seconds = 2615.729 FPS 18296 frames in 5.0 seconds = 3659.192 FPS 18293 frames in 5.0 seconds = 3658.551 FPS

[QuImUfu]

What ubuntu version are you running on? As you have seen, your vales are very oddly slower than my values.

Could you boot into a live system of newest ubuntu 16.10 , install ssr and repeat this test with completely default driver and system settings and with the same ssr settings you have used in the post above? (this will, of curse not influence you running system in any way.)

This would make sure that it is not a Driver/System problem.

[MaartenBaert]

Look, it's not realistic to test with glxgears running at >1000fps because no actual game will ever do that. Test with a realistic game at around 60 fps. The number you are seeing now are not meaningful.

Also, SSR has an option under OpenGL recording to limit the game frame rate, which makes more CPU time available to SSR. This can help improve recording FPS. It obviously reduces game FPS though.

[QuImUfu]

That is true, but it should not be slower than it is on my pc. That's why i think something could be wrong with his driver. A RX460 should never be 1/2 as fast as a HD4550. It should be 10x faster, or at least as fast. Even a GT620 (still much worse card) gets done 10000fps. His graphics card should be performing much better than it is. That is why i think there has to be something wrong with the driver/his System. And if his computer is much faster in glxgears in live-cd mode, it would proof that. (that is only needed because glxgears is a bad benchmark. if his system would be slower than mine in some real-world benchmark that would be enough proof for some faulty driver/configuration)

But you are right, using a proper benchmark would be better.

If @brmbrmcar is ready to install and run the unigine valley benchmark on his current system with the ExtremeHD preset and do the same test (recording and not recording. looking at the fps and writing them here), this would be better.

[brmbrmcar]

I am on Ubuntu 16.04. I can try with a benchmark or even live booting if you want.

[MaartenBaert]

It could also be that he is just running a much slower window manager. At ridiculous frame rates like that, you are benchmarking the window manager, not the application. Like I said, try running a real benchmark like Unigine Valley.

[brmbrmcar]

Output:

Loading "/home/brmbrmcar/Unigine_Valley-1.0/bin/../data/valley_1.0.cfg"...
Loading "libGPUMonitor_x64.so"...
Loading "libGL.so.1"...
Loading "libopenal.so.1"...
Set 1920x1080 fullscreen video mode
Set 1.00 gamma value
Unigine engine http://unigine.com/
Binary: Linux 64bit GCC 4.4.5 Release Feb 14 2013 r11294
Features: OpenGL OpenAL XPad360 Joystick Flash Editor
App path:  /home/brmbrmcar/Unigine_Valley-1.0/bin/
Data path: /home/brmbrmcar/Unigine_Valley-1.0/data/
Save path: /home/brmbrmcar/.Valley/

---- System ----
System: Linux 4.4.0-57-generic x86_64
CPU: AMD A8-7670K Radeon R7, 10 Compute Cores 4C+6G  3590MHz MMX+ SSE SSE2 SSE3 SSSE3 SSE41 SSE42 SSE4A SSE5 AVX HTT x4
GPU: Unknown GPU x1
System memory: 7925 MB
Video memory:  256 MB
Sync threads:  3
Async threads: 4

---- MathLib ----
Set SSE2 simd processor

---- Sound ----
Renderer: OpenAL Soft
OpenAL vendor:   OpenAL Community
OpenAL renderer: OpenAL Soft
OpenAL version:  1.1 ALSOFT 1.16.0
Found AL_EXT_LINEAR_DISTANCE
Found AL_EXT_OFFSET
Found ALC_EXT_EFX
Found EFX Filter
Found EFX Reverb
Found EAX Reverb
Found QUAD16 format
Found 51CHN16 format
Found 61CHN16 format
Found 71CHN16 format
Maximum sources:         256
Maximum effect slots:    4
Maximum auxiliary sends: 2

---- Render ----
GLRender::GLRender(): Unknown ATI GPU
OpenGL vendor:   ATI Technologies Inc.
OpenGL renderer: AMD Radeon (TM) RX 460 Graphics
OpenGL version:  3.2.13453 Core Profile Context 16.40.5
OpenGL flags:    Core Profile
Found required GL_ARB_map_buffer_range
Found required GL_ARB_vertex_array_object
Found required GL_ARB_draw_instanced
Found required GL_ARB_draw_elements_base_vertex
Found required GL_ARB_transform_feedback
Found required GL_ARB_half_float_vertex
Found required GL_ARB_half_float_pixel
Found required GL_ARB_framebuffer_object
Found required GL_ARB_texture_multisample
Found required GL_ARB_uniform_buffer_object
Found required GL_ARB_geometry_shader4
Found optional GL_ARB_blend_func_extended
Found optional GL_ARB_tessellation_shader
Found optional GL_ARB_shader_bit_encoding
Found optional GL_ARB_sample_shading
Found optional GL_ARB_compute_shader
Found optional GL_ARB_gpu_shader5
Found optional GL_EXT_texture_compression_s3tc
Found optional GL_ARB_texture_compression_rgtc
Shading language:        4.50
Maximum texture size:    16384
Maximum texture units:   192
Maximum texture renders: 8

---- Physics ----
Physics: Multi-threaded

---- PathFind ----
PathFind: Multi-threaded

GPUMonitorPlugin::init(): can't initialize GPUMonitor
EnginePlugins::init(): can't initialize "GPUMonitor" plugin
---- Interpreter ----
Version: 2.52

Loading "valley/unigine.cpp" 52ms
Unigine~# render_restart
Loading "valley/locale/unigine.en" dictionary
Loading "core/materials/default/unigine_post.mat" 23 materials 50 shaders 5ms
Loading "core/materials/default/unigine_render.mat" 47 materials 2368 shaders 11ms
Loading "core/materials/default/unigine_mesh.mat" 5 materials 3386 shaders 12ms
Loading "core/materials/default/unigine_mesh_lut.mat" 2 materials 1062 shaders 3ms
Loading "core/materials/default/unigine_mesh_paint.mat" 2 materials 1158 shaders 5ms
Loading "core/materials/default/unigine_mesh_tessellation.mat" 5 materials 3332 shaders 14ms
Loading "core/materials/default/unigine_mesh_tessellation_paint.mat" 2 materials 2276 shaders 8ms
Loading "core/materials/default/unigine_mesh_triplanar.mat" 1 material 112 shaders 1ms
Loading "core/materials/default/unigine_mesh_overlap.mat" 1 material 300 shaders 3ms
Loading "core/materials/default/unigine_mesh_terrain.mat" 1 material 813 shaders 4ms
Loading "core/materials/default/unigine_mesh_layer.mat" 1 material 84 shaders 1ms
Loading "core/materials/default/unigine_mesh_noise.mat" 1 material 106 shaders 1ms
Loading "core/materials/default/unigine_mesh_stem.mat" 2 materials 2180 shaders 13ms
Loading "core/materials/default/unigine_mesh_wire.mat" 1 material 45 shaders 0ms
Loading "core/materials/default/unigine_terrain.mat" 1 material 1980 shaders 7ms
Loading "core/materials/default/unigine_grass.mat" 2 materials 474 shaders 3ms
Loading "core/materials/default/unigine_particles.mat" 1 material 109 shaders 1ms
Loading "core/materials/default/unigine_billboard.mat" 1 material 51 shaders 1ms
Loading "core/materials/default/unigine_billboards.mat" 2 materials 840 shaders 3ms
Loading "core/materials/default/unigine_volume.mat" 6 materials 53 shaders 3ms
Loading "core/materials/default/unigine_gui.mat" 1 material 82 shaders 0ms
Loading "core/materials/default/unigine_water.mat" 1 material 533 shaders 14ms
Loading "core/materials/default/unigine_sky.mat" 1 material 21 shaders 10ms
Loading "core/materials/default/unigine_decal.mat" 1 material 99 shaders 1ms
Loading "core/properties/unigine.prop" 2 properties 0ms
Unigine Valley Benchmark 1.0 (1.0)Unigine~# world_load valley/valley
Loading "valley/valley.cpp" 152ms
Loading "valley/valley.mat" 72 materials 959ms
Loading "valley/sound/sound.prop" 142 properties 2ms
Loading "valley/valley.world" 1912ms
Unigine~# quit
Close "libopenal.so.1"
Close "libGL.so.1"
Memory usage: none
Allocations:  none
Shutdown

I didn't get any (understandable) performance logs, but my fps was around 25 when not recording and 15 whilst recording (max settings). Interestingly the stuff the log says is somewhat wrong.

[QuImUfu]

That benchmark fits into what you can expect from you card (see here) So @MaartenBaert was right and i was wrong, the slow speed in glxgears is caused by you using Ubuntu (unity) and me using Lubuntu (lxde). Most you can do to improve your peformance is doumented here, other than that updating to ubuntu 16.10 and installing the amdgpu-pro driver or the bleeding edge opensource driver might help (a little bit).

Why don't you want to try OpenGL recording? It is easy enough. Just put 'ssr-glinject' in front of what you want to start. (for steam see here.)

[brmbrmcar]

I'll update to 16.10. I don't tend to like OpenGL recording because it can be difficult to do quickly as I use it a lot for different things and gives less flexibility.

[brmbrmcar]

Upgrading only made things worse 😭

[QuImUfu]

The performance got worse? Are you sure? That seems pretty unlikely. What happens if you use newest mesa and drivers from here?

[StripedMonkey]

I'm afraid that the state of AMD drivers is poor to say the least. I had significant decreases in performance when upgrading. Its very possible to have performance regressions.

On Mon, Jan 2, 2017 at 3:49 PM, QuImUfu notifications@github.com wrote:

The performance got worse? Are you sure? That seems pretty unlikely. What happens if you use newest mesa and drivers from here https://launchpad.net/%7Eoibaf/+archive/ubuntu/graphics-drivers?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/MaartenBaert/ssr/issues/518#issuecomment-270018832, or mute the thread https://github.com/notifications/unsubscribe-auth/AHo2ROGSf12Ij8TUkmuBH9CfccO1JXA9ks5rOWLdgaJpZM4LWMpT .

[brmbrmcar]

I have tried those drivers before but couldn't get them to install.

[QuImUfu]

Get them to install? It is as easy as executing (in a Terminal) first this:

sudo add-apt-repository ppa:oibaf/graphics-drivers

Than this:

sudo apt update

And finally this:

sudo apt upgrade

And voila new Driver is installed. (I'd recommend a Restart afterwards)

[brmbrmcar]

I have done that around 1000 times, doesn't change the drivers used.

[QuImUfu]

it does they are getting updated ^^ you wont notice it other than checking the performance games have on you PC or the output of

glxinfo -B

see for the Extended Renderer info version string, using the normal ubuntu sources it is something like 11.2.0 while with the newest driver it is 13.1.0.

[brmbrmcar]

I tried the commend, don't see that version string but here is my output:

name of display: :0
display: :0  screen: 0
direct rendering: Yes
OpenGL vendor string: Advanced Micro Devices, Inc.
OpenGL renderer string: AMD Radeon (TM) RX 460 Graphics
OpenGL core profile version string: 4.5.13453 Core Profile Context
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

OpenGL version string: 4.5.13453 Compatibility Profile Context
OpenGL shading language version string: 4.50
OpenGL context flags: (none)
OpenGL profile mask: compatibility profile

OpenGL ES profile version string: 4.5.13453 Compatibility Profile Context
OpenGL ES profile shading language version string: 4.50

[QuImUfu]

oha, then that is different with the amdgpu-driver and the radeon Driver, too. another way to get this info is:

dpkg -s libgl1-mesa-glx

look again at the Version string.

[brmbrmcar]

Version: 1:13.1~git161230193800.c2799a8~x~padoka0

[QuImUfu]

so you are already using the newest version from the padoka ppa. That should give you the best performance achievable with you Hardware if you don't want to use OpenGL recording or anything else mentioned on the page linked before.

[brmbrmcar]

(This discussion is turning very irrelevant to ssr) I'm pretty sure my GPU can perform better than this. Otherwise I'm getting a refund.

That driver changes nothing whilst recording in ssr though. It's like the GPU doesn't matter.

[QuImUfu]

Look at http://www.phoronix.com/scan.php?page=article&item=amd-rx460-rx470 It is what you can expect in the moment under Linux. The Driver is not completely finished and It has a lot of room for optimization. Under Windows the performance is better, in most games, in the moment. :disappointed: And the performance goes always down a lot, especially when you record the whole screen.

[brmbrmcar]

Hmmm. SuperTuxKart now shows that my driver is too old. My computer should be capable of running it (my system meets the requirements). What seems interesting on those benchmarks is how on some programs it was half-decent, but on others it was terrible. I'll close this, but OpenGL recording produced dodgy quality for me.