April 2015 - Wine-Devel - list.winehq.org

Re: [PATCH 2/4] wined3d: Keep track of renderbuffer capabilities.

by Henri Verbeet

On 30 April 2015 at 21:45, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: >>> + if ((rt_format->flags[WINED3D_GL_RES_TYPE_RB] & WINED3DFMT_FLAG_RENDERTARGET) >>> + && (ds_format->flags[WINED3D_GL_RES_TYPE_RB] & (WINED3DFMT_FLAG_DEPTH | WINED3DFMT_FLAG_STENCIL))) >> This is actually wrong. At least, as long as we don't allow (plain) >> renderbuffers to be used for FBO attachments. There's nothing in the >> spec that says formats that can be used for color rendering with >> renderbuffers have to be available for color rendering with textures >> as well, and in fact that's much of the reason for this patch set. > I'm not really making a distinction between "is this format a depth > stencil format" and "Can a resource with this type and format be > created". Maybe we should add some WINED3DFMT_FLAG_SUPPORTED flag and > check it in resource_init regardless of what the app requests? > I think WINED3DFMT_FLAG_FBO_ATTACHABLE mostly does what we want as long as FBO ORM is used, perhaps it should be generalized to e.g. WINED3DFMT_FLAG_RENDERABLE.

April 30, 2015

Re: [PATCH 2/4] wined3d: Keep track of renderbuffer capabilities.

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-04-30 um 11:09 schrieb Henri Verbeet: > That's not wrong as such, but it is pretty arbitrary. > WINED3DFMT_FLAG_FLOAT is a basic property of the format, like e.g. the > component masks and sizes, it shouldn't depend on the resource type. > Once we'll get proper integer types for d3d10, it will probably make > sense to keep track of the type (INT/UINT/FLOAT/UNORM/SNORM) as an > enumeration instead, perhaps even per-component. Yeah, as I said in the mail that introduced the split, I could move things like FLAG_FLOAT and FLAG_GETDC into a separate, resource-independent flags field. Or we just keep it the way it is and track things like float per component later on. I'm using WINED3D_GL_RES_TYPE_RB instead of 2D here because this function is doing checks for the onscreen WGL buffer. It's not the same as a renderbuffer but it has the similar limitations and abilities that I don't see a reason to add a separate WGL buffer resource type at this point. >> + if ((rt_format->flags[WINED3D_GL_RES_TYPE_RB] & WINED3DFMT_FLAG_RENDERTARGET) >> + && (ds_format->flags[WINED3D_GL_RES_TYPE_RB] & (WINED3DFMT_FLAG_DEPTH | WINED3DFMT_FLAG_STENCIL))) > This is actually wrong. At least, as long as we don't allow (plain) > renderbuffers to be used for FBO attachments. There's nothing in the > spec that says formats that can be used for color rendering with > renderbuffers have to be available for color rendering with textures > as well, and in fact that's much of the reason for this patch set. I'm not really making a distinction between "is this format a depth stencil format" and "Can a resource with this type and format be created". Maybe we should add some WINED3DFMT_FLAG_SUPPORTED flag and check it in resource_init regardless of what the app requests? WINED3DFMT_FLAG_TEXTURE doesn't work for this purpose because when the application creates a non-texture depth stencil surface (or even the implicit depth stencil) we have no reason to require WINED3DFMT_FLAG_TEXTURE. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVQoZbAAoJEN0/YqbEcdMwUf0P/RfOs3qlOmR0QQp1GHruCuzz KMX5hh9Mr52MQ6Q7ZGmN2WxsWRsm0uyoIozzyjRnJncrwtYr9PH4mGn9RL3Yu4So AJMrmLWxhzoW07pBfWkiOwCnxej29pI3A2tZ2T2Gqhlb/ShiruBjwuWr7STrhg1L DSB6vDp3os7yo4w+itPyXYPRyxC/OlOXCMt27YKNKYmHdhGTYR3/TPM4yswp1zI0 0V4AFDrjtOD/c80mBVFKGcFUbN0aYlLKzHrCyXGpgutIfc8ULJOAKFlUvhP4I3so VeYtlnlMLcbxaOqd7VuteSvZl/hXwrOBOd7hy2Cfop/aHkmx6jCIL3qHowlGhZpc ADz98OkGyKX+xJ0KUmKpI1iLLsvkig5vAZsKGcawgEvAM4sycBaLLZPh5rmruXr3 ZhpmbKIONXnbNKxOx/iV02Vl7ItY0ziSsdtwrPb2GKhLhdOlohrsa0CByyY7LS6s gmZQ5IMlYaq9QLWjHxX2DW0J/3q/ovQXEMVjKoo+tK8F5pR1f5egXuDgBkOsw8z5 yTz4nvQmHoPdbLPIeiW/SC4+D6T7aOctWoy10If+mRR+VVq7uKMTicXkdgnhS2RM m7SpKTfy8vhVblVZ594kXFCPqPo5cm/CWWH7DnxaRcN3B6tbS2d5ZeamJ6qnOyps LIyM343lMK6fDVpsj0+I =trjB -----END PGP SIGNATURE-----

