Speed of gdi vs opengl DirectDrawRenderer

[Jonas Maebe]

Hi,

I had a problem with Majesty Gold HD running at glacial speed on my
machine (quad Core i5 2.9GHz, NVidia GeForce GT 750M 1GB, OS X 10.9.5).
I'm using wine 1.7.35, but I've had similar problems with older wine
versions. It's a DirectDraw7 game that has been partially remastered to
run on modern systems, but still uses DirectDraw7.

This is a common problem on Windows too, but generally can be resolved
by telling the game to use the DirectDraw blitter (instead of blitting
itself). That didn't help on Wine though.

I profiled wine (Instruments time profile) and noticed that most time
was spent in wined3d's convert_r5g6b5_x8r8g8b8. Replacing that routine
with an optimized sse2 version from pixman did not make much of a
difference.

Then I discovered that if I told the game to render to a 16 bit instead
of to a 32 bit surface, wine would let OpenGL handle the colour
conversion. Unfortunately, while this significantly reduced wine's cpu
usage, it by no means made the game any faster. Looking at the OpenGL
Driver Monitor stats, it seems the cpu was simply waiting all the time
on the GPU, probably while it was blitting all of those 1920x1080 images
to the screen. Reducing the resolution to the lowest supported by the
game (800x600) made it slightly faster, but not much.

Next, I added the DirectDrawRenderer registry key and set it to gdi.
Now, while it's still slow at 1920x1080, the game runs much faster at
800x600 and even still at 1024x768. Profiling the gdi renderer shows
that it has way higher cpu usage than the OpenGL renderer (virtually all
in convert_to_8888), but it seems that for some reason it has causes
much less traffic to the GPU.

The wiki's wording suggests the gdi renderer is deprecated though. Does
that mean this qualifies as a bug in the OpenGL renderer (maybe it tries
to update the screen more often than necessary, saturating the bus that
way?), and are there any things I can try to narrow down why the gdi
renderer is so much faster? I didn't immediately see where it blits
things actually to the screen.

Thanks,


Jonas

[Ken Thomases]

On Feb 19, 2015, at 2:12 PM, Jonas Maebe <jonas.maebe(a)elis.ugent.be> wrote:
> I had a problem with Majesty Gold HD running at glacial speed on my
> machine (quad Core i5 2.9GHz, NVidia GeForce GT 750M 1GB, OS X 10.9.5).
> … are there any things I can try to narrow down why the gdi
> renderer is so much faster? I didn't immediately see where it blits
> things actually to the screen.

GDI32 rendering goes to an in-main-memory window surface (backbuffer).  USER32 tells the Mac driver to flush that window surface to screen at certain points, but the Mac driver implements that asynchronously.  Basically, the flush operation queues a request to the Cocoa main thread to call [window.contentView setNeedsDisplayInRect:theDirtyRect].  The Wine thread is allowed to go on as soon as that request is queued.  It doesn't wait for the view to be actually marked as needing display, let alone for Cocoa to get around to actually displaying it.

When the Cocoa main thread does go to display the view, it locks the window surface and creates CGImages from its data and draws those to the window.  Then it unlocks the surface.  But those draw operations are not flushed immediately to screen while that lock is held.  So, the surface lock should not be held while Cocoa waits for the GPU or the Window Server refresh cycle.

Basically, GDI32 and USER32 can overdrive the drawing loop without having to wait for the GPU or the refresh cycle.

See if the game has a setting for disabling vsync.  If it doesn't, try setting:

[HKEY_CURRENT_USER\Software\Wine\Mac Driver]
"AllowVerticalSync"="n"

Does that help?


Others would understand better why the OpenGL renderer is slow.  Does your system support 16-bit display modes?  Is the game/wined3d actually switching it into one of those?

-Ken

[Jonas Maebe]

On 19/02/15 21:45, Ken Thomases wrote:
[snip]
> Basically, GDI32 and USER32 can overdrive the drawing loop without having to wait for the GPU or the refresh cycle.

Great, thanks for the explanation! That's indeed exactly what this game
seems to need. It generates and tries to display a new screen per game
step, but there's no need to display them all.
> See if the game has a setting for disabling vsync.  If it doesn't, try setting:
>
> [HKEY_CURRENT_USER\Software\Wine\Mac Driver]
> "AllowVerticalSync"="n"
>
> Does that help?

The game has an option to disable it, but just to make sure I also added
the registry key. It didn't make a (noticeable) difference.
> Others would understand better why the OpenGL renderer is slow.  Does your system support 16-bit display modes?

I don't know:

