Creating large DirectDraw surface fails

[mark_k]

WinUAE 3.4.0 (32-bit) on Windows 10 1703 64-bit, AMD FirePro W5100 graphics card.

When the emulation window is quite large, setting Graphics API to DirectDraw fails. Emulation still runs, just the window is blank. There is this log output on changing D3D->DDraw:
DirectDraw Display GUID = NULL
window already open (1533x355 2170x1625)
Created 2176x1625x32 (09C6BC50) surface in DefaultRAM (1)
Created 800x11x32 (09C6BC90) surface in DefaultRAM (1)
DDRAW: 2176x1625 B=0I 32-bit
set_ddraw: 2170x1625@32-bytes
Allocated draw temp buffer (1600*1280*32) = 0EEA0020
DirectDraw Display GUID = NULL
Created 2176x1625x32 (09C6C330) surface in DefaultRAM (1)
Created 800x11x32 (09C6C290) surface in DefaultRAM (1)
DDRAW: 2176x1625 B=0I 32-bit
set_ddraw: 2170x1625@32-bytes
Allocated draw temp buffer (1600*1280*32) = 0EEA6020
NTSC mode lace V=53.7283Hz H=21760.0920Hz (163x405+0) IDX=-1 (<?>) D=0 RTG=0/0
Buffer size (1096*772) Native
IDirectDraw7_CreateSurface (4340x3250,DefaultRAM): 80070057 S=1 F=0007 C=0057 (87)
IDirectDraw7_CreateSurface (4340x3250,VRAM): 88760091 S=1 F=0876 C=0091 (145)
IDirectDraw7_CreateSurface (4340x3250,RAM): 80070057 S=1 F=0007 C=0057 (87)
IDirectDraw7_CreateSurface (4340x3250,NonLocalVRAM): 88760091 S=1 F=0876 C=0091 (145)
DDRAW: failed to create temp surface (4340x3250)
RTGFREQ: 405*53.7283 = 21759.9685 / 53.7 = 405
BEAMCON0=1B88 VTOTAL=0194 HTOTAL=00A2
HSSTOP=0013 HBSTRT=0001 HBSTOP=001E
VSSTOP=000C VBSTRT=0000 VBSTOP=0014
HSSTRT=000A VSSTRT=0006 HCENTER=005B
HSYNCSTART=00A4 HSYNCEND=001D

The 4340×3250 temp surface seems quite large? Windows Desktop is 3840×2160 pixels. If I reduce the size of the emulation window a bit, WinUAE is able to create a DirectDraw surface. I tried various window sizes, and WinUAE could create a 4094×3824×32 surface, but failed with 4098×3824. Maybe a driver limitation on 4096 pixels for the width?

[Toni Wilen]

Do you really expect me to care?

DirectDraw7 is over 15 years old, from era when 4096 was impossibly huge. It is practically unsupported today.

[Mclane]

Firm but fair!

It is a tad old Mark

[mark_k]

Some more info...

Earlier in the log output there is this:
Max hardware surface size: 16384x16384

That seems to be generated by this code in dxwrap.cpp:

