-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Hi,
Thanks for catching this bug. You'll have to submit your patch with your real name, and as Aaryaman stated, a signed off line.
Am 2016-05-21 um 10:46 schrieb contrib@maxqia.com:
- if (!surface)
- if (!surface || surface->container->resource.format->id == WINED3DFMT_NULL) { key->objects[idx].object = 0; key->objects[idx].target = 0;
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.
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.
On 2016-05-21 9:17 am, Stefan Dösinger wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Hi,
Thanks for catching this bug. You'll have to submit your patch with your real name, and as Aaryaman stated, a signed off line.
Am 2016-05-21 um 10:46 schrieb contrib@maxqia.com:
- if (!surface)
- if (!surface || surface->container->resource.format->id ==
WINED3DFMT_NULL) { key->objects[idx].object = 0; key->objects[idx].target = 0;
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.
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.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2
iQIcBAEBCAAGBQJXQG4IAAoJEN0/YqbEcdMwQOQP/20p3/P+Ej25ABqMh83F9l1/ OlhCUM3BdjYxYaZacopDInmudVALgTLaQe28dlKMw181XSqQ1op9acwHXSvXkNKM ZyvNIsqtLxenX37ZWu0I22xqV+DFU07D4TbzrQMAlgMd9XUK2713PhNVKRuYSLpS LazcTMldRoiHOxrJF7spbAr0Nn2JPGwHV/4NA0baQdIycnVQqztFQHPmdRVSP/eO 9zOacv0AKDaPt3GXgJV0+S7QuDW9EEsXI6nkytDJpazBnfSrJRCVQIGhPiokf9ik dlFkwYKuZe/fSTgSfyxyB0IhQoaOsfM4LTSJymQpneADRLhbmPORORMdzFMW/GrN qKPgK28U2oES3u3YF6u5/2YgfrSUvJvvqPe8077Tyl60uG5W7lBWeMQ4HUDaDHgW vWcDbvX1vYh+BG5zIvvVzGvmRKoKYnnEj65iqGqpi/vcJMz2f4ff/vmAiT1y23Hl 0Y50ZUxTWXpUVi4uzoQlKgpmXbny2je0P2K12zbA13J3kJ/LxoHqefm1RW9VJ1w4 VxYD94lbk4zchO0AQwbLK83b7f8QoTZH2quqyzbgyFoAynXv0RDhQ2ZjtRN66Jh+ HmFOprGcCEmOnFs9c0JS8c9MSBVc8g1i6XmnnnccO3wyaw7vrNQbNmnqPRhkpPEV ELMYspnFGK8apZ7633Dq =QeKV -----END PGP SIGNATURE-----
It seems like surface_get_texture_name isn't returning 0.
Code Added : diff --git a/dlls/wined3d/context.c b/dlls/wined3d/context.c index e741969..27f1d04 100644 --- a/dlls/wined3d/context.c +++ b/dlls/wined3d/context.c @@ -424,6 +424,12 @@ static inline void context_set_fbo_key_for_surface(const struct wined3d_context break; } } + if (key->objects[idx].object != 0 && surface->container->resource.format->id == WINED3DFMT_NULL) + ERR("WINED3DFMT_NULL object is %i at %x\n", key->objects[idx].object, location); + if (key->objects[idx].target != 0 && surface->container->resource.format->id == WINED3DFMT_NULL) + ERR("WINED3DFMT_NULL target is %i at %x\n", key->objects[idx].target, location); + if (key->objects[idx].level != 0 && surface->container->resource.format->id == WINED3DFMT_NULL) + ERR("WINED3DFMT_NULL level is %i at %x\n", key->objects[idx].level, location); }
static void context_generate_fbo_key(const struct wined3d_context *context,
Snippet from Console : (10 is WINED3D_LOCATION_TEXTURE_RGB) err:d3d:context_set_fbo_key_for_surface WINED3DFMT_NULL object is 105 at 10 err:d3d:context_set_fbo_key_for_surface WINED3DFMT_NULL target is 3553 at 10 err:d3d:context_set_fbo_key_for_surface WINED3DFMT_NULL object is 105 at 10 err:d3d:context_set_fbo_key_for_surface WINED3DFMT_NULL target is 3553 at 10 fixme:d3d:context_check_fbo_status FBO status GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT (0x8cd6) fixme:d3d:context_dump_fbo_attachment GL_DEPTH_ATTACHMENT: 2d texture 104, 2048x2048, format 0x81a6. fixme:d3d:context_dump_fbo_attachment GL_STENCIL_ATTACHMENT: NONE. fixme:d3d:context_dump_fbo_attachment GL_COLOR_ATTACHMENT0: 2d texture 105, 0x0, format 0x1. fixme:d3d:context_dump_fbo_attachment GL_COLOR_ATTACHMENT1: NONE. fixme:d3d:context_dump_fbo_attachment GL_COLOR_ATTACHMENT2: NONE. fixme:d3d:context_dump_fbo_attachment GL_COLOR_ATTACHMENT3: NONE. fixme:d3d:context_dump_fbo_attachment GL_COLOR_ATTACHMENT4: NONE. fixme:d3d:context_dump_fbo_attachment GL_COLOR_ATTACHMENT5: NONE. fixme:d3d:context_dump_fbo_attachment GL_COLOR_ATTACHMENT6: NONE. fixme:d3d:context_dump_fbo_attachment GL_COLOR_ATTACHMENT7: NONE. err:d3d:wined3d_debug_callback 0x1dd038: "GL_INVALID_FRAMEBUFFER_OPERATION error generated. Operation is not valid because a bound framebuffer is not framebuffer complete.". err:d3d:device_clear_render_targets >>>>>>>>>>>>>>>>> GL_INVALID_FRAMEBUFFER_OPERATION (0x506) from glClear @ ../../../source/dlls/wined3d/device.c / 509
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@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.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Am 2016-05-22 um 13:23 schrieb Józef Kucia:
Yes, the handling of WINED3DFMT_NULL textures could be improved. We should ensure that WINED3DFMT_NULL won't ever have a GL texture allocated.
I'd love to have D3DFMT_NULL textures handled in d3d8 / d3d9, and just set the render target to NULL in wined3d in that case. Afaik having no render target is valid in d3d10.
Obviously that means we'll have to handle mapping those textures in the client libraries, which might make this approach uglier than the current one.
-
Józef Kucia -
Max Qian -
Stefan Dösinger