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

Re: [PATCH 2/2] d3d9/tests: Add a depth bias test.

by Henri Verbeet

On 30 July 2015 at 12:00, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + static const D3DFORMAT formats[] = > + { > + D3DFMT_D16, D3DFMT_D24X8, D3DFMT_D32, > + > + /* The scaling factor detection function detects the wrong factor for > + * float formats on Nvidia, therefore the following tests are disabled. > + * The wined3d function detects 2^23 like for fixed point formats but > + * the test needs 2^22 to pass. > + * > + * AMD GPUs need a different scaling factor for float depth buffers > + * (2^24) than fixed point (2^23), but the wined3d detection function > + * works there, producing the right result in the test. > + * > + * D3DFMT_D32F_LOCKABLE, D3DFMT_D24FS8, > + */ > + }; > + No D24S8? I think that's one of the most common formats. (No INTZ either, but I suppose it's likely to behave like everything else.)

July 30, 2015

Re: [PATCH 1/2] wined3d: Try to detect the polygon offset scale value.

by Henri Verbeet

On 30 July 2015 at 12:00, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + if (depth->format_flags & WINED3DFMT_FLAG_FLOAT) > + scale = gl_info->float_polyoffset_scale; > + else > + scale = gl_info->fixed_polyoffset_scale; Ideally this would be a format property. In practice it probably works because we only use 24 and 32 bit depth formats, and the hardware probably either only distinguishes between 16 and 24/32, or just doesn't support 32. > + while(1) I would have preferred that as "for (;;)" > + return powf(2, cur); It seems the compiler is smart enough to work it out, but strictly speaking powf() takes floating point arguments.

July 30, 2015

Re: D3DRM Implementation patches upto CreateDeviceFromSurface

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-07-30 um 12:07 schrieb Aaryaman Vasishta: > d3drm_device_create_surfaces_from_clipper sets the clipper and > primary surface, and init_device sets ddraw and d3drm first before > anything else, so even if any of them fail d3drm_device_destroy > will ensure they're destroyed. If I explicitly destroy ddraw, how > should I handle destroying of ddraw in d3drm_device_destroy (if > it's not destroyed at that point)? The problem with the current way is that what init_device does if it fails is an implementation detail that the caller shouldn't know. Ideally nothing is ever changed when a function fails. I see two options: 1) Make sure init_device doesn't set any objects in case of failure. 2) Always AddRef ddraw and render target in init_device and always (including the success case) release them in the caller. I prefer the second one because that way you have a clear pairing of create/addref and release calls in both places. (d3drm1_CreateDeviceFromClipper create + release, and init_device Addref + d3drm_device_destroy Release). I think I mentioned this before, but "init_device" and "d3drm_device_destroy" are inconsistent names. I recommend to rename "init_device" to "d3drm_device_init". -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVugbeAAoJEN0/YqbEcdMwIBkP/R4QwAu7FKYO67M2u+bf27sF styuLfk1LjmzUg5e9bnWpKaZqdsVash8csXbskwkx1wIsP+Zf8hMG5rDP4pAdpA1 aF+BxjVc8Vzd4uY11E5Qqp8TMvJb2vbJSCHIx9uOL2T18fOxGQWZKzLtdWiYzWaq r5BsjvJ7bvA08mTfbo6EjBydQrCdhTEWTNQg22AR6GcgNjX4sWwLyPmuRsUPciBS k3TLnV2x67O56l2XSJHEXKE/dwaleOXUELVEOsUoGrfkNd64Ptd2EhE0sUZzu2us MdyCohhmJyjjI9olA1DeJdRywa/0emmacHocveeaKILzraSxfZSQD7/ZX3u9UWBd 7ECeD77XBMXefrxA8/1Jxddmq8qi2UUwt3r3UnsozmpbIpb39X0Dsv1MxF2+KF1W G5B5JfW+qB+jUv/cBT7ah/nah9l/WTSFRbxcKq9YY/dCve759LaDoC1rOQMevHuI kgohAVhfFuJl0hHDMqe3u2hACp1VgaLcQMTNOe9z9PJ01fetF4bmcYNrOQq6Vvo0 ir7QeE1LohwjxGibfdbv6MqmhnGpAJVa0LeXyn4wEaCWkoQ/6Tv4kX/uoSEv2aZr beV2+T5LmkgBcwHg6d3PzoZL2yBZeP94FyLsb8kq//P3u5J1VLYE0PLAs3zucvQQ KSj7C89fLJMPYHielQKE =CBf1 -----END PGP SIGNATURE-----

