{"id":190,"date":"2015-02-10T11:01:37","date_gmt":"2015-02-10T16:01:37","guid":{"rendered":"https:\/\/blogs.mathworks.com\/graphics\/?p=190"},"modified":"2015-02-10T11:01:37","modified_gmt":"2015-02-10T16:01:37","slug":"area-scaling","status":"publish","type":"post","link":"https:\/\/blogs.mathworks.com\/graphics\/2015\/02\/10\/area-scaling\/","title":{"rendered":"Area Scaling"},"content":{"rendered":"

Last time<\/a> we looked at how the performance of MATLAB's graphics system scales with the number of data points. Another interesting lens to look at performance scaling with is the way that performance scales with the number of pixels. This can actually show us a lot of interesting details of the balance of the compute and memory systems of our graphics card.<\/p>

When we look at performance scaling through this lens, we'll keep coming up with charts that look something like this:<\/p>

\"\" <\/p>

In this chart, the X axis is the size of the object we're drawing in pixels, and the Y axis is the number of objects we can draw per second. As you can see, I've sketched two curves on the chart. The one labeled \"Pixel Limit\" is a hyperbola which represents a constant number of pixels per second. The other curve is a horizontal line which I've labeled \"Geometry Limit\". These are also known as the \"fill rate\" and \"setup rate\". To a first order approximation, the \"pixel limit\" is a function of the details of the graphics card's memory system, and the \"geometry limit\" is a function of the graphics card's GPU. When we measure performance, we'll find that we always get numbers that are somewhere in the green shaded area. It isn't possible to cross over those two curves. In fact, as we'll see, it is usually pretty hard to get results up in that corner where the two curves meet. Real, measured data usually rounds off the corner between these two curves.<\/p>

So let's collect some measurements and see how real data compares to this sketch. The following chunk of code creates 2,500 triangles and spins them around for 150 frames. It spins them using the hgtransform technique I described in this post<\/a>.<\/p>

ntri = 2500;\r\nnframe = 150;\r\nradii = linspace(0,1,75);\r\nareas = (171.5*radii).^2 * 3 * sqrt(3) \/ 4;\r\nseconds = zeros(1,length(radii));\r\nfor<\/span> j=1:length(radii)\r\n    rad = radii(j);\r\n    cla\r\n    axis square<\/span>\r\n    axis off<\/span>\r\n    xlim([-1 1])\r\n    ylim([-1 1])\r\n    g = hgtransform;\r\n    theta = linspace(0,2*pi,ntri);\r\n    v = [rad*cos(theta)', rad*sin(theta)'];\r\n    x = 1:ntri;\r\n    o1 = floor(ntri\/3);\r\n    o2 = floor(2*ntri\/3);\r\n    f = [x', 1+mod(x+o1,ntri)', 1+mod(x+o2,ntri)'];\r\n    h = patch('Faces'<\/span>,f,'Vertices'<\/span>,v,'FaceVertexCData'<\/span>,x', ...<\/span>\r\n              'FaceColor'<\/span>,'flat'<\/span>,'EdgeColor'<\/span>,'none'<\/span>, ...<\/span>\r\n              'Parent'<\/span>,g);\r\n    drawnow\r\n    t = nan(1,nframe);\r\n    rotmat = makehgtform('zrotate'<\/span>,pi\/20);\r\n    for<\/span> k=1:nframe\r\n        tic\r\n        set(g,'Matrix'<\/span>,get(g,'Matrix'<\/span>) * rotmat);\r\n        drawnow\r\n        t(k) = toc;\r\n        if<\/span> sum(t(1:k)) > 1.5\r\n            break<\/span>\r\n        end<\/span>\r\n    end<\/span>\r\n    seconds(j) = median(t(isfinite(t)));\r\nend<\/span>\r\n<\/pre>\"\" 
Now we can plot these results like so:<\/p>
plot(areas,ntri.\/seconds)\r\nxlabel('Pixels per triangle'<\/span>)\r\nylabel('Triangles per second'<\/span>)\r\n<\/pre>\"\" 
That looks kind of like the curve I sketched, but with a lot of noise for the small triangles. To make things clearer, lets add a \"hyperbolic grid\" with the following function:<\/p>
function<\/span> hyperbolicgrid\r\n  radii = linspace(0,1,75);\r\n  areas = (171.5*radii).^2 * 3 * sqrt(3) \/ 4;\r\n  for<\/span> j=1:8\r\n    line(areas,j*1e9.\/areas,'Color'<\/span>,[.875 .875 .875], ...<\/span>\r\n         'HandleVisibility'<\/span>,'off'<\/span>)\r\n  end<\/span>\r\n<\/pre>
cla\r\nhold on<\/span>\r\nhyperbolicgrid\r\nplot(areas,ntri.\/seconds)\r\nxlabel('Pixels per triangle'<\/span>)\r\nylabel('Triangles per second'<\/span>)\r\nxlim([0 inf])\r\nylim([0 5e5])\r\ntitle('Performance Scaling'<\/span>)\r\n<\/pre>\"\" 
Now we can see that the curve doesn't actually follow one of the hyperbolas. The fill rate for small triangles is actually quite a bit lower than the fill rate for large triangles. This is something that you'll often see in real data. What's happening here is that the graphics card's memory system is very wide. That's part of the trick that makes a graphics card's memory system so fast. When we're drawing small triangles we're not touching enough neighboring pixels to take full advantage of the width of the memory system and so we lose some efficiency. But the details of shape of the pixel limit depend on your graphics card. In this case, I'm using a nVidia Quadro K600<\/a>.<\/p>
opengl info<\/span>\r\n<\/pre>
                          Version: '4.4.0'\r\n                           Vendor: 'NVIDIA Corporation'\r\n                         Renderer: 'Quadro K600\/PCIe\/SSE2'\r\n                   MaxTextureSize: 16384\r\n                           Visual: 'Visual 0x07, (RGBA 32 bits (8 8 8 8), ...'\r\n                         Software: 'false'\r\n        SupportsGraphicsSmoothing: 1\r\n    SupportsDepthPeelTransparency: 1\r\n       SupportsAlignVertexCenters: 1\r\n                       Extensions: {293x1 cell}\r\n               MaxFrameBufferSize: 16384\r\n\r\n<\/pre>
I've run that code above with a number of different settings and we can use these results to see how those settings affect graphics performance. For example, how does the SortMethod property<\/a> affect performance? The default was childorder because those triangles are all at Z=0. When I switch to<\/p>
set(gca,'SortMethod'<\/span>,'depthsort'<\/span>)\r\n<\/pre>
I get a different results.<\/p>
load r2014b_results<\/span>\r\nload depthsort_results<\/span>\r\ncla\r\nhold on<\/span>\r\nhyperbolicgrid\r\nplot(areas,ntri.\/r2014b_results)\r\nplot(areas,ntri.\/depthsort_results)\r\nxlabel('Pixels per triangle'<\/span>)\r\nylabel('Triangles per second'<\/span>)\r\nxlim([0 inf])\r\nylim([0 5e5])\r\nlegend('childorder'<\/span>,'depthsort'<\/span>)\r\ntitle('SortMethod'<\/span>)\r\n<\/pre>\"\" 
You can see that the pixel limit is lower for large triangles, but for small triangles the difference is pretty negligible because of those efficiency issues. You can also see that the depthsort curve is a little unusual because it doesn't \"droop off\" on the left side. This is actually a result of some interesting optimizations that modern graphics cards use to accelerate depthsorting for small triangles.<\/p>
What about software opengl? How does it's performance compare to the hardware?<\/p>
load r2014b_results<\/span>\r\nload sw_results<\/span>\r\ncla\r\nhold on<\/span>\r\nhyperbolicgrid\r\nplot(areas,ntri.\/r2014b_results)\r\nplot(areas,ntri.\/sw_results)\r\nxlabel('Pixels per triangle'<\/span>)\r\nylabel('Triangles per second'<\/span>)\r\nxlim([0 inf])\r\nylim([0 5e5])\r\nlegend('hardware'<\/span>,'software'<\/span>)\r\ntitle('Hardware vs. Software'<\/span>)\r\n<\/pre>\"\" 
We can see that using software opengl affects both limits, and quite substantially. The difference between these two curves will, of course, depend on what type of graphics card your system has. But it does highlight the importance of making sure that your graphics card drivers are up to date so that MATLAB can use hardware OpenGL.<\/p>
And finally, how do different versions of MATLAB compare?<\/p>
load r2014b_results<\/span>\r\nload r2014a_results<\/span>\r\ncla\r\nhold on<\/span>\r\nhyperbolicgrid\r\nplot(areas,ntri.\/r2014b_results)\r\nplot(areas,ntri.\/r2014a_results)\r\nxlabel('Pixels per triangle'<\/span>)\r\nylabel('Triangles per second'<\/span>)\r\nxlim([0 inf])\r\nylim([0 5e5])\r\nlegend('R2014b'<\/span>,'R2014a'<\/span>)\r\ntitle('R2014b vs. R2014a'<\/span>)\r\n<\/pre>\"\" 
That's interesting, isn't it? It turns out that the old graphics system in R2014a actually had a slightly higher pixel limit than the current version. That's because the new one has added features such as GraphicsSmoothing which incur costs per pixel. But the geometry limit of the old version was only 150,000 triangles per second. That's much, much lower than the geometry limit of the new graphics system. That's because the old graphics system was designed when graphics cards had much lower geometry limits and it had some architectural isses feeding geometry to the card quickly. This bottleneck is one of the things we wanted to make sure we fixed when we were designing a new graphics system for MATLAB.<\/p>
I should mention here that there are per-pixel costs in initializing the window and in swapping the completed picture onto the screen. This means that to get the most accurate versions of these curves we should really scale the size of the figure window rather than just the size of the triangles we're drawing into the figure window. But doing that made the code a bit more complex, and it really doesn't have a very large effect in this particular case, so I haven't done that here. But you might find that useful if you try to do this sort of area scaling analysis.<\/p>
As you can see, this view of performance scaling is a powerful one for understanding the bottlenecks in your graphics system. This is often the first technique I try when I'm trying to understand a new graphics performance issue.<\/p>