Re: [PATCH] wined3d: wined3d_check_surface_capability return TRUE for surfaces with WINED3DFMT_FLAG_TEXTURE.
On 4 September 2017 at 18:26, lorenzo Skotos lorenzofersteam@live.it wrote:
- if (format->glInternal)
- if (format->glInternal || format->flags[WINED3D_GL_RES_TYPE_TEX_2D] & WINED3DFMT_FLAG_TEXTURE)
That should fix the regression, but since the ambiguity of WINED3DFMT_FLAG_TEXTURE led to the issue in the first place, I'd rather not simply restore the check. Instead, I think it would be better to explicitly mark these special "extension" formats as such. In theory Matteo has a patch for that.
In data martedì 5 settembre 2017 17:55:54 CEST, hai scritto:
On 4 September 2017 at 18:26, lorenzo Skotos lorenzofersteam@live.it
wrote:
- if (format->glInternal)
- if (format->glInternal || format->flags[WINED3D_GL_RES_TYPE_TEX_2D] &
WINED3DFMT_FLAG_TEXTURE)
That should fix the regression, but since the ambiguity of WINED3DFMT_FLAG_TEXTURE led to the issue in the first place, I'd rather not simply restore the check. Instead, I think it would be better to explicitly mark these special "extension" formats as such. In theory Matteo has a patch for that.
Which issue was caused by relying on WINED3DFMT_FLAG_TEXTURE ? I admit that I know nothing about directx or wined3d (and the code is not much documented. ). Also considering that this specific control wasn't the only thing that was removed in that commit. I'd certianly like to learn a better way to deal with these issues. My studying of the wine source code started recently. Thanks.
P.S Sorry I wrongly sent the response on your email instead of the mailing list
On 5 September 2017 at 18:31, Lorenzo Ferrillo lorenzofersteam@live.it wrote:
Which issue was caused by relying on WINED3DFMT_FLAG_TEXTURE ? I admit that I know nothing about directx or wined3d (and the code is not much documented. ). Also considering that this specific control wasn't the only thing that was removed in that commit. I'd certianly like to learn a better way to deal with these issues. My studying of the wine source code started recently. Thanks.
Special formats like "RESZ", "NVDB" and "INST" can't be used to create resources, but are instead used to indicate that drivers support specific vendor extensions. In wined3d, these formats have WINED3DFMT_FLAG_TEXTURE set, but don't have an internal format, since they can't be used to create textures. The reason they have WINED3DFMT_FLAG_TEXTURE set is mostly historic.
There also exist formats like e.g. YUV and P8 formats that can't be used for texturing, but can be used for e.g. blits. Those have an internal format, but don't have WINED3DFMT_FLAG_TEXTURE. The intention of commit 8c98be4791f18f31b04a4a0f08d18979aa0d06df was to report those formats as supported for surfaces, without calling into the blitter, since that wouldn't work with subsequent commits, and was a little questionable to begin with. Unfortunately that commit failed to take the "extension" formats into account. Instead of restoring the WINED3DFMT_FLAG_TEXTURE check, I think it would make more sense to introduce a dedicated flag for those extension formats, and check that instead.
In data martedì 5 settembre 2017 19:30:37 CEST, hai scritto:
On 5 September 2017 at 18:31, Lorenzo Ferrillo lorenzofersteam@live.it
wrote:
Which issue was caused by relying on WINED3DFMT_FLAG_TEXTURE ?
I admit that I know nothing about directx or wined3d (and the code is not
much documented. ). Also considering that this specific control wasn't the only thing that was removed in that commit. I'd certianly like to learn a better way to deal with these issues. My studying of the wine source code started recently. Thanks.
Special formats like "RESZ", "NVDB" and "INST" can't be used to create resources, but are instead used to indicate that drivers support specific vendor extensions. In wined3d, these formats have WINED3DFMT_FLAG_TEXTURE set, but don't have an internal format, since they can't be used to create textures. The reason they have WINED3DFMT_FLAG_TEXTURE set is mostly historic.
There also exist formats like e.g. YUV and P8 formats that can't be used for texturing, but can be used for e.g. blits. Those have an internal format, but don't have WINED3DFMT_FLAG_TEXTURE. The intention of commit 8c98be4791f18f31b04a4a0f08d18979aa0d06df was to report those formats as supported for surfaces, without calling into the blitter, since that wouldn't work with subsequent commits, and was a little questionable to begin with. Unfortunately that commit failed to take the "extension" formats into account. Instead of restoring the WINED3DFMT_FLAG_TEXTURE check, I think it would make more sense to introduce a dedicated flag for those extension formats, and check that instead.
So it made sense to replace that code with the current one. Before there wasn't a check for format->gl_internal or similar.
However with this patch it should restore the possibility of returning TRUE for formats without an internal format (such as NULL,REZ,NDBV) but have the WINED3DFMT_FLAG_TEXTURE AND for the formats that doesn't have this flag but have an internal format (as YUV and P8 formats). Also this doesn't call the blitter at all, unless the blitter is wrongly called in a different part of the code.
However thanks for explanations. Now this part of code is less obscure to me.
-
Henri Verbeet -
Lorenzo Ferrillo