July 30, 2015

Re: D3DRM Implementation patches upto CreateDeviceFromSurface

by Aaryaman Vasishta

On Thu, Jul 30, 2015 at 3:27 PM, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > - From patch 1: > > > + hr = init_device(object, 1, iface, ddraw, render_target, width, > height); > > + if (FAILED(hr)) > > + d3drm_device_destroy(object); > > + else > > + *device = IDirect3DRMDevice_from_impl(object); > Aren't you leaking ddraw here? It's possible that d3drm_device_destroy > destroys it because ddraw is stored in object, but the caller doesn't know > this. I'd be better to explicitly destroy it. > > What about render_target in this case? Clipper isn't a problem because you > didn't create it - the application did. > d3drm_device_create_surfaces_from_clipper sets the clipper and primary surface, and init_device sets ddraw and d3drm first before anything else, so even if any of them fail d3drm_device_destroy will ensure they're destroyed. If I explicitly destroy ddraw, how should I handle destroying of ddraw in d3drm_device_destroy (if it's not destroyed at that point)? Jam

July 30, 2015

Re: D3DRM Implementation patches upto CreateDeviceFromSurface

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, - From patch 1: > + hr = init_device(object, 1, iface, ddraw, render_target, width, height); > + if (FAILED(hr)) > + d3drm_device_destroy(object); > + else > + *device = IDirect3DRMDevice_from_impl(object); Aren't you leaking ddraw here? It's possible that d3drm_device_destroy destroys it because ddraw is stored in object, but the caller doesn't know this. I'd be better to explicitly destroy it. What about render_target in this case? Clipper isn't a problem because you didn't create it - the application did. > +HRESULT d3drm_device_create_surfaces_from_clipper(struct d3drm_device *object, IDirectDraw *ddraw, IDirectDrawClipper *clipper, int width, int height, IDirectDrawSurface **surface) > ... > + hr = IDirectDraw_CreateSurface(ddraw, &surface_desc, &render_target, NULL); > + if (FAILED(hr)) > + return hr; Here you have to release clipper (because you addref'ed it) and the primary surface. You can avoid the clipper release by addrefing it after the CreateSurface call. AddRef never fails. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVufURAAoJEN0/YqbEcdMwgCQP/06Ed03h8q0pbbk7IuVO+9aU yVkglF4i+Wlw1JqM0qqIPeJg2pGd166qMdofiP29fks62Pp231A4kIvEcRGteBJf stRWLLGyBsPGPWf+UB5SmT2Qi6rT48LQE9aDi82LvXlzHTA4itHhCtjxQgoAwFLk hp7Wu6Fx6Rm6TtjijmBIpp2y3o42w+nTjdwGWFEgWSnwKk0oqHYDTHZbkvJE9h1K vbriLQIO7yAE2/4C+mWmMiOlVHXksgDttUOFtG1dqb0Xg3mo/rERd/5HwHRntnKi rVkc1W2ahagrmrckf72airTAyEwhO7RqAoqjW0zioHrBpU/xoUkxQuiMcrjyndGj 2yTeZ3Lrd4LRJhIKVJdCnzXhFLYEg2i0iUjAduh0UVERJw0ya6B43Rz4XgKjBXJ4 2mWK9NVkfSy+IZ5lpKZbUYQhNu+nO7BQtGm9CNjtHj13xt5KXy6MDaB4NiICOk2N IMyymeuQl9TF+nWjw80qQohONYOwL7ty5e5oUSbiKdmlNeqGLNbZPhT5HH/NaqUP WQ4qv+2br3n5p4IPFxmm54gvelcVdL39sC2/7bd9GUikvB2n0iESbtDNpZo1dvuM R5v7tG+uvsz4jpiJ/xIW5eKy0naYHP/Ri1cXQHqbG5ogGbPY9EKXo59TQvuhfkGa JES0dpGT/kJI2cW2bQoR =DeiB -----END PGP SIGNATURE-----

July 30, 2015

Re: [4 PATCHES] reg.exe: implement query (bug #24017)

by Henri Verbeet

On 30 July 2015 at 08:42, Alex Henrie <alexhenrie24(a)gmail.com> wrote: > this purpose. It would also be a good idea to ask for feedback on the > #wine-staging IRC channel. > The Wine developers IRC channel is #winehackers. #wine-staging is the IRC channel for the (hostile) wine-staging fork.

July 30, 2015

Re: [4 PATCHES] reg.exe: implement query (bug #24017)

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-07-30 um 10:11 schrieb xantares 09: >> From: alexhenrie24(a)gmail.com Also, why do the From fields say >> that you are the author of these patches, when the actual author >> appears to be Jonathan Vollebregt? It would be better for >> Jonathan to submit these patches himself, if possible. Fwiw, the status of these patches as far as I remembered was that I ack'ed at least one of them, but Alexandre didn't commit it. My suspicion was that the patch was too big and I suggested a way to split it. Please search through the wine-devel archives to see if you can find out what happened to those patches. Cheers, Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVueJ8AAoJEN0/YqbEcdMwpCsP/30bDDmE1KGaUIz+GysLTQl+ FAvdJjjpHL2ZeAQrVaZIsJZfQ+26vZdq57yvIodJoqLlJagcFuDdGDRp4wjIFTnN KVTC25jnjZPSs2A37sQDrFFgQTR3v6vSJQpWQ3UNypbjHTBo5ldk9kqN7HXbxCgN v4Yn2BvYfcl4qoTZWU60An/7atbWRMD/bcM56Gj3fDEUOWKNyn2GffimnOuiijSU Ay1nFmVpKDpwnYWWfoZpOM2euisQCJxioUKAfH5XIK8jpj/JoARZy6szc3yYCThe 3a0gCL/VHOatG4ktBqjij23RQeaDWWzsxNx/DhUirFCjf4ac6rJ8cQwmpQrhBac/ AzWwZJbyEjxhc1AoSr1KghjM12BkJhNJErNoGLM2pUlNonxlsTHvDom9Oqe8fVU5 mXIe31+7ul/5TkvE/KuR7h0Pd2k4POGyNoPFnFzE9Sojr/c6x/NbCEXbJb9v+Nzf ClQiAWlLYkAXK+UFus1StivtLcZBm9bhMekOT0jLoAV+roToDP1a26TyKdixDjvT oe6Pd142QJMtBw0yQV/HQTDyPrYSs9wTnvkgw/UlE67d0x45t1NCT/dFr9MgL0rq 5AyHkTZ4vgiqF7z3flyOeINvWKNtVM/UAsRsgL83ftJt68XYFAeQP5+Rg5AXSueJ +I48A7WBYlcPiPdDVkE+ =UtEl -----END PGP SIGNATURE-----

July 30, 2015

RE: [4 PATCHES] reg.exe: implement query (bug #24017)

by xantares 09

> From: alexhenrie24(a)gmail.com > Date: Thu, 30 Jul 2015 01:32:17 -0600 > Subject: Re: [4 PATCHES] reg.exe: implement query (bug #24017) > To: xantares09(a)hotmail.com > CC: wine-devel(a)winehq.org; jnvsor(a)gmail.com > > Also, why do the From fields say that you are the author of these > patches, when the actual author appears to be Jonathan Vollebregt? It > would be better for Jonathan to submit these patches himself, if > possible. > > -Alex Absolutely, I'll try to contact him.

July 30, 2015

Re: [4 PATCHES] reg.exe: implement query (bug #24017)

by Alex Henrie

Also, why do the From fields say that you are the author of these patches, when the actual author appears to be Jonathan Vollebregt? It would be better for Jonathan to submit these patches himself, if possible. -Alex

July 30, 2015

Re: [4 PATCHES] reg.exe: implement query (bug #24017)

by Alex Henrie

Xan, You will have to send these patches to the mailing list in separate emails. I strongly recommend using the `git send-email` command for this purpose. It would also be a good idea to ask for feedback on the #wine-staging IRC channel. -Alex

July 30, 2015