trace:wgl:init_pixel_formats renderer_properties 0:
trace:wgl:dump_renderer Renderer ID: 0x00022700
trace:wgl:dump_renderer Buffer modes:
trace:wgl:dump_renderer     Monoscopic:    YES
trace:wgl:dump_renderer     Stereoscopic:  NO
trace:wgl:dump_renderer     Single buffer: YES
trace:wgl:dump_renderer     Double buffer: YES
trace:wgl:dump_renderer Color buffer modes:
trace:wgl:dump_renderer     Color size 15, Alpha size 0
trace:wgl:dump_renderer     Color size 32, Alpha size 8
trace:wgl:dump_renderer     Color size 64, Alpha size 16, Float
trace:wgl:dump_renderer     Color size 128, Alpha size 32, Float
trace:wgl:dump_renderer Accumulation buffer sizes: { 128, }
trace:wgl:dump_renderer Depth buffer sizes: { 0, 16, 24, }
trace:wgl:dump_renderer Stencil buffer sizes: { 0, 8, }
trace:wgl:dump_renderer Max. Auxiliary Buffers: 2
trace:wgl:dump_renderer Max. Sample Buffers: 1
trace:wgl:dump_renderer Max. Samples: 8
trace:wgl:dump_renderer Offscreen: NO
trace:wgl:dump_renderer Accelerated: YES
trace:wgl:dump_renderer Backing store: YES
trace:wgl:dump_renderer Window: YES
trace:wgl:dump_renderer Online: YES
trace:d3d:wined3d_adapter_init_fb_cfgs iPixelFormat=1,

