Mesa-3D
Mesa-3D copied to clipboard
Panzers Phase I and Panzers Phase II games don't render anything
Using master iXit branch + wine dri3 PPAs with game Panzers Phase I and Panzers Phase II.
The games start showing a video which works fine. After the video a loading screen and the main menu should appear, however the screen doesn't render anything. Up to some week ago it shown a black screen + mouse cursor, currently it shows the last frame of the video before pressing ESC key (which should get to the loading screen) and mouse cursor.
Notes:
- I get the same behaviour when using default r300 driver on my RV530 or running with D3D_ALWAYS_SOFTWARE=1 ;
- without gallium-nine it renders properly.
Here is the output of running NINE_DEBUG=all wine panzers.exe > ~/nine-panzers-error.txt 2>&1 : https://drive.google.com/file/d/0B5wrIOE2Fy-mQm52RXdPc19seGs/view?usp=sharing
With current ixit wine and ixit mesa, does it work better ?
I still get the same issue.
Still same issue (on both RV530 or D3D_ALWAYS_SOFTWARE=1) on current mesa git.
Still same issue on 2016-02-05 mesa git (which includes many recent nine updates).
Still no idea what's wrong, perhaps window handling code.
At the end of the log the game calls nine:device9:Reset. The spec says this call should be ignored as the device has non zero refcount. But currently we do not check the refcount.
Which part of the spec do you have in mind ?
There are failing wine tests for device reset. Device reset with non zero refcount should fail, but we don't check the refcount atm an don't fail.
Well, you are going to have a refcount to the device to be able to reset it.
I guess you mean if the objets you are supposed to release are not (default pool textures and buffers).
Fix should be on ixit/master, can you check the games work now ?
I am still having the same issue. New debug output with NINE_DEBUG=all wine panzers.exe > ~/nine-panzers-error.txt 2>&1 here: https://drive.google.com/file/d/0B5wrIOE2Fy-mZTRhVkduYmhYWVk/view?usp=sharing EDIT: I used mesa/ixit master up to c0e5c77e
siro, any idea ?
An apitrace would help.
Commit c0e5c77
causes a "Device Reset" crash while loading on two games that worked before.
Logs: StarTrekOnline-Windowed-Crash.txt (Doesn't crash in fullscreen mode.) PlanetSide2-Crash.txt (Crashes in windowed or fullscreen mode. Log has asserts saying windowed even while fullscreen (Bug or fake fullscreen? Game has seperate option "Fullscreen windowed".)
Commenting out these changes in device9.c fixes the bug:
/* We must test after the state was cleared for accurate count */
for (i = 0; i < This->nswapchains; ++i) {
if (!NineSwapChain9_CheckSurfaceReferences(This->swapchains[i], &num_swapchain_surfaces))
hr = D3DERR_INVALIDCALL;
}
/* The only remaining default pool resources allowed are from
* swapchain internal surfaces */
if (This->num_default_pool_resources != num_swapchain_surfaces)
hr = D3DERR_INVALIDCALL;
Posted here instead of in a new issue as it may be related to this issue. It may be a different bug however, I don't have the games to test them.
Probably there needs something more to be taken into account.
I guess you just need to comment the last two lines, right ?
Could you tell what are the values of This->num_default_pool_resources num_swapchain_surfaces when this fails ?
Both parts need to be commented out. Commenting out one of them, regardless of which one, doesn't stop the crash.
Values as requested:
Star Trek Online:
nine:device9:Reset: This->num_default_pool_resources=2 num_swapchain_surfaces=0
Planetside 2:
nine:device9:Reset: This->num_default_pool_resources=8 num_swapchain_surfaces=2
This was confirmed, as changing unsigned i, num_swapchain_surfaces = 0;
from 0 to 2 stopped the STO crash.
Possibly useful info: Star Trek Online: x86 mesa/wine. Works with DRI2 or DRI3. Planetside 2: Requires x64 mesa/wine and DRI3.
As workaround, does it work in swapchain9.c to replace
BOOL
NineSwapChain9_CheckSurfaceReferences( struct NineSwapChain9 *This,
unsigned *swapchain_surfaces_counter )
{
unsigned i;
/* refs and bind should be 0, meaning there is no reference outside the
* swapchain (as the surfaces have a container, they don't get deleted
* because their refs/bind are 0) */
for (i = 0; i <= This->params.BackBufferCount; i++) {
if (This->buffers[i]->base.base.refs != 0 || This->buffers[i]->base.base.bind != 0)
return FALSE;
}
*swapchain_surfaces_counter += This->params.BackBufferCount + 1;
if (This->zsbuf) {
if (This->zsbuf->base.base.refs != 0 || This->zsbuf->base.base.bind != 0)
return FALSE;
*swapchain_surfaces_counter += 1;
}
return TRUE;
}
by
BOOL
NineSwapChain9_CheckSurfaceReferences( struct NineSwapChain9 *This,
unsigned *swapchain_surfaces_counter )
{
*swapchain_surfaces_counter += This->params.BackBufferCount + 1;
if (This->zsbuf) {
*swapchain_surfaces_counter += 1;
}
return TRUE;
}
Both games crash in the same place as before.
Values: Star Trek Online: nine:device9:Reset: This->num_default_pool_resources=2 num_swapchain_surfaces=3 Planetside 2: nine:device9:Reset: This->num_default_pool_resources=8 num_swapchain_surfaces=2
With this workaround, commenting out only this part works (It didn't before): device9.c line 828-829
/* The only remaining default pool resources allowed are from
* swapchain internal surfaces */
if (This->num_default_pool_resources != num_swapchain_surfaces)
hr = D3DERR_INVALIDCALL;