April 30, 2015

Re: [2/3] user32: Add some tests for EndDialog called from other thread.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=13148 Your paranoid android. === w7u (32 bit msg) === msg.c:12230: Test failed: unexpected hwnd 0014013C msg.c:12252: Test failed: bad time 314e6/314f6

April 30, 2015

Re: [1/3] user32/tests: Add a test for calling SetWindowPos for other thread window. Resend.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=13147 Your paranoid android. === w7u (32 bit msg) === msg.c:12230: Test failed: unexpected hwnd 0014013C msg.c:12252: Test failed: bad time 30ece/30ede

April 30, 2015

Re: [PATCH 2/5] d3d9/tests: Add a test for UpdateTexture. (v2, resend)

by Alexandre Julliard

Matteo Bruni <mbruni(a)codeweavers.com> writes: > v2: Make tests pass on the testbot, add a couple more test cases, some > small cleanups. It doesn't work here: ../../../tools/runtest -q -P wine -T ../../.. -M d3d9.dll -p d3d9_test.exe.so visual && touch visual.ok visual.c:12925: Tests skipped: No NVDB (depth bounds test) support, skipping tests. visual.c:16373: Tests skipped: DXT5 volume textures are not supported, skipping test. visual.c:18582: Test failed: Got unexpected color 0x0000ff00, case 0, 1. visual.c:18582: Test failed: Got unexpected color 0x0000ff00, case 0, 2. visual.c:18582: Test failed: Got unexpected color 0x0000ff00, case 0, 3. visual.c:18582: Test failed: Got unexpected color 0x0000ff00, case 0, 4. visual.c:18582: Test failed: Got unexpected color 0x0036c800, case 1, 1. visual.c:18582: Test failed: Got unexpected color 0x0036c800, case 1, 2. visual.c:18582: Test failed: Got unexpected color 0x0036c800, case 1, 3. visual.c:18582: Test failed: Got unexpected color 0x0036c800, case 1, 4. visual.c:18409: Tests skipped: Volume ATI2N textures are not supported, skipping some tests. visual.c:18582: Test failed: Got unexpected color 0x0000ff00, case 2, 1. visual.c:18582: Test failed: Got unexpected color 0x0000ff00, case 2, 2. visual.c:18582: Test failed: Got unexpected color 0x0000ff00, case 2, 3. visual.c:18582: Test failed: Got unexpected color 0x0000ff00, case 2, 4. make: *** [visual.ok] Error 12 -- Alexandre Julliard julliard(a)winehq.org

April 30, 2015

Re: [PATCH 4/4] wined3d: Don't use depth textures without ARB_depth_texture.

by Henri Verbeet

On 30 April 2015 at 00:00, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + if (!gl_info->supported[ARB_DEPTH_TEXTURE]) > + { > + static const unsigned int depth_flags = WINED3DFMT_FLAG_SHADOW | WINED3DFMT_FLAG_DEPTH > + | WINED3DFMT_FLAG_STENCIL; > + format->flags[WINED3D_GL_RES_TYPE_TEX_1D] &= ~depth_flags; > + format->flags[WINED3D_GL_RES_TYPE_TEX_2D] &= ~depth_flags; > + format->flags[WINED3D_GL_RES_TYPE_TEX_3D] &= ~depth_flags; > + format->flags[WINED3D_GL_RES_TYPE_TEX_CUBE] &= ~depth_flags; > + format->flags[WINED3D_GL_RES_TYPE_TEX_RECT] &= ~depth_flags; > + } This is wrong for the reasons mentioned in patch 2/4, but it should also be unnecessary. WINED3DFMT_FLAG_TEXTURE is supposed to indicate if you can use a format for texturing or not.

April 30, 2015

Re: [PATCH 3/4] wined3d: Use renderbuffers if the resource type is RB.

by Henri Verbeet

On 30 April 2015 at 00:00, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > @@ -341,6 +341,8 @@ void wined3d_resource_update_draw_binding(struct wined3d_resource *resource) > resource->draw_binding = WINED3D_LOCATION_DRAWABLE; > else if (resource->multisample_type) > resource->draw_binding = WINED3D_LOCATION_RB_MULTISAMPLE; > + else if (resource->gl_type == WINED3D_GL_RES_TYPE_RB) > + resource->draw_binding = WINED3D_LOCATION_RB_RESOLVED; I haven't looked much into what actually happens now, but the last time I looked at using renderbuffers for FBO attachments, one of the issues that came up was the initial surface contents. Right now we handle that by clearing WINED3D_LOCATION_SYSMEM and marking it current, but that won't work so well for renderbuffers. Somewhat related, does WINED3DFMT_D16_LOCKABLE need special handling?

April 30, 2015

Re: [PATCH 2/4] wined3d: Keep track of renderbuffer capabilities.

by Henri Verbeet

