Re: [hatari-devel] OS X performance problem

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


On Thu, 29 May 2014, Eero Tamminen wrote:

Funnily enough, I notice this problem much more with the powerful
discrete AMD Radeon videochip rather than with the slower Intel
videochip.

This kind of trivial blitting operation is memory bandwidth bound,
not 3D operations bound.  OSX SDL backend apparently does separate
texture upload for each rect update. With the discrete graphics card
the data goes over PCI Express bus, with integrated GPU through
system memory bus.

What PCI-E connection you have to your card, and what Intel processor?


Discrete video:
8x PCIe, AMD Radeon HD 6750M with 1 GB memory

Integrated video:
Intel HD Graphics 3000, 512 MB

Processor:
2.2 GHz Intel Core i7 Mobile
http://ark.intel.com/products/50067/Intel-Core-i7-2720QM-Processor-6M-Cache-up-to-3_30-GHz


Looking at bandwidth for the Hatari window updating at 50 Hz, the window
is 832*576, 4 bytes per pixel, 1916928 bytes per frame. Times 50 and it's ~91 MB/s or 0.089 GB/s. The processor has PCIe v2, so 4 GB/s for 8 lanes, much (44 times) above the needed bandwidth.

But I don't know how Hatari works, maybe it updates the window many many times per refresh and thereby exceeds the bandwidth as you suggest. Or maybe I did the calculations all wrong :)

One more thing I also noticed was a lucky (but poor in this care) guy with a retina display (aka, HI-DPI) where the window needed to have 4x pixel zoom to get to a usable window size. Oh boy that machine didn't stand much a chance to keep full frame rate. But running without Hatari zoom and then using the OS X built-in zoom (control+mousewheel or control+two finger swipe on touchpad) worked well (this zoom does not alter the screen resolution and still pushes all the pixels, but I guess doing it through OpenGL).

--
Anders Eriksson
ae@xxxxxx     http://www.dhs.nu/
ae@xxxxxxxxx  http://www.atari.org/



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/