iXit / wine-nine-standalone

Build Gallium Nine support on top of an existing WINE installation
GNU Lesser General Public License v2.1
273 stars 23 forks source link

ATI X1900 won't work with G9 installed #132

Closed vorob1 closed 2 years ago

vorob1 commented 2 years ago

Hi!

I've got an old laptop for experiments. It is based on a core duo and radeon x1900 mobile. I'm using 32bit Debian 11. I've installed WINE 7 and tested some games. C&C 3 worked poorly, but worked. Then i've decided to try G9.

Downloaded G9 release 0.8 and did this:

1.Extract the tarball in e.g. your home directory 2.run the nine-install.sh script from the directory you extracted the tarball in

And now, when i start C&C 3 it won’t launch, it now state that I’m missing dx9 or compatible videocard.

I'm definitely did smth wrong here, but no idea what. Also g9 config menu is grey...

My glxinfo:

OpenGL vendor string: X.Org R300 Project OpenGL renderer string: ATI R580 OpenGL version string: 2.1 Mesa 20.3.5 OpenGL shading language version string: 1.20 OpenGL extensions: OpenGL ES profile version string: OpenGL ES 2.0 Mesa 20.3.5 OpenGL ES profile shading language version string: OpenGL ES GLSL ES 1.0.16 OpenGL ES profile extensions:

Screenshot from 2022-04-15 14-08-45 Screenshot from 2022-04-15 14-17-00

vorob1 commented 2 years ago

Screenshot from 2022-04-15 15-09-47

No idea should this nine-install.sh be launched with sudo or not. When its sudo it's doing lots of stuff in terminal. But without it i got first checkbox checked. But other are still grey...

vorob1 commented 2 years ago

Case was solved by installing these dependencies:

libd3dadapter9-mesa libd3dadapter9-mesa:i386

For some reason these were not mentioned in the guide.

lorn10 commented 2 years ago

Unfortunately the r300 Mesa driver is currently not Gallium Nine ready. Check the following Mesa issue 5966 for more details.

However, there is some renewed interest in that very old Mesa driver because of the partial transition to NIR, see Mesa MR !8044. So maybe we will see in the future some improvements which eventually makes Gallium Nine working also on that old, old hardware. :+1:

axeldavy commented 2 years ago

Glad you were able to resolved your issue. Some games should work, but indeed r500 has some issues with advanced games.

ondracka commented 2 years ago

Sorry to hijack this closed bug report (its unclear what would be the preferred support channel for nine), @axeldavy do you have any idea what could be going wrong for the more advanced games? I've been trying to figure it out for some time now and I still have very little clue.

All of the apps I tried (except basic tests like Xnine) just render black, including very simple stuff like intros, loading screens, logos, etc. It seems to be somehow related to vertex shaders, because when I force draw module (llvmpipe) for the vertex shaders, some scenes are OK, some other however are still black. What would be the recommended way to diagnose? My current idea is to try Wined3d tests and compare failure differences between the r300 hardware paths and the r300 swtcl (draw) and try to fix that, but there should be probably some easier way. I'm fairly confident I should be able to fix the driver once I figure out what is actually going wrong, but I have no knowledge of nine or D3D at all.

lorn10 commented 2 years ago

Okay, it looks that the game Command & Conquer 3: Tiberium Wars seems to work with Gallium Nine so I asked my why. After some "brainstorming" I came to the conclusion, it works because it is not a Shader Model 3.0 based game.:wink: The original requirements were a "ATI Radeon 8500 or Nvidia GeForce 4 or higher [D3D8] video card [with DirectX 9.0c installed]".

It contrast to this the CXBX-R emulator is a D3D9 Shader Model 3.0 based application which uses also a (more or less exotic) uber shader.

A way to test this theory would be Command & Conquer 4: Tiberian Twilight which is effectively a native Shader Model 3.0 game. Maybe @vorob1 has some time and motivation to try out also the demo of that game.

Coincidentally, I recently came across the following article, OpenGL, Shader Model 3.3 Texturing: Black Textures?