On 30 April 2015 at 00:00, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > diff --git a/dlls/wined3d/directx.c b/dlls/wined3d/directx.c > index 36be539..ad9b496 100644 > --- a/dlls/wined3d/directx.c > +++ b/dlls/wined3d/directx.c > @@ -4095,7 +4095,7 @@ static BOOL wined3d_check_pixel_format_color(const struct wined3d_gl_info *gl_in > BYTE redSize, greenSize, blueSize, alphaSize, colorBits; > > /* Float formats need FBOs. If FBOs are used this function isn't called */ > - if (format->flags[WINED3D_GL_RES_TYPE_TEX_2D] & WINED3DFMT_FLAG_FLOAT) > + if (format->flags[WINED3D_GL_RES_TYPE_RB] & WINED3DFMT_FLAG_FLOAT) That's not wrong as such, but it is pretty arbitrary. WINED3DFMT_FLAG_FLOAT is a basic property of the format, like e.g. the component masks and sizes, it shouldn't depend on the resource type. Once we'll get proper integer types for d3d10, it will probably make sense to keep track of the type (INT/UINT/FLOAT/UNORM/SNORM) as an enumeration instead, perhaps even per-component. > @@ -4178,8 +4178,8 @@ HRESULT CDECL wined3d_check_depth_stencil_match(const struct wined3d *wined3d, > ds_format = wined3d_get_format(&adapter->gl_info, depth_stencil_format_id); > if (wined3d_settings.offscreen_rendering_mode == ORM_FBO) > { > - if ((rt_format->flags[WINED3D_GL_RES_TYPE_TEX_2D] & WINED3DFMT_FLAG_RENDERTARGET) > - && (ds_format->flags[WINED3D_GL_RES_TYPE_TEX_2D] & (WINED3DFMT_FLAG_DEPTH | WINED3DFMT_FLAG_STENCIL))) > + if ((rt_format->flags[WINED3D_GL_RES_TYPE_RB] & WINED3DFMT_FLAG_RENDERTARGET) > + && (ds_format->flags[WINED3D_GL_RES_TYPE_RB] & (WINED3DFMT_FLAG_DEPTH | WINED3DFMT_FLAG_STENCIL))) This is actually wrong. At least, as long as we don't allow (plain) renderbuffers to be used for FBO attachments. There's nothing in the spec that says formats that can be used for color rendering with renderbuffers have to be available for color rendering with textures as well, and in fact that's much of the reason for this patch set. > @@ -998,9 +998,9 @@ static BOOL fbo_blit_supported(const struct wined3d_gl_info *gl_info, enum wined > break; > > case WINED3D_BLIT_OP_DEPTH_BLIT: > - if (!(src_format->flags[WINED3D_GL_RES_TYPE_TEX_2D] & (WINED3DFMT_FLAG_DEPTH | WINED3DFMT_FLAG_STENCIL))) > + if (!(src_format->flags[WINED3D_GL_RES_TYPE_RB] & (WINED3DFMT_FLAG_DEPTH | WINED3DFMT_FLAG_STENCIL))) Similar to WINED3DFMT_FLAG_FLOAT, these are basic properties of the format.

April 30, 2015

Re: [PATCH 1/4] wined3d: Allow specifying a different depth stencil location.

by Henri Verbeet

On 30 April 2015 at 00:00, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > @@ -2342,12 +2352,14 @@ BOOL context_apply_clear_state(struct wined3d_context *context, const struct win > ++i; > } > context_apply_fbo_state(context, GL_FRAMEBUFFER, context->blit_targets, > - wined3d_rendertarget_view_get_surface(fb->depth_stencil), > - rt_count ? rts[0]->resource->draw_binding : WINED3D_LOCATION_TEXTURE_RGB); > + wined3d_rendertarget_view_get_surface(dsv), > + rt_count ? rts[0]->resource->draw_binding : WINED3D_LOCATION_TEXTURE_RGB, > + dsv ? dsv->resource->draw_binding : WINED3D_LOCATION_TEXTURE_RGB); > } This works because we mostly just care that the color location isn't WINED3D_LOCATION_DRAWABLE if there's no attachment. (In particular for the case where the application is doing depth only rendering.) Strictly speaking though, it's probably more correct to use the color location if there's no depth/stencil attachment, to avoid silliness like the color attachment being in WINED3D_LOCATION_DRAWABLE and the depth/stencil attachment in WINED3D_LOCATION_TEXTURE_RGB. In fact, now that the color and depth/stencil locations are separate, you can probably just pass 0.

April 30, 2015

Re: [PATCH 5/5] wined3d: Don't use the same va_list multiple times in shader_vaddline().

by Henri Verbeet

On 29 April 2015 at 23:34, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > -static void string_buffer_vsprintf(struct wined3d_string_buffer *buffer, const char *format, va_list args) > +static int string_buffer_vsprintf(struct wined3d_string_buffer *buffer, const char *format, va_list args) > { > if (!buffer) > - return; > + return 0; > string_buffer_clear(buffer); > - shader_vaddline(buffer, format, args); > + return shader_vaddline(buffer, format, args); > } > You could perhaps just merge this into string_buffer_sprintf(), but I don't care that much.

April 30, 2015