r500 hardware: "Vertex texture fetch" feature wrongly exposed by Gallium Nine

[lorn10]

This bug report targets a feature called Vertex texture fetch (VTF) which is currently exposed for D3D applications in conjunction with Gallium Nine also on R500 based hardware.

According to the information available, this shouldn't be the case regarding a Radeon X1600 or any pre DX10 class ATI/AMD GPU. The Khronos "Vertex texture fetch" OpenGL Wiki page notes regarding this:

ATI/AMD chose not to have VTF in their SM 3.0 GPUs. ... All of their standard X series. They said it would be too slow. It would be better to do Render_To_VertexBuffer (R2VB).

A good example to demonstrate that wrong behavior is Unigine Sanctuary. It clearly lists Vertex texture fetch as available.

---- 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

Note, this issue is present also in WineD3D, see bug 52625. Initially it was assumed that this was a bug in Mesa, see Mesa bug 6053. However, it was confirmed by Wine developer Stefan Dösinger that this is most likely WineD3D related. So this bug exist as well there. :wink:

[axeldavy]

That is right indeed, Nine doesn't seem to handle D3DUSAGE_QUERY_VERTEXTEXTURE.

I didn't know it was possible to support vs 3 without supporting vertex textures, but it seems that dx9 ATI hardware did do that. Now the question is whether it is sufficient or not to support the check, or if we also have to return a compilation error for invalid shaders.

[lorn10]

Thanks for the informative reply. Maybe @ondracka has some ideas what will be here the "right" thing to do.

It should be noted that even NVIDIA DX9 SM3.0 class hardware didn't support all the common vertex texture formats, so the problem exist there too. I quote:

[NVIDIA] dx9 SM3 (6&7 series): only R32F & A32B32G32R32F supported for 2D and no filtering, CUBE or VOL texture support

More information can be found at the Chromium VTF page.

PS By the way, there was some progress regarding the "black rendering" issue on RV530 hardware and Gallium Nine. The "black rendering" is not present when the RADEON_DEBUG=notcl option is used, this forces software rendering for vertex shaders. But there are compared to WineD3D still some rendering corruptions present which have currently an unclear origin.:wink:

[ondracka]

Would it be difficult to just return false for any CheckDeviceFormat with D3DUSAGE_QUERY_VERTEXTEXTURE when PIPE_SHADER_CAP_MAX_TEXTURE_SAMPLERS = 0 for PIPE_SHADER_VERTEX or something like that? I could do some testing if needed.

That said I'm not 100% sure that this leads to some real issues in the Sactuary benchmark, but I have another app: Anno 1404, where nine generates TXL opcode in a vertex shader, so I can test with that.

[axeldavy]

Yes, that's exactly that. Sorry I didn't have time to send you a patch to test (some computer update issues, and lack of time), but that would be basically that.

[ondracka]

There is a MR at https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15864 with that there is no more "Found optional Vertex texture fetch" reported. There is still a ton of other issues though, so don't expect nine to work with Unigine Sanctuary on r300 anytime soon :-(

[lorn10]

Really great, this VTF issue seems to be resolved, many thanks @ondracka and @axeldavy! :+1: Closing this issue now.