[Bug 52570] New: d3d:debug_d3dformat Unrecognized 0x34324644 & 0x36314644 WINED3DFORMAT
https://bugs.winehq.org/show_bug.cgi?id=52570 Bug ID: 52570 Summary: d3d:debug_d3dformat Unrecognized 0x34324644 & 0x36314644 WINED3DFORMAT Product: Wine Version: 7.2 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-d3d Assignee: wine-bugs(a)winehq.org Reporter: kle(a)bluewin.ch Distribution: --- Hi all! It looks like there are present two unimplemented ATI texture features in WineD3D. I can confirm this for the Unigine Sanctuary benchmark. When WineD3D is used, I get on startup an "Unrecognized 0x34324644 (as fourcc: DF24)" and "Unrecognized 0x36314644 (as fourcc: DF16)" error message. Shortly after this the benchmark stops / halts. There is at the CLI the following information avaiable: ---- Render ---- Renderer: ATI R500 256Mb Direct3D9 desc: ATI Radeon X1600 Series Direct3D9 driver: atiumdag.dll Found required D3DPTEXTURECAPS_CUBEMAP Found required D3DPTEXTURECAPS_VOLUMEMAP Found required D3DPTADDRESSCAPS_WRAP Found required D3DPTADDRESSCAPS_CLAMP Found required D3DCAPS2_CANAUTOGENMIPMAP Found optional Vertex shader 3.0 Found optional Pixel shader 3.0 Found optional Vertex texture fetch Found optional HDR blending Found optional HDR filtering Found optional NULL texture Found optional RGB10A2 texture Found optional DXT texture compression Found optional ATI texture compression 1 Found optional ATI texture compression 2 0110:fixme:d3d:debug_d3dformat Unrecognized 0x34324644 (as fourcc: DF24) WINED3DFORMAT! 0110:fixme:d3d:wined3d_get_format Can't find format unrecognized (0x34324644) in the format lookup table. 0110:fixme:d3d:debug_d3dformat Unrecognized 0x36314644 (as fourcc: DF16) WINED3DFORMAT! 0110:fixme:d3d:wined3d_get_format Can't find format unrecognized (0x36314644) in the format lookup table. 0110:fixme:d3d:debug_d3dformat Unrecognized 0x34324644 (as fourcc: DF24) WINED3DFORMAT! 0110:fixme:d3d:wined3d_get_format Can't find format unrecognized (0x34324644) in the format lookup table. Found optional NVIDIA hardware shadow Found ATI alpha to coverage Found optional NVIDIA alpha to coverage Maximum texture width: 4096 Maximum texture height: 4096 Maximum render targets: 4 Interestingly this doesn't occur when Gallium Nine is used: ---- Render ---- Renderer: ATI R500 256Mb Direct3D9 desc: ATI Radeon X1600 Series Direct3D9 driver: atiumdag.dll Found required D3DPTEXTURECAPS_CUBEMAP Found required D3DPTEXTURECAPS_VOLUMEMAP Found required D3DPTADDRESSCAPS_WRAP Found required D3DPTADDRESSCAPS_CLAMP Found required D3DCAPS2_CANAUTOGENMIPMAP Found optional Vertex shader 3.0 Found optional Pixel shader 3.0 Found optional Vertex texture fetch Found optional HDR blending Found optional HDR filtering Found optional NULL texture Found optional RGB10A2 texture Found optional DXT texture compression Found optional ATI texture compression 1 Found optional ATI texture compression 2 Found optional ATI texture fetch 4 Found optional ATI hardware shadow Found optional NVIDIA hardware shadow Found ATI alpha to coverage Found optional NVIDIA alpha to coverage Maximum texture width: 4096 Maximum texture height: 4096 Maximum render targets: 4 So it looks that the "ATI texture fetch 4" and "ATI hardware shadow" features are not implemented in WineD3D. ;-) And by the way, the function "Vertex texture fetch" isn't supported by all ATI R500 based hardware so it shouldn't be listed as avaiable. Regarding this there exist a bug report on Mesa: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6053 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52570 C. Leu <kle(a)bluewin.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|d3d:debug_d3dformat |WineD3D: "texture fetch 4" |Unrecognized 0x34324644 & |feature missing, |0x36314644 WINED3DFORMAT |"Unrecognized 0x34324644 & | |0x36314644 WINED3DFORMAT" Distribution|--- |Ubuntu -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=52570 mirh <mirh@protonmail.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mirh@protonmail.ch --- Comment #1 from mirh <mirh@protonmail.ch> --- After following the links, I'm guessing this is a duplicate of bug 52625 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=52570 Stefan Dösinger <stefan@codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |stefan@codeweavers.com --- Comment #2 from Stefan Dösinger <stefan@codeweavers.com> --- This bug is related to, but not the same as bug 52625. There was an attempt to implement FETCH4 circa 2018, but the only thing that got merged were the tests. The rationale was that FETCH4 is a proprietary AMD feature and no game has a hard requirement for it. The only reason to support FETCH4 is that games use DF16/DF24, and advertising support for those formats implies FETCH4 support. The goal of the 2018 patches was to get it running on d3d10+ GPUs via textureGather(), which is a d3d10+ feature. That's obviously not available on r300-r500. To support FETCH4 on these cards, we need some OpenGL API (likely through an extension) to access the hardware capability. Are you aware of such an extension in Mesa? Mesa r300g probably supports GL_ARB_shadow, which serves a similar purpose, but can't be directly used to substitute fetch4 or textureGather(). FETCH4 returns for texels from the texture, and the shader can then compare it to 4 depth values to implement percentage closer filtering. GL_ARB_shadow does PCF itself and then returns the result. So in order to get the shaders working, we'd either have to undo the PCF filter done by texture2DShadow or somehow recognize what the follow-up instructions do and remove them. Neither of these options sounds appealing. (The entire reply was written from long-ago memory. My memory of the specs might be wrong) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=52570 --- Comment #3 from C. Leu <kle@bluewin.ch> --- Thanks for the informative answer Stefan Dösinger. I think as of 2026 it doesn't really make sense anymore to look for a proper "texture fetch 4 feature" solution in WineD3D regarding old hardware. As already mentioned, for older hardware there exist a solution in the form of Gallium Nine. So if anyone wants to have proper "texture fetch 4" support there exist the possibility to use Mesa 25.1 and a Wine version up to 10.0. (Note, I have not tested the behavior of Gallium Nine in later Wine 11 versions but considering the numerous changes in Wine 11 Gallium Nine is most likely non-functional.) Vulkan capable hardware will use DXVK anyway. And if the "texture fetch 4" feature is not yet supported there then the efforts to implement it should be made in DXVK not WineD3D. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=52570 --- Comment #4 from mirh <mirh@protonmail.ch> --- https://list.winehq.org/archives/list/wine-devel@list.winehq.org/thread/ZH6X... Yeah, I have seen your big ass discussion about it now. https://community.khronos.org/t/8-11-gl-ext-transform-feedback-on-ati-card/5... It is my understanding that GL_ATI_texture_nearest_four should have been the proper dx9-era-equivalent, but for time or resources constraints it was only ever officially consolidated in GL_AMD_texture_texture4. In turn, in mesa that is aliased to GL_ARB_texture_gather (which in gallium is max_texture_gather_components). And specifically with r600 that has been implemented with the sm5(?) gather4 opcode. This is despite the original extension even being available on dx 10.1 hardware (ofc not to mention whatever r500 had then). https://web.archive.org/web/20081219164228/http://www.geeks3d.com/?p=1411 https://opengl.gpuinfo.org/displayreport.php?id=523#tabs-2 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=52570 --- Comment #5 from mirh <mirh@protonmail.ch> --- https://web.archive.org/web/20090731134018fw_/http://developer.amd.com/media... https://web.archive.org/web/20140820034930/http://amd-dev.wpengine.netdna-cd... You probably already had the docs.. but I spent too much time to find that, so here's the link for the original d3d9 sample they shipped in the 2006 radeon sdk. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (2)
-
WineHQ Bugzilla -
WineHQ Bugzilla