d3d = Direct3DCreate9 (D3D9b_SDK_VERSION);
if (d3d) {
	if (SUCCEEDED (IDirect3D9_GetDeviceCaps (d3d, 0, D3DDEVTYPE_HAL, &d3dCaps))) {
		dxcaps.maxwidth = d3dCaps.MaxTextureWidth;
		dxcaps.maxheight = d3dCaps.MaxTextureHeight;
		write_log (_T("Max hardware surface size: %dx%d\n"), dxcaps.maxwidth, dxcaps.maxheight);

So it seems that, at least for this OS version/graphics card/driver, the Direct3D maximum surface size is larger than the maximum DirectDraw surface size.

When graphics API is set to DirectDraw, in win32_scaler.cpp S2X_init() does this (edited for clarity):

temp_width = dst_width * 2;
if (temp_width > dxcaps.maxwidth)
	temp_width = dxcaps.maxwidth;
temp_height = dst_height * 2;
if (temp_height > dxcaps.maxheight)
	temp_height = dxcaps.maxheight;
if (temp_width < dst_width)
	temp_width = dst_width;
if (temp_height < dst_height)
	temp_height = dst_height;

tempsurf = allocsurface (temp_width, temp_height);
if (!tempsurf) {
	write_log (_T("DDRAW: failed to create temp surface (%dx%d)\n"), temp_width, temp_height);
	return false;
}

Are the "*2" dimensions only used when a filter like hq2x is used? If so, could you retry with temp_width = dst_width and temp_height = dst_height if the allocsurface() call fails?

Do you think the maximum size difference between D3D and DirectDraw is a driver bug or deficiency? I could try reporting it to AMD.

[mark_k]

Testing my old 2008-vintage Dell laptop with Windows 10 1511, 128MB Nvidia graphics and 1920×1200 desktop, the largest I can size the emulation window is 3072×2048 pixels. Then in DirectDraw mode WinUAE reports
Created 6144x4096x32 (0990EC08) surface in RAM (3)
and it works. WinUAE reports the max (D3D) hardware surface size as 8192×8192, which is larger than 2× the maximum size I can set the emulation window to.

[meynaf]

DDraw7 is old but unlike D3D it's there on every machine. Perhaps something else (D2D maybe ?) could be used instead.

[Toni Wilen]

D3D size most likely has nothing to do with DD max size.
No one uses old hardware with 4k resolutions

Anyway, DD is unsupported unless it makes sense = old hardware with normal resolution.

[mark_k]

I ran into this issue again today. The problem seems to be that WinUAE always tries to allocate a DirectDraw surface of double the width and height of the output window. But why does it need to do that?

From the log output above, the window size there was 2176x1625 pixels, but the requested surface size was 4340x3250. In Direct3D mode there's no mention of such large/doubled dimensions in the log.

if (d3d) {
	int m = currprefs.gf[picasso_on].gfx_filter_filtermode + 1;
	if (m < scale)
		m = scale;
	temp_width = dst_width * m;
	temp_height = dst_height * m;
} else {
	temp_width = dst_width * 2;		// <--- ???
	if (temp_width > dxcaps.maxwidth)
		temp_width = dxcaps.maxwidth;
	temp_height = dst_height * 2;		// <--- ???
	if (temp_height > dxcaps.maxheight)
	temp_height = dxcaps.maxheight;

Even on a non-4K monitor, 1920x1080 full-screen would mean a requested surface size of 3840x2160. Depending on the graphics card, maybe the "best" memory type allocation might fail (VRAM/RAM) but NonLocalVRAM succeed, meaning it works but with performance worse than it could be.

[honx]

what is this direct draw? i haven't even found a way to activate it in winuae.

[mark_k]

Miscellaneous settings page, under Graphics API.

[Foebane]

Mark, can you explain why you want such a large area?

[mark_k]

I don't, WinUAE tries to allocate a surface of double the window width and height. On my system, that fails if either dimension is >2048, since it seems the maximum size supported for a DirectDraw surface by the driver is 4096x4096. Even for smaller windows on other systems, the surface needing four times the video RAM could (maybe) impact performance. If an older graphics card driver supports max 2048x2048 DD surface size say, any window wider than 1024 pixels would hit that limit.

[Toni Wilen]

Originally Posted by mark_k

I ran into this issue again today. The problem seems to be that WinUAE always tries to allocate a DirectDraw surface of double the width and height of the output window. But why does it need to do that?

It is needed for offset/scaling support. DD can't do clipping very well. D3D does it automatically.

Unfortunately there is no way to query max supported size.

EDIT: Unless 2048 is considered limit, if doubling would make it >2048, don't double and let some garbage appear when moving the display.

[mark_k]

I patched the 3600b3 32-bit EXE to remove the width- and height-doubling. Effectively the lines
temp_width = dst_width * 2; and temp_height = dst_height * 2;
are now just
temp_width = dst_width; and temp_height = dst_height;

https://www.media!fire.com/file/3r7ihh9lnlz1fqr/winuae_3600b3_DD_surf_patch.7z

It seems to work fine. I could use DirectDraw with any size window(*) and in full-screen mode. Playing with the size/position sliders in filter settings seemed to work OK. (Is that what you meant by offset/scaling?)

*: If I make the window dimensions larger than 4096 pixels by moving it partly off-screen and increasing its width/height, then of course surface creation fails. In that case the window is blank and WinUAE prints this over and over in the log: DirectDraw_BlitToPrimary: 80070057 S=1 F=0007 C=0057 (87)

[Toni Wilen]

It does not work fine. I get completely blank window if I use dst_width/dst_height directly, after changing one comparison display is visible but horizontal/vertical scaling and offset works very badly.

EDIT: 2048 "limit" added, at least should enable larger resolutions to work, at least usually.

[mark_k]

Maybe any problems are driver-specific? I only checked with the AMD driver. I'll try to get around to testing in VMWare and VirtualBox (though at least VirtualBox's graphics driver has other issues anyway).

[Toni Wilen]

It shouldn't, unless driver ignores something..

Another update: now it attempts different allocation sizes: 2x size first, then few smaller sizes and finally equal size.

[mark_k]

This is really weird. I tested again using the patched 3600b3 (not latest winuae.exe).

My normal config (same as uploaded in 256-byte FFS thread) has 1-plane highgfx 1024x768 chipset Workbench. With DirectDraw & "no scaling" I can adjust window size to whatever I want, from smallest possible to filling the screen. It works fine.

However, testing an A500-like config running some old DOC demo...

No scaling: Window always all-black regardless of size

Default scaling:
774x597: black, 783x601: OK, 783x597: black, 721x602: OK, 727x601: OK, 722x598: black, 720x601: OK, 720x599: black, 720x600: black, 710x601: OK, 700x601: black, 705x601: black, 707x601: OK, 707x600: black, 706x601: OK
So any window size under ~706x601 pixels is blank.

Fullscreen (TV):
752x574: OK, 706x550: OK, 706x539: OK, 702x540 (or smaller): blank

Integer scaling:
1525x1175: OK, 1534x1152: OK, 1526x1133 (or smaller): blank

Automatic center: any size seems OK
Overscan blanking: any size seems OK

With unmodified WinUAE (subject to 2048-pixel limit in either dimension):
Default scaling: 357x255 (or smaller): blank, 354x260 (or larger): OK
No scaling: any window size OK
Integer scaling: any size OK