Early 2013, Retina MPB, UI performance benchmarking and review

I have your laptop, too, and fixed the lag by turning off the auto GPU switch from the settings. The Intel HD 4000 makes you save battery but just cannot handle the pixels.

What I am surprised about is that you use your rMBP at 1650x1080p ratio. I tried to and the texts becomes blurry, because this is not the best and optimized aspect.

I think it looks better on a high-res cMBP.

 

Could you please run the same tests but on the 'Best for Retina' setting?

 

As we say in Australia: bloody oath.

 

Thanks for the benchmarks! They seem to mirror my own findings I posted in these forums some time ago, that there is not much performance difference between the integrated and the discrete GPU.

Your tests show that:

a) Excel needs some major reworking to its rendering algorithms
b) Apple needs to optimise their PDF rendering engine (assuming you have used Preview)

A few questions: did you conduct your tests with maximised application windows? And - did you use Preview or some other PDF viewer?

 

Another test showed that the integrated GPU is more than capable pushing these pixels but the software wasn't on par yet.

 

I did the steps you recommended and it did not change the GPU clock speed. I know this because I ran a CUDA program called deviceQuery, that comes with the CUDA development samples for OS X.

I renamed the AppleGraphicsPowerManagement.kext to AppleGraphicsPowerManagement1.kext1, cleared the caches by running

sudo rm -rf /System/Library/Caches/com.apple.kext.caches/*

and restarted and I verified the kext was not loaded by running

kextstat |grep AGPM , which returned nothing as expected.

Both times I got the GPU clock rate at 900 MHz for the GPU clock speed.

Output both times.

$ ./deviceQuery
./deviceQuery Starting...

CUDA Device Query (Runtime API) version (CUDART static linking)

Detected 1 CUDA Capable device(s)

Device 0: "GeForce GT 650M"
CUDA Driver Version / Runtime Version 5.0 / 5.0
CUDA Capability Major/Minor version number: 3.0
Total amount of global memory: 1024 MBytes (1073414144 bytes)
( 2) Multiprocessors x (192) CUDA Cores/MP: 384 CUDA Cores
GPU Clock rate: 900 MHz (0.90 GHz)
Memory Clock rate: 2508 Mhz
Memory Bus Width: 128-bit
L2 Cache Size: 262144 bytes
Max Texture Dimension Size (x,y,z) 1D=(65536), 2D=(65536,65536), 3D=(4096,4096,4096)
Max Layered Texture Size (dim) x layers 1D=(16384) x 2048, 2D=(16384,16384) x 2048
Total amount of constant memory: 65536 bytes
Total amount of shared memory per block: 49152 bytes
Total number of registers available per block: 65536
Warp size: 32
Maximum number of threads per multiprocessor: 2048
Maximum number of threads per block: 1024
Maximum sizes of each dimension of a block: 1024 x 1024 x 64
Maximum sizes of each dimension of a grid: 2147483647 x 65535 x 65535
Maximum memory pitch: 2147483647 bytes
Texture alignment: 512 bytes
Concurrent copy and kernel execution: Yes with 1 copy engine(s)
Run time limit on kernels: Yes
Integrated GPU sharing Host Memory: No
Support host page-locked memory mapping: Yes
Alignment requirement for Surfaces: Yes
Device has ECC support: Disabled
Device supports Unified Addressing (UVA): Yes
Device PCI Bus ID / PCI location ID: 1 / 0
Compute Mode:
< Default (multiple host threads can use ::cudaSetDevice() with device simultaneously) >

deviceQuery, CUDA Driver = CUDART, CUDA Driver Version = 5.0, CUDA Runtime Version = 5.0, NumDevs = 1, Device0 = GeForce GT 650M
_______________________________________________________________

The only way to speed up the UI, is to use a non HIDPI resolution; setting the UI scale = 1.0.

That is the only way.

 

The Graphics Power Management probably throttles the GPU in certain cases of high load or high heat.

Times that you aren't stressing the GPU you might not see a performance gain.

I would run some GPU benchmark that stress out the GPU and isolates just the GPU.

Like http://unigine.com/products/heaven/download/

You can also try the GPU benchmarks on xbench, however xbench runs very quickly.

Going off of Quartz Debug, isn't always the best way.

Again the biggest performance gain you are going to see is by using a non HiDPI resolution.

 

I'm waiting till Apple fixes this annoying issue with the HiDPi mode in Retina models.

I have very good framerate scrolling on Facebook with webkit and HD4000 but in some applications is just lags a lot! Resizing windows, Mail.app and so on.. when I'm running Ubuntu on Parallels at 2880x1800 everything runs so smooth! Resizing, scrolling. Why on OS X it doesn't run well as it should?

 

I am running OS X 10.8.2 at 2048x1280 non HiDPI it runs smooth.

 

I'm talking about HiDPi not non-HiDPi.

 

the lag is pretty non-existent in modes where hiDPI is not used.. I'm doing this with "RDM" app, usually 1920x1200 or 2048x1280.
Switch to scaled 1920 (hiDPI) and voíla - lag

 

Retina 13" MBP is no doubt the best laptop ive ever owned.

 

How would I be able to run it like that without the hiDPI I would like to try it at 2048 x 1280

 

I'll upload my working copy (tested with Mountain Lion 10.8.2. latest updates + virusscanned with clamXav)

Code:

http://speedy.sh/k3Dr3/RDM.app

Edit: there are two bugs with it though,
a) if you choose choose some really low setting, e.g 800x600 you might not see the app in the menubar.. just go to settings > display and choose whatever

b) RDM.app needs to quit and re-started when connecting an external monitor. It won't recognise the attached displays automatically in "real-time".

Other than that, it does what it should - letting you change resolutions...

attached the app here also + screenshot of it

 

1920x1200 looks blurry on rMBP. You have any trick to make fonts more defined on 1920x1200?

 

I did a benchmark using

http://unigine.com/products/heaven/download/, which really stresses out the GPU and nicely benchmarks the GPU and out puts the results in a standard format.

I do see an 11% improvement on average, by taking out the AppleGraphicsPowerManagement.kext. That improvement is not enough to justify the potential downside of running warm.

For me the better solution is just using non-hidpi on automatic graphics switching.

I get more screen real estate, no lag, less memory usage, for me better productivity.

 

There are definitely some weird aplication-specific bugs in Apple's Cocoa (UI frameworks). For instance, compare resize performance between Mail and Calendar. On my system, Mail feels rather choppy and Calendar is absolutely smooth - yet the Calendar has arguably the more complex layout. This must have something to do with how the application recompute their UI layout on resize... Probably the best example is App Store. To be honest though, App Store resizing is also laggy on non-retina Macs (just not that extreme).

 

With the last 10.8.3 update the text even at 1920 x 1200 (15" rMBP, of course) becomes noticeably smoother and crisper at the same time. It was fuzzier prior to the update. I'm running mine @ 1920 exclusively. I've never even considered 1440 x 900 because as I did with my old MBP, I find at that scaling the desktop is pretty much unusable (for what I do).

 

Out of curiosity, are you planning benchmarks for comparison?