Input latency measurements (and D3D11)

[Toni Wilen]

Did you use updated vertex shader? (post #49). If yes, then someone needs to find fixed shader/projection calculations. I don't want to know.

[Dr.Venom]

Originally Posted by Toni Wilen

Did you use updated vertex shader? (post #49).

Unfortunately makes no difference.. (i've changed it in the file "_winuae.vs"). Does 1:1 mapping work for you in single line mode? I've tested this now on my LCD with NVidia GTX1070.

Originally Posted by Toni Wilen

If yes, then someone needs to find fixed shader/projection calculations. I don't want to know.

I don't think I'll be able to be of much help with that . Sadly without 1:1 mapping this is not going to work for CRT setups.

[Toni Wilen]

That was the whole point of finding Direct3D11 2D example that is usable. I knew it wasn't going to be that simple because most examples are not designed for perfect 1:1 pixel mapping and 2D examples are rare.

[Dr.Venom]

Originally Posted by Toni Wilen

That was the whole point of finding Direct3D11 2D example that is usable. I knew it wasn't going to be that simple because most examples are not designed for perfect 1:1 pixel mapping and 2D examples are rare.

Yeah I understand. Is there a reason for you to think we should be looking for the issue in the shader / projection calculation (and not something else), since double line mode seem to be fine?

[mark_k]

Currently you use DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL. On Windows 10 DXGI_SWAP_EFFECT_FLIP_DISCARD could be more optimal?

That's assuming you don't want to experiment with using dirty rectangles to optimise rendering (telling DXGI which parts of the buffer have changed, which could make use over RDP better/feasible).

[Toni Wilen]

RTG needs partial updates. Currently it flickers because it is not yet handled properly.

[Dr.Venom]

Toni, could the following be causing the "blurriness" issue in single line mode?

Half-Pixel Offset in DirectX 11


Some quotes:

But it turns out that in Direct3D 10/11, the value of SV_Target for first pixels on the screen is not (0, 0), (1, 0), but (0.5, 0.5), (1.5, 0.5)!

Therefore to sample texture based on pixel position, it's enought to divide it by screen resolution.

Texture2D g_Texture : register(t0);
SamplerState g_SamplerState : register(s0);

cbuffer : register(b0) {
    float2 g_ScreenResolution;
};

void PixelShader(float2 Position : SV_Position, out float4 Color : SV_Target)
{
    Color = g_Texture.Sample(g_SamplerState, Position / g_ScreenResolution);
}

[Toni Wilen]

Explanation makes sense but the shader fix does not (at least not for me). Not enough information.

[Dr.Venom]

With regards to the half pixel offset possibly being the culprit in single line mode; looking at the corsair tekst in single line mode enlarged (fourth picture in post #60 ), it seems that it may be interpolated / sampled just between the lines. I.e. the vertical white stripes of the letters seem correct, but the horizontal white pixels / lines in the "corsair" text are all grey.

Is the input to the shader by any chance an odd number of lines in single line mode, but an even number of lines in double-line-mode? Just guessing as to what is happening in single line mode, and why it seems to be correct in double line mode..

[Dr.Venom]

Originally Posted by mark_k

Just updated AMD graphics driver to 17.Q4 from here. Now in D3D11 mode CPU% reads about 650%, FPS about 9.

I'll try a clean driver install to see if that fixes it. If not it looks like AMD broke something since 17.Q3.1.

Not sure if you still have this issue, but I've just tested latest winuae beta of today with AMD RX480 card and latest driver (Crimson ReLive Edition 17.10.3, 10/27/2017, W10 64-bit) and I'm not experiencing any slowdown, it's running 50fps with CPU reading near 0%.

[Dr.Venom]

I created a simple test picture with dpaint that shows a white single pixel line square and cross on black background. (Upped to the zone as a bootable adf "testpicture.zip").

This may be helpful to more easily check whether there are display irregularities (maybe also useful when implementing integer scaling modes..)

It clearly shows the difference between double line mode and single line mode. Double line mode is showing the picture perfectly.

In single line mode all horizontal lines are grey (vertical lines are correct). This strongly suggests there's a half pixel offset in the y direction, where color is sampled as an average of white and black, resulting in the grey lines.

From what I read D3D11 already applies the half-pixel offset (that was explicitly needed in d3d9) in the background, so it's not needed for D3D10 and 11. You don't by any chance have a half-pixel offset left over somewhere (from d3d9 code) in the display code?

[Toni Wilen]

As I already said: all the maths is from that 2d d3d11 example. I don't want to know how matrixes and shaders exactly work, I want ready made perfect example solution.

EDIT: and it is not specific to vertical, odd width or height causes it, and some other "not exactly aligned" values.

[mark_k]

Is there any change if you vary window size slightly? I remember seeing extra/missing lines in D3D9 mode when window width/height is odd.

Adding an option to use the WARP renderer for D3D11 could be useful. Both to compare with how hardware drivers render, but also because it allows D3D11 mode to be used anywhere, e.g. with no graphics driver installed, in a VM which doesn't support hardware 3D acceleration, on some old PC with pre-DX9-class graphics card etc. I wonder how non-vsync/with-tearing would work with WARP...
Edit: The WARP renderer might be used by default if there's no suitable hardware/driver. But a manual option would be good for testing.

[mark_k]

There are two ways to make WinUAE use the WARP device at the moment.

1. Install the Windows SDK then run dxcpl.exe. Click Edit List... and add the WinUAE executable to the list. Check the Force WARP box and click Apply.

2. If you don't want to install the Windows SDK, you can patch WinUAE to use the WARP device. Note that these details are for the current unofficial-beta 32-bit winuae.exe. Official betas are built with different optimisation level so they may not apply there.

This patch effectively changes the source code line
pD3D11CreateDevice(NULL, D3D_DRIVER_TYPE_HARDWARE, NULL, cdflags, levels, 2, D3D11_SDK_VERSION, &d3d->m_device, NULL, &d3d->m_deviceContext);
to
pD3D11CreateDevice(NULL, D3D_DRIVER_TYPE_WARP, NULL, cdflags, levels, 2, D3D11_SDK_VERSION, &d3d->m_device, NULL, &d3d->m_deviceContext);

Using a binary file editor, load your backup/renamed winuae.exe into it. Search for the byte sequence
6A 20 6A 00 6A 01 6A 00
Replace the 01 with 05 so it becomes
6A 20 6A 00 6A 05 6A 00


Both methods seemed to work OK for me. Windowed and full-window modes work (no tearing, sadly). Full-screen doesn't. Maybe that's because WinUAE enumerates only physical hardware adapters for full-screen mode??? Or perhaps the WARP device just doesn't support full-screen mode.


Dr.Venom: Would be interested to hear whether you see the same issues with the WARP device...

[Dr.Venom]

Originally Posted by mark_k

Dr.Venom: Would be interested to hear whether you see the same issues with the WARP device...

I patched the winuae.exe according to your suggestion with a binary editor. Checked whether full-screen worked and it no longer does (when selecting full-screen, it reverts immediately to windowed)..

With the WARP patched exe the same issue as posted in #71 occurs for me, so no change.

I imagine you're seeing the same issue in single line mode? (You could use the testpicture.zip from the zone if you haven't done so already.)

[mark_k]

Ah yes, I see the problem both with hardware and WARP renderers. So it's not driver-specific, but whether it occurs does seem to depend on the Amiga display mode. I didn't see it with HIGHGFX or SUPER72 modes, but did with PAL.

[mark_k]

In UpdateBuffers() you have:

float left, right, top, bottom;
float positionX, positionY;

positionX = (d3d->m_screenWidth - d3d->m_bitmapWidth) / 2.0 + d3d->xoffset;
positionY = (d3d->m_screenHeight - d3d->m_bitmapHeight) / 2.0 + d3d->yoffset;

// Calculate the screen coordinates of the left side of the bitmap.
left = (float)((d3d->m_screenWidth / 2) * -1) + positionX;

// Calculate the screen coordinates of the right side of the bitmap.
right = left + (float)d3d->m_bitmapWidth;

// Calculate the screen coordinates of the top of the bitmap.
top = (float)(d3d->m_screenHeight / 2) - positionY;

// Calculate the screen coordinates of the bottom of the bitmap.
bottom = top - (float)d3d->m_bitmapHeight;

Now I think left, right, top and bottom are supposed to be whole-number floats, e.g. 123.0, not 123.5.
Let's plug some numbers into the above:
screenWidth = 400, screenHeight = 300, bitmapWidth = 376, bitmapHeight = 283
(assume xoffset and yoffset are 0 here)
Then:
positionX = (400 - 376)/2.0 = 24/2.0 = 12.0
positionY = (300 - 283)/2.0 = 17/2.0 = 8.5
left = (400/2 × -1) + 12.0 = -200.0 + 12.0 = -188.0
right = -188.0 + 376.0 = 188.0
top = (float)(300/2) - 8.5 = 150.0 - 8.5 = 141.5
bottom = 141.5 - 283.0 = -141.5

Notice how top and bottom are not whole numbers.

How about reworking the calculations like this:

// positionX and positionY no longer used

// Calculate the screen coordinates of the left side of the bitmap.
left = d3d->xoffset - (float)((d3d->m_bitmapWidth + 1)/2);	// +1 to round properly, probably doesn't matter???

// Calculate the screen coordinates of the right side of the bitmap.
right = left + (float)d3d->m_bitmapWidth;

// Calculate the screen coordinates of the top of the bitmap.
top = d3d->yoffset - (float)((d3d->m_bitmapHeight + 1)/2);	// +1 to round properly, probably doesn't matter???

// Calculate the screen coordinates of the bottom of the bitmap.
bottom = top - (float)d3d->m_bitmapHeight;

[Toni Wilen]

I already did that few days ago. No change.

[mark_k]

Hmm, OK next guess...

// Create a texture sampler state description.
samplerDesc.Filter = D3D11_FILTER_MIN_MAG_MIP_LINEAR;
samplerDesc.AddressU = D3D11_TEXTURE_ADDRESS_WRAP;
samplerDesc.AddressV = D3D11_TEXTURE_ADDRESS_WRAP;
samplerDesc.AddressW = D3D11_TEXTURE_ADDRESS_WRAP;

MSDN says: "D3D11_FILTER_MIN_MAG_MIP_LINEAR - Use linear interpolation for minification, magnification, and mip-level sampling."

Have you tried changing that to D3D11_FILTER_MIN_MAG_MIP_POINT instead? (But there's probably still an off-by-half-a-pixel error somewhere.)

Also (not related to this problem), similarly to D3D9, should probably use D3D11_TEXTURE_ADDRESS_MIRROR or D3D11_TEXTURE_ADDRESS_CLAMP for AddressU and AddressV to avoid "texture wraparound shadow".

[Toni Wilen]

samplerDesc.Filter = filterd3d->gfx_filter_bilinear ? D3D11_FILTER_MIN_MAG_MIP_LINEAR : D3D11_FILTER_MIN_MAG_MIP_POINT;

Seems to fix it, at least it looks better now. (WRAP -> CLAMP also changed). (RTG is also fixed)