Long story short, the relevant point seems to be the handling of NPOT Textures. While no DX9 class hardware supports them, all DX10+ GPUs are capable for it. Perhaps Gallium Nine lacks also in this regard some "optimizations" which results then effectively in a black rendering of textures on DX9 type hardware? @axeldavy

vorob1 commented 2 years ago

After I downloaded the proper files from the repository the game start working but with enabled G9 I got only black screen and broken polygons. I will try to make video bout it.

i also tried some other Directx 9 Games and they also shows a black screen or broken polygons.

lorn10 commented 2 years ago

Thanks for the feedback. So then also Command & Conquer 3: Tiberium Wars does not work. What a pity. :disappointed:

Edit: It should work theoretically with WineD3D, it is confirmed for example that Half Life 2 works fine (which is a Shader Model 2.0 based game). But you should really switch to a newer Mesa version. There were quite some changes around the r300 driver.

ondracka commented 2 years ago

OK, so this seems to be yet another issue. @vorob1 this is unlikely to be nine issue so we should move this to mesa bugzilla. First, could you please get a latest mesa main and retest with that one? There was quite a lot of changes with respect to 20.3. If the issue is still there open a new bug report at freedesktop bugzilla https://gitlab.freedesktop.org/mesa/mesa/-/issues with proper description and screenshots. We will follow up on this there.

vorob1 commented 2 years ago

Just for you to understand, I’ve got zero knowledge about Linux. Only basic commands from google :) But I’ve tried Debian and mint, on both of them ice installed wine 7 and g9 and result was the same. Maaaaybe I’m doing smth wrong, but I’m read to test anything you say.

ondracka commented 2 years ago

Would you be able to get d3d apitrace (with that I can test myself even though I don't have the game)?

I believe it should be as simple as downloading the apitrace win32 build https://github.com/apitrace/apitrace/releases/download/10.0/apitrace-10.0-win32.7z , extracting it, putting the d3d9.dll from the lib/wrappers directory to the game folder and setting d3d9 to native using winecfg. After that run the game and a .trace file should be created (either in the game folder or possibly in desktop folder). After that please upload the file here (or to some external fileserver if it is too big, it could be tens of megabytes).

lorn10 commented 2 years ago

And it should be mentioned that the Demo version of that game is still available for download at different website like here: :wink: https://www.gamepressure.com/download.asp?ID=14733

Addition: The following interesting blog page of Aras Pranckevičius has some really nice information about the NPOT topic.

Regarding Direct3D 9 it is noted, I quote:

Things are quite simple here. D3DCAPS9.TextureCaps has capability bits, D3DPTEXTURECAPS_POW2 and D3DPTEXTURECAPS_NONPOW2CONDITIONAL both being off indicates full support for NPOT texture sizes. When both D3DPTEXTURECAPS_POW2 and D3DPTEXTURECAPS_NONPOW2CONDITIONAL bits are on, then you have limited NPOT support.

I’ve no idea what would it mean if NONPOW2CONDITIONAL bit is set, but POW2 bit is not.

Hardware wise, limited NPOT has been generally available since 2002-2004, and full NPOT since 2006 or so.

So both flags should be set to on for r500 or generally all pre-DX10 class ATI/AMD hardware. This seems to be true also for the Nvidia NV30 GPU range. However, I have no clue about NV40 but it most likely also don't support full NPOT. :wink:

Note, ATI/AMD is "lying" about the NPOT support in GL and GLES on DX9 hardware. Effectively there exist only support (in hardware) for the limited variant of NPOT, everything other is emulated in software.

ondracka commented 2 years ago

The issue with C&C3 is not related to NPOT textures. In fact it looks like it should work fine with nine except for a NIR assert and few failing shaders. The issues are however caused by lack of relative addressing in fragment shaders (r300 driver deficiency). See https://gitlab.freedesktop.org/mesa/mesa/-/issues/6368 and https://gitlab.freedesktop.org/mesa/mesa/-/issues/6371