| 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/