There are also several enumerated pixel formats with 16 as "color depth"
(but still 32 as "color bits", so I'm not sure which one counts):
trace:wgl:enum_renderer_pixel_formats w/p/a 1/1/1 col 32/8
dp/stn/ac/ax/b/db/str 16/0/0/0/0/0/0 samp 0/0 0000000000000804f remapped
from w/p/a 1/0/1 col 15/0 dp/stn/ac/ax/b/db/str 16/0/0/0/0/0/0 samp 0/0
0000000000000801d
trace:wgl:enum_renderer_pixel_formats w/p/a 1/1/1 col 32/8
dp/stn/ac/ax/b/db/str 16/0/0/0/0/0/0 samp 1/2 0000000140000804f remapped
from w/p/a 1/0/1 col 15/0 dp/stn/ac/ax/b/db/str 16/0/0/0/0/0/0 samp 1/2
0000000140000801d
trace:wgl:enum_renderer_pixel_formats w/p/a 1/1/1 col 32/8
dp/stn/ac/ax/b/db/str 16/0/0/0/0/0/0 samp 1/4 0000000240000804f remapped
from w/p/a 1/0/1 col 15/0 dp/stn/ac/ax/b/db/str 16/0/0/0/0/0/0 samp 1/4
0000000240000801d
trace:wgl:enum_renderer_pixel_formats w/p/a 1/1/1 col 32/8
dp/stn/ac/ax/b/db/str 16/0/0/0/0/0/0 samp 1/8 0000000440000804f remapped
from w/p/a 1/0/1 col 15/0 dp/stn/ac/ax/b/db/str 16/0/0/0/0/0/0 samp 1/8
0000000440000801d
trace:wgl:enum_renderer_pixel_formats w/p/a 1/1/1 col 32/8
dp/stn/ac/ax/b/db/str 16/0/0/0/0/0/0 samp 0/0 0000000000000804f remapped
from w/p/a 1/1/1 col 15/0 dp/stn/ac/ax/b/db/str 16/0/0/0/0/0/0 samp 0/0
0000000000000801f (duplicate)

All of the "col" values are either 32, 64f or 128f.
> Is the game/wined3d actually switching it into one of those?

I'm not sure:

trace:d3d:init_format_fbo_compat_info Checking if format
WINED3DFMT_B5G6R5_UNORM is supported as FBO color attachment...
trace:d3d:check_fbo_compat Framebuffer format check call ok utils.c / 1344
trace:d3d:check_fbo_compat Format WINED3DFMT_B5G6R5_UNORM is supported
as FBO color attachment.
trace:d3d:check_fbo_compat RB attachment call ok utils.c / 1420
trace:d3d:check_fbo_compat Post-pixelshader blending check call ok
utils.c / 1468
trace:d3d:check_fbo_compat Format supports post-pixelshader blending.
trace:d3d:check_fbo_compat Color output: 0xff7b0000
trace:d3d:check_fbo_compat RB cleanup call ok utils.c / 1500

...

trace:d3d:wined3d_set_adapter_display_mode wined3d 0x11fe50, adapter_idx
0, mode 0x33fcfc.
trace:d3d:wined3d_set_adapter_display_mode mode 1024x768(a)0
WINED3DFMT_B5G6R5_UNORM 0.
...
trace:d3d:wined3d_get_adapter_display_mode wined3d 0x11fe50, adapter_idx
0, display_mode 0x33fc08, rotation 0x0.
warn:d3d:wined3d_get_adapter_display_mode Overriding format
WINED3DFMT_B8G8R8X8_UNORM with stored format WINED3DFMT_B5G6R5_UNORM.
trace:d3d:wined3d_get_adapter_display_mode Returning 1024x768(a)60
WINED3DFMT_B5G6R5_UNORM 0x1.
...
trace:d3d:swapchain_update_render_to_fbo Single buffered rendering.
trace:d3d:context_create swapchain 0x161238, target 0x1618f0, window
0x3003a.
trace:d3d:context_choose_pixel_format device 0x131748, dc 0x90033,
color_format WINED3DFMT_B5G6R5_UNORM, ds_format
WINED3DFMT_D24_UNORM_S8_UINT, aux_buffers 0, find_compatible 0.
trace:d3d:getColorBits format WINED3DFMT_B5G6R5_UNORM.
trace:d3d:getColorBits Returning red: 5, green: 6, blue: 5, alpha: 0,
total: 16 for format WINED3DFMT_B5G6R5_UNORM.
trace:d3d:getDepthStencilBits format WINED3DFMT_D24_UNORM_S8_UINT.
trace:d3d:getDepthStencilBits Returning depthSize: 24 and stencilSize: 8
for format WINED3DFMT_D24_UNORM_S8_UINT.
trace:d3d:context_choose_pixel_format Found iPixelFormat=69 for
ColorFormat=WINED3DFMT_B5G6R5_UNORM,
DepthStencilFormat=WINED3DFMT_D24_UNORM_S8_UINT
trace:d3d:context_enter Entering context 0x141f68, level 1.
trace:d3d:device_context_add Adding context 0x141f68.
trace:d3d:context_set_current Switching to D3D context 0x141f68, GL
context 0x31001, device context 0x90033.


Jonas

[Ken Thomases]

On Feb 20, 2015, at 4:16 PM, Jonas Maebe <jonas.maebe(a)elis.ugent.be> wrote:
> On 19/02/15 21:45, Ken Thomases wrote:
> [snip]
> > Basically, GDI32 and USER32 can overdrive the drawing loop without having to wait for the GPU or the refresh cycle.
>
> Great, thanks for the explanation! That's indeed exactly what this game
> seems to need. It generates and tries to display a new screen per game
> step, but there's no need to display them all.

If that's the case, then maybe there are unnecessary calls to glFlush() or even glFinish() that can/should be skipped.

If Stefan has the inclination and the opportunity, I'd wait for him to get a chance to analyze its behavior.

Thanks for the log snippets in response to my questions about display modes, but I no longer think that's relevant.

-Ken

[Ken Thomases]

On Feb 20, 2015, at 5:49 PM, Ken Thomases <ken(a)codeweavers.com> wrote:
> On Feb 20, 2015, at 4:16 PM, Jonas Maebe <jonas.maebe(a)elis.ugent.be> wrote:
> > On 19/02/15 21:45, Ken Thomases wrote:
> > [snip]
> > > Basically, GDI32 and USER32 can overdrive the drawing loop without having to wait for the GPU or the refresh cycle.
> >
> > Great, thanks for the explanation! That's indeed exactly what this game
> > seems to need. It generates and tries to display a new screen per game
> > step, but there's no need to display them all.
>
> If that's the case, then maybe there are unnecessary calls to glFlush() or even glFinish() that can/should be skipped.

There is one more thing you could try along these lines, but it's a long shot.  Try setting:

[HKEY_CURRENT_USER\Software\Wine\Mac Driver]
"SkipSingleBufferFlushes"="y"

-Ken

[Henri Verbeet]

It could very well be the case that this happens because we don't
properly implement ddraw asynchronous blits. The gdi renderer might
mitigate that with the behavior Ken described. If that's the case, the
csmt patchset would in theory allow this to be fixed, although I
suspect it currently doesn't.

[Stefan Dösinger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Am 2015-02-19 um 21:12 schrieb Jonas Maebe:
> I profiled wine (Instruments time profile) and noticed that most 
> time was spent in wined3d's convert_r5g6b5_x8r8g8b8. Replacing
> that routine with an optimized sse2 version from pixman did not
> make much of a difference.
> Is there a demo version of this game somewhere? I am reworking the d3d
> blitting code at the moment, and it seems like this would be an
> interesting game to look at.

If the game does video memory r5g6b5 to video memory x8r8g8b8 blits
then we should be able to do this on the GPU. It's quite possible
however that this is either a system memory to system memory blit, in
which case doing this in the CPU is the correct thing. If the game
uploads from a system memory r5g6b5 to a video memory x8r8g8b8 texture
then we can in theory let OpenGL do the work via glTexSubImage2D, but
it'll mostly mean that OpenGL converts the data using the CPU before
sending it to the GPU.

This may be a game bug - you say the game has troubles on Windows too.
It may also be a bug in our modesetting code, in the sense that the
game sets the display format to r5g6b5, but we stay at x8r8g8b8
because X11 (and I think OSX, Ken correct me please) can't switch the
color depth. Ideally OpenGL takes care of the resulting conversion,
but that's not always the case.

Cheers,
Stefan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBAgAGBQJU5vwjAAoJEN0/YqbEcdMwmJ8P/2R+emEQmVNZkcrODAFKsHSy
cfjl11FXowNzf7hE9HM4tPcZyC9rOL+wDRaB79MXaybtQl3iqTJS+hp+F4Dqvo5j
qL/sTonGeD/GYejv7sTLzAUfEpfCAFDCmKMamPmX3hYHcXoZqnSaXHcPsEzvo0Tp
ll3kviweQ7PzqIG8EwU4ewge9ySKlBQFI/27TedbnXynmDjLqv4lSBUtRYyPCw+W
3i6Wv5iIG1M9Uh0OqehOXw/vF3b3ztulShF9gOu2GvCGOaOMzAyeDVtrKiaaNgP1
i2NN0wccmfRhwxu9o8zVdV8RB7MzZyjueUiHV4VTw/VRXJo+w5PnGOpQQkbtWt38
C09GaUKKGsvJJNTu9egb7v+lGJK9+oFpbYR9fQBILCl9OzlPU45TUoe6UCQPwnF6
vXTW6pwxeSPwybFbR0PYHZU7eQTiRClw1U8YZUeayI0lZwnuO9lR+tEIAgowe74S
tyBPh+N1ox3vxPMuRbcR80ylTIypjsaTvAS/ExQ9J7SKLbO6QrINUDINv/WiwQ/C
NdYNh472x34mk2FtJoF2Vw7SSq88kee+2s4vBQ1mr6Jvgkl3wXBfxWOYPUj0cQC4
rFbDWqUqAliSYOmuQA+ATD7dPTA+j1JwRjrMD5iy+r7aESfgtQwWULxHGzTqhKfu
u+Idj1N/57pwuCDim6XY
=uDdp
-----END PGP SIGNATURE-----

[Jonas Maebe]

On 20/02/15 10:19, Stefan Dösinger wrote:
> Am 2015-02-19 um 21:12 schrieb Jonas Maebe:
> > I profiled wine (Instruments time profile) and noticed that most
> >  time was spent in wined3d's convert_r5g6b5_x8r8g8b8. Replacing 
> > that routine with an optimized sse2 version from pixman did not 
> > make much of a difference.
> > Is there a demo version of this game somewhere? I am reworking the
> > d3d blitting code at the moment, and it seems like this would be
> > an interesting game to look at.

There's a demo of the non-HD version of the game available at
http://www.cyberlore.com/Majesty/demo.htm . At first sight it exhibits
the same symptoms (OpenGL driver monitor shows a lot of cpu waiting
time on the GPU). It's hard to verify though, because the demo doesn't
allow you to change the in-game speed, unlike the full game (so I
can't test whether it would go faster if I'd yank up the game speed).

I have actually 2 copies of Majesty Gold HD (one on Gamersgate and one
on GOG), but since I've downloaded it already from both I don't think
I can gift you one. It's currently also on sale at GOG till Tuesday,
so if Codeweavers has $4,99/€4,49 to spare... :)
(http://www.gog.com/game/majesty_gold_hd )
> If the game does video memory r5g6b5 to video memory x8r8g8b8
> blits then we should be able to do this on the GPU. It's quite
> possible however that this is either a system memory to system
> memory blit, in which case doing this in the CPU is the correct
> thing. If the game uploads from a system memory r5g6b5 to a video
> memory x8r8g8b8 texture then we can in theory let OpenGL do the
> work via glTexSubImage2D, but it'll mostly mean that OpenGL
> converts the data using the CPU before sending it to the GPU.
>
> This may be a game bug - you say the game has troubles on Windows
> too.

Yes. The most common workarounds for slowness under Windows appear to be
a) tell the game to use a 32 bit rather than a 16 bit mode (doesn't
help in my case for Wine). Note that while the demo contains a
gameopt.ini file in which you can change the depth to 32, it will just
crash it. Changing this works fine in the full Majesty Gold HD version
b) tell the game to use DirectDraw for bliting rather than its
internal routines (is already the default) (-useddblit command line
parameter -- don't know whether it does anything for the demo)
> It may also be a bug in our modesetting code, in the sense that
> the game sets the display format to r5g6b5, but we stay at
> x8r8g8b8 because X11 (and I think OSX, Ken correct me please) can't
> switch the color depth. Ideally OpenGL takes care of the resulting
> conversion, but that's not always the case.

If you need any more/specific trace output other than what I pasted in
my reply to Ken, let me know!

Thanks,


Jonas

[Ken Thomases]

On Feb 19, 2015, at 2:12 PM, Jonas Maebe <jonas.maebe(a)elis.ugent.be> wrote:
> I had a problem with Majesty Gold HD running at glacial speed on my
> machine (quad Core i5 2.9GHz, NVidia GeForce GT 750M 1GB, OS X 10.9.5).
> The wiki's wording suggests the gdi renderer is deprecated though. Does
> that mean this qualifies as a bug in the OpenGL renderer …?

For what it's worth, I think this does qualify for a bug report.  It will be easier to keep track of there.

-Ken

[Jonas Maebe]

On 21/02/15 00:46, Ken Thomases wrote:
> On Feb 19, 2015, at 2:12 PM, Jonas Maebe <jonas.maebe(a)elis.ugent.be> wrote:
> > I had a problem with Majesty Gold HD running at glacial speed on my
> > machine (quad Core i5 2.9GHz, NVidia GeForce GT 750M 1GB, OS X 10.9.5).
> > The wiki's wording suggests the gdi renderer is deprecated though. Does
> > that mean this qualifies as a bug in the OpenGL renderer …?
>
> For what it's worth, I think this does qualify for a bug report.  It will be easier to keep track of there.

I finally got around to that, after figuring out how to solve it (using 
a hack: limiting the glFlush calls to 60Hz): 
https://bugs.winehq.org/show_bug.cgi?id=39421

BTW: how come there is no ddraw or directdraw or similar component on 
bugzilla? Is there another component I can use?


Jonas

[Stefan Dösinger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Am 2015-10-11 um 19:22 schrieb Jonas Maebe:
> BTW: how come there is no ddraw or directdraw or similar component
> on bugzilla? Is there another component I can use?
> d3d
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2

iQIcBAEBCAAGBQJWGqYnAAoJEN0/YqbEcdMwGMYQAIZq0z99r4/jbT6uOHmmrOqX
wWlGkL4CMX+65vnWwyzky9AT+Ewy/QvDdYNbTZ2ETlbNIAojk8EepO+dOOU7618x
fuRdve5uvBUKmMUxF+CbsgHZxhGdBC00WFiBuM7UTOdGpZy2dF4HIgbUCdzqMEIa
tz8Njc9iRI/MAfcrZKUwc+YM+koi0F5vngQrt+fXo7OIZ1IUunVJrjleZszfWRgR
o8Ajtq0CsyZZ6pMIKN4wrekKzeXqelsP6aQf1Eb/wnju1/2Vz2WmGiSbo2vZ2Ld4
HYOXMC9Pxq1eAP2g8fQWaNewZkVaGJCF3SU0aWS7eDJi8ZFUIysuDqhU8K1f6tVF
/KQ7beb9ssH5kNy3uipigfEMNiEb36WLiAjUQJNRZhV7EW6Lf/PsuMAKRvDkbWb0
xRWfu/ngK+NBGKdWYR5NRzNEzNkvNRWGlCeZcpa4X/AUW1/98Li4pZW6DLhuMsEF
ydjAr5NpzoExiINKL3LB7g39xk4VpA1W55IWYPYm2cmwsE6yrJGrkC0vvQCU6bGS
K/dDrcu91TyP/x+01rSBAmX+tYlpeK81Z9djzeS4fFtMzJu5yi1lOpCfruRLwXz9
ElwDvWdkKkqSKs4vWa/TBYv7UptouYeLUDXMi9EvBalNGA1tKKmq4qR/VD/njszi
64cV1SND2spz89k15S6g
=Bc4I
-----END PGP SIGNATURE-----