GPU usage in SDL

SDL Development
1

I created a Media Player and used SDL to render YUV to the screen.
There are 2 options in SDL: Hardware Rendering and Software Rendering. We can force SDL to use Software Rendering using this flag: SDL_RENDERER_SOFTWARE when creating a renderer.
The problem is that when I don’t use this flag i.e. in the case of Hardware Rendering, CPU usage is higher than when I use this flag to enable software-only Rendering. The opposite should happen, right?
The GPU that SDL is using is: Intel(R) UHD Graphics 630
The processor is: Intel(R) Core™ i7-8700 CPU @ 3.20GHz, 3192 Mhz, 6 Core(s), 12 Logical Processor(s)
The use of SDL is minimal. I update the texture and then Render it.
My application’s max CPU usage in the case of Hardware Rendering is 69% and for Software Rendering is 64%.
The average CPU usage in the case of Hardware Rendering is 58% and in the case of Software Rendering is 55%.
Also, 30% GPU is being used by my application on average when Hardware Rendering is done.
I hypothesize that the CPU is performing much faster than the GPU and the extra CPU resource taken in the case of Hardware Rendering is due to extra to and fro between CPU-GPU. Please clarify if I am wrong and any possible explanation for this anomaly.

2

Since there is no code, I can only make two assumptions:

  1. You are calling the renderer more than necessary (faster than the display refresh rate)
  2. Converting from one pixel format to another is performed (usually to ARGB)
3

Are you definitely including the SDL_RENDERER_PRESENTVSYNC flag?

4

What does this flag do?
And what is the difference between:
SDL_CreateRenderer(m_pWindow, -1, 0) and SDL_CreateRenderer(m_pWindow, -1, SDL_RENDERER_ACCELERATED)

5

It synchronises rendering with display refresh. Without it your frame rate may not be capped which would explain the high GPU usage. Note that there’s no point rendering frames faster than your display refresh rate, since the extra ones will never be seen!

2 Likes
6

I found out the issue. It was unrelated to any of the flags. Actually, my application launched 77 threads on its own( in Software Mode), while in Hardware Mode it launched 82 threads. The 5 more threads were due to d3d9.dll invoked by SDL internally. My machine is 6 cores, i.e. 12 logical processors, so after a point, if we increase the number of threads a lot, context switching takes a toll and the more threads you add the more it decreases the performance of the application. Also the use case was too trivial to use Hardware Rendering, which instead of giving a performance gain, deprecated the performance due to the to and forth between the CPU and GPU i.e. passing the data to GPU. I was giving preprocessed YUV to SDL to just display on the screen, that’s it.

7

77 threads seems… excessive. Are those from your application, or from SDL?

You typically don’t want more threads than you have processors.

1 Like
8

Yes definitely, the number is on the higher side. Most of the threads are used by QT in notification, etc
For a 6-core machine, 12 logical cores, around 20 to 30 threads will improve performance but after that, the performance will decrease due to context switch. Till this threshold, after 12 threads, the application CPU time per thread decreases, but the application gets more CPU time overall. After a certain point, it no longer useful and 77 threads are too much. The application will get way faster if we limit the thread count below 30. For that, the whole FrontEnd will have to be revamped, which is a huge task. The backend only spawns around 10 - 15 threads…
Thanks for your help and quick response!