[PATCH] wined3d: Don't accept WINED3DFMT_NULL

[Józef Kucia]

Actually, I've written the original patch. The patch won't be
necessary if we ensure that a GL texture is never allocated for the
WINED3DFMT_NULL format.

On Sat, May 21, 2016 at 4:17 PM, Stefan Dösinger
<stefandoesinger at gmail.com> wrote:
> My sense is that a D3DFMT_NULL texture should hever have a GL texture allocated, so going through the final else path should be ok - surface_get_texture_name returns 0, and context_attach_surface_fbo ignores the other fields if object is 0. Can you check if object is != 0 in the case where it fails, and see where the value comes from? I can imagine that the game manually calls PreLoad on a NULL texture as a possible cause. In our draw and clear code we're skipping the GL texture allocation for NULL resources.

Yes, the handling of WINED3DFMT_NULL textures could be improved. We
should ensure that WINED3DFMT_NULL won't ever have a GL texture
allocated. In the case of CS:GO, it seems that a GL texture is
allocated when a draw call is issued with the D3DFMT_NULL texture
attached to the texture stage 0. If I recall correctly, this happens
when the loading screen is shown. The game for some reasons iterates
over a set of textures, attaches each of them to the texture stage 0
and issues a draw call with a single triangle.

> If the GL texture is not 0 I expect that you get a GL error before context_set_fbo_key_for_surface is run. If it is indeed 0 and something goes wrong at a later point then my reasoning above must be wrong in some way.

That's accurate. The first GL error occurs when Wine tries to allocate
the texture storage by calling glTexImage2D(). The error is reported
because the internal format is 0 for WINED3DFMT_NULL.