Testing reliability for PTB - slow increase in graphics timing

1

I setup a new machine for PTB. Ubuntu 18.04, newest PTB release via NeuroDebian. Linux kernel 4.15.0-45-lowlatency, Intel Core i7-8700 6 Core 12MB Cache 3.20GHz/4.6Ghz Turbo CPU, 16 GB RAM, Radeon Pro WX 5100 8GB, Dell Precision 3630 with a good SSD. It's running at 1280x1024x60Hz. I set the cpu-frequency governor to "performance" mode, which helps this machine quite a bit too.


When I run the attached script it shows a bunch of movies at the same time - I used 25 as my setting for a test run. They're a single short video clip with 25 frames (about 200x200 pixels), rotated and color shifted, and the goal is just to challenge the graphics card a bit. Attached is also a plot of the "graphicstime" variable, from a run of this script. I didn't drop any frames on this run, but you can see I came a little close on one of the calls. The graphicstime variable is just the time from before all the calls to push the movie to the buffer to after - so it's really a test of a bunch of calls like this:


                tex=Screen('MakeTexture', window,vars.mov{i});

                Screen('DrawTexture', window, tex,srcRect,dstRect(:,j),angle(j),1,0.2,colorMod(:,mod(j,4)+1));


My goal was to push this harder and harder (more screen calls) until I start getting dropped frames, and then use that as a test script for different machines and for different Ubuntu settings on the machine. That is, does the low latency kernel help, does disabling certain services help, etc. 

Two things I've noticed:

1 - I get dropped frames from time to time, and I can't quite figure out why. I rarely get them with VBLSyncTest, but you can see in this script even in this run where I didn't get a drop, I still got one frame where it came close - it usually takes just a couple ms to call the Screen calls, but once it took about 11 ms but still avoided a miss. I'd like to continue to tweak settings to make this as rare as possible, and would welcome ideas.

2 - The time it takes for the Screen calls slowly grows. I didn't anticipate this. Any intuition for why that happens?

Thanks!
2
I don't have time atm. to answer 1, but i've written about that topic
before in response to similar questions in the past, so i suggest
searching the forum for those answers, some also specific to AMD gpu's
on Linux iirc.

Wrt. 2, a pretty obvious reason should be that your script creates
lots of textures in a loop without ever closing them. I'm pretty sure
PTB printed a performance warning about that at the end of your
script? All those textures and consumed memory would cause slowdown
over time.

Oh and your tic / toc won't benchmark what the gpu does at all, only
the processing time on the graphics drivers main thread for gpu
command generation and submission. Look at DrawingSpeedTest.m's
optional gpumeasure option for how to measure what the gpu does.
Screen('DrawingFinished', window [, dontclear], 1); can be used for
some more crude approximation of used cpu + gpu time, although using
it itself that way would reduce performance.

-mario

On Fri, Feb 1, 2019 at 9:49 PM smithlabvision@... [PSYCHTOOLBOX]
<PSYCHTOOLBOX@yahoogroups.com> wrote:
> I setup a new machine for PTB. Ubuntu 18.04, newest PTB release via NeuroDebian. Linux kernel 4.15.0-45-lowlatency, Intel Core i7-8700 6 Core 12MB Cache 3.20GHz/4.6Ghz Turbo CPU, 16 GB RAM, Radeon Pro WX 5100 8GB, Dell Precision 3630 with a good SSD. It's running at 1280x1024x60Hz. I set the cpu-frequency governor to "performance" mode, which helps this machine quite a bit too.
>
>
> When I run the attached script it shows a bunch of movies at the same time - I used 25 as my setting for a test run. They're a single short video clip with 25 frames (about 200x200 pixels), rotated and color shifted, and the goal is just to challenge the graphics card a bit. Attached is also a plot of the "graphicstime" variable, from a run of this script. I didn't drop any frames on this run, but you can see I came a little close on one of the calls. The graphicstime variable is just the time from before all the calls to push the movie to the buffer to after - so it's really a test of a bunch of calls like this:
>
>
> tex=Screen('MakeTexture', window,vars.mov{i});
>
> Screen('DrawTexture', window, tex,srcRect,dstRect(:,j),angle(j),1,0.2,colorMod(:,mod(j,4)+1));
>
>
> My goal was to push this harder and harder (more screen calls) until I start getting dropped frames, and then use that as a test script for different machines and for different Ubuntu settings on the machine. That is, does the low latency kernel help, does disabling certain services help, etc.
>
> Two things I've noticed:
>
> 1 - I get dropped frames from time to time, and I can't quite figure out why. I rarely get them with VBLSyncTest, but you can see in this script even in this run where I didn't get a drop, I still got one frame where it came close - it usually takes just a couple ms to call the Screen calls, but once it took about 11 ms but still avoided a miss. I'd like to continue to tweak settings to make this as rare as possible, and would welcome ideas.
>
> 2 - The time it takes for the Screen calls slowly grows. I didn't anticipate this. Any intuition for why that happens?
>
> Thanks!
>
>
3
Mario,

Thanks, I should have caught that. I didn't see a PTB warning, but may have just missed it. Clearing the texture solved the slowly increasing problem. I appreciate the help.

I'll look into other timing options from DrawingSpeedTest. But my attempt there was coarse - the goal was to try to queue up enough commands that would slow down the graphics, and push the system harder. Although it doesn't seem to be that difficult for my GPU, which is good. You're saying those DrawTextures calls are non-blocking?

In terms of system performance, fixing my memory leak bug solved a lot, it all seems a lot faster and better now. But going through the forum, I find a mix of various info about performance. Some of it is in threads I started a couple years back, and relates to older Ubuntu versions. It would be great if there was a single location that collated the information. I'd be happy to do some of that. Is there a place currently suggested for that kind of doc, where multiple people could contribute?