[Touch Pro, Fuze General] Da_G:
So i've been trying for a good 2 weeks to figure out the exact reason behind why the graphics results can vary so much in spb benchmark, and I think i've got it figured out.

In a nutshell: The hardware acceleration provided through overlay support sucks!

Why do I say that?

If you load up a combination of drivers that results in the device not being able to create an overlay layer (see the output from debug log below) - performance is markedly increased as a result of falling back to 'slower' rendering methods.

Here's what the debug log reports when performance is low:

++gMDPCtrl[mdpImg.layer].stMDPImg.imgType = 3
++gMDPCtrl[mdpImg.layer].stMDPImg.bmy_addr = 32a800
++gMDPCtrl[mdpImg.layer].stMDPImg.cbcr_addr = 0
++gMDPCtrl[mdpImg.layer].stMDPImg.width = 1e0
++gMDPCtrl[mdpImg.layer].stMDPImg.cwin.x1 = 0
++gMDPCtrl[mdpImg.layer].stMDPImg.cwin.x2 = 1df
++gMDPCtrl[mdpImg.layer].stMDPImg.cwin.y1 = 0
++gMDPCtrl[mdpImg.layer].stMDPImg.cwin.y2 = 27f
++gMDPCtrl[mdpImg.layer].stMDPImg.lcd_x = 0
++gMDPCtrl[mdpImg.layer].stMDPImg.lcd_y = 0
++gMDPCtrl[mdpImg.layer].stMDPImg.mdpOp = 380
++gMDPCtrl[mdpImg.layer].stMDPImg.tpVal = 1002
++gMDPCtrl[mdpImg.layer].stMDPImg.alpha = 0
++gMDPCtrl[mdpImg.layer].stMDPImg.layer = 9
++gMDPCtrl[mdpImg.layer].stMDPImg.ascale.width = 1e0
++gMDPCtrl[mdpImg.layer].stMDPImg.ascale.height = 280
-Display_UpdateOverlay

Note the lack of any errors.. overlay was successfully created, used, and destroyed. In this situation performance will be poor.

Now compare to a differing HTCmdp.dll which does not correctly create the overlay layer:

+gMDPCtrl[mdpImg.layer].stMDPImg.imgType = 3
+gMDPCtrl[mdpImg.layer].stMDPImg.bmy_addr = 32a800
+gMDPCtrl[mdpImg.layer].stMDPImg.cbcr_addr = 0
+gMDPCtrl[mdpImg.layer].stMDPImg.width = 1e0
+gMDPCtrl[mdpImg.layer].stMDPImg.cwin.x1 = 0
+gMDPCtrl[mdpImg.layer].stMDPImg.cwin.x2 = 1df
+gMDPCtrl[mdpImg.layer].stMDPImg.cwin.y1 = 0
+gMDPCtrl[mdpImg.layer].stMDPImg.cwin.y2 = 27f
+gMDPCtrl[mdpImg.layer].stMDPImg.lcd_x = 0
+gMDPCtrl[mdpImg.layer].stMDPImg.lcd_y = 0
+gMDPCtrl[mdpImg.layer].stMDPImg.mdpOp = 380
+gMDPCtrl[mdpImg.layer].stMDPImg.tpVal = 1002
+gMDPCtrl[mdpImg.layer].stMDPImg.alpha = 0
+gMDPCtrl[mdpImg.layer].stMDPImg.layer = 9
+gMDPCtrl[mdpImg.layer].stMDPImg.ascale.width = 1e0
+gMDPCtrl[mdpImg.layer].stMDPImg.ascale.height = 280
02:20:27 [D:DISP] DrvEscape:LCD_OVERLAY_ENABLE...
+Display_CreateOverlay create overlay failed

As you can see, this driver fails to properly create the overlay, so rendering falls back an older method, most likely GDI.. apparently the acceleration for GDI is significantly better than in overlay mode.. when overlay is successfully created graphics scores are around 8ms/38ms/33ms, give or take a few ms depending on the time of day, cosmic rays, etc. When overlay fails to create, graphics scores are around 6ms/25ms/6ms.. sometimes even as low as 2ms/24ms/5ms..

I have not done any tests outside of spb benchmark, so curious how this effects video playback. generally any hardware acceleration for video is done through overlay, so not having a functioning overlay might hurt that.. or overlay support might be so bad that gdi is better anyway..

WMP has registry keys to choose which render method it's using, so more testing w/that is probably in order.. but im sick, so i'm going to bed :)

Relevant keys are:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MediaPlayer\Preferences]
"RenderMethod"=dword:2
"RenderGDI" ; unknown default

Not much documentation for WMP in that arena, but that's what I found poking around.. anyway, curious behavior..