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

Re: [PATCH 4/4] ddraw: Test if P8 primaries can be converted to RGB.

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-07-07 14:53, schrieb Henri Verbeet: > I don't think this fix is quite correct either. The drawable format > is a wined3d internal thing, ddraw shouldn't have to know about it. > In principle it wouldn't necessarily need to be > WINED3DFMT_B8G8R8X8_UNORM either, for example if we ever get around > to supporting 10 bpc display modes. The drawable format is a winex11.drv / winemac.drv internal thing. wined3d calls ChangeDisplaySettingsEx to set an 8 bpp mode, but winex11 never really complies with that request. Wined3d depends on that non-compliance though. I guess wined3d P8 support currently fails on Windows. In practice WINED3DFMT_B8G8R8X8_UNORM (or any other non-indexed RGB format) gives us the right answer. Ideally we'd make the emulated P8 mode explicit, but then we have to take care that applications that query the display mode with user32 don't break. > So I think the fix for this would need to be in > wined3d_check_device_format(), or its utility functions. I don't think so. Wined3d_check_device_format doesn't know what ddraw is going to do with the source surface. What if e.g. the application tries to create a YUY2 offscreen surface in P8 mode? I'm open to the argument that blits between converted surfaces with the same format should be reported as supposed. But in that case we'd get the right answer for the wrong reason. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTup/tAAoJEN0/YqbEcdMwvS8P+wTD77w6V4o8BvYeil5V5LWp sS3iXWW4GqXx5rMXv84O4qNkXcfQtTfdAOwtOz3bngFdlF3UEHEd8P7XIJzWJpH6 LgV2CCCz37LBnNWEaU8Nrd13o7jlDuoGS10c2hyBSwJCPC/84jbnJfVwiaCwizyH N3F1q+GxXW5vMM7FeEZk0hkrDSPaL4dQ/6qIVR5CKMwNe/+86voXb3VvVwzlUraw pexRhte+/uebPbwo16PUXhTaH8E6UGuPpVH3ANxNJweK4aLbbJmEhayMgDGmgFgo S52sIGOjAEV2zIZqstild7n90Pdp9e9rfCrhQ4lTLnyseveyUHoEjqHaDjovzcoN W1c77gLIhPKgB8reHI6HZAofyuYC5osobK6cikHJNF4ixsiAA87f+mizxrSCql3q uYlcYWqoWHy9GcChkkNFFayMdOa7+dhLlkfp+GYrk0oQkOyU6zs8fN2Jej9GLf/b NN4vAd9jhyPvxLuUztrlx3LCzZ4Dt/iJ7O1nGCusU+Jq/m/61XZOXj+luF3wGREA u0DftXL6kEu/ucx+/VD6KwYCuNpdy9/5OgnLd9NIqzFB91xegoAzEqLsubnik2Iq 8hYvTOcju7mgTUF+ZnGnqy4U88F2CqLAyK10PTt4qLFDMls/pQbv5R58A0z27021 CcTfiLPJLJC5+HF138YP =4KW+ -----END PGP SIGNATURE-----

July 7, 2014

Re: [PATCH 6/6] wined3d: Do not warn about WINED3DUSAGE_WRITEONLY.

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-07-07 14:09, schrieb Henri Verbeet: > Actually, another guess would be that the driver will hand you a > write-combined mapping if D3DUSAGE_WRITEONLY is set. (And just > always on NVIDIA.) In theory that would be visible through > VirtualQuery(). I did a quick test, and this is exactly what happens. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTuphFAAoJEN0/YqbEcdMwfToP/R1z5rvR8j4OhH6ZJ2PHkBe+ bWP/u9938YbsfOi3A7wWVUveguN1eqHw1GXDIKdUEblA1t+LT8ujqnpjc9PJCj9B ja/9dUOSZvUPAMsrSGFh3243VZjnSpyknKnWmMKWU+/erVRSD+EMIjJgrb7OJ+YG zxaUtgdsQrYKpc3uXibRHg0PS0VnKraHkrW/Ne8PzMbDLf4aej6/lICUCRjt1cTp +ZAhMwN/b+8viF7odq4qi41w2fnYcYDQZKjP4sdqk8G7tQMVOcGBxXHND4kLwgBe q79+NKKQVn5xjAJ+GDxoy9/uyQJziPKh6ja3v/+1ybwABptPzblE2fUJEmntPjuZ FFzIQP9o76B2YKR0hzEPlPe+C8MsCIciU1CgLp0zhBHVQMkqMfAyrh/QXFM3sW6R yZbqQY1BOZW5SXki5IdWugVv+ldyiGCojvf1lzmX1l8dZR4yQk6aQ+iJrNECd0vc 6ytiKh7ZAOOfPO5mFePWrew7olc18iSIB2pY3rIuccQxZqYV9j6lXXDJQpCoZFRo syQIvjiL1lHNFggMZ4k/f9FR+T7kT4mNOG0MFGd88tPum4KQW0MyF/jHH/KH06Hp AGN6jk+HKt2d5T4BvQcHlzpcdHctLwwf2A732ol0q7Bkcm/9NatXl9bqhXt0nxE9 Vh3RXHRF9+uYkuXwBgih =dUSk -----END PGP SIGNATURE-----

July 7, 2014

Re: [PATCH 4/4] ddraw: Test if P8 primaries can be converted to RGB.

by Henri Verbeet

On 6 July 2014 18:06, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > diff --git a/dlls/ddraw/surface.c b/dlls/ddraw/surface.c > index 3d61e61..7367c01 100644 > --- a/dlls/ddraw/surface.c > +++ b/dlls/ddraw/surface.c > @@ -5838,6 +5838,7 @@ HRESULT ddraw_surface_create(struct ddraw *ddraw, const DDSURFACEDESC2 *surface_ > { > enum wined3d_resource_type rtype; > DWORD usage = 0; > + enum wined3d_format_id adapter_format = mode.format_id; > > if (desc->ddsCaps.dwCaps2 & DDSCAPS2_CUBEMAP) > rtype = WINED3D_RTYPE_CUBE_TEXTURE; > @@ -5851,8 +5852,11 @@ HRESULT ddraw_surface_create(struct ddraw *ddraw, const DDSURFACEDESC2 *surface_ > else if (desc->ddsCaps.dwCaps & DDSCAPS_3DDEVICE) > usage = WINED3DUSAGE_RENDERTARGET; > > + if (desc->ddsCaps.dwCaps & DDSCAPS_PRIMARYSURFACE) > + adapter_format = WINED3DFMT_B8G8R8X8_UNORM; > + > if (SUCCEEDED(hr = wined3d_check_device_format(ddraw->wined3d, WINED3DADAPTER_DEFAULT, > - WINED3D_DEVICE_TYPE_HAL, mode.format_id, usage, rtype, wined3d_desc.format))) > + WINED3D_DEVICE_TYPE_HAL, adapter_format, usage, rtype, wined3d_desc.format))) I don't think this fix is quite correct either. The drawable format is a wined3d internal thing, ddraw shouldn't have to know about it. In principle it wouldn't necessarily need to be WINED3DFMT_B8G8R8X8_UNORM either, for example if we ever get around to supporting 10 bpc display modes. So I think the fix for this would need to be in wined3d_check_device_format(), or its utility functions.

July 7, 2014

Re: [PATCH 6/6] wined3d: Do not warn about WINED3DUSAGE_WRITEONLY.

by Henri Verbeet

On 4 July 2014 21:27, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > I have done some basic benchmarking of the WRITEONLY flag in combination with DYNAMIC on Windows. The short summary: D3DUSAGE_WRITEONLY has no impact on Nvidia. On AMD GPUs not setting D3DUSAGE_WRITEONLY makes the common CPU->GPU streaming use case slower. If the application maps the buffer with D3DLOCK_READONLY or even reads back its contents, not setting D3DUSAGE_WRITEONLY improves performance considerably. > > All tests were run on Windows 7. I have not tested this on Intel. > > This is the raw data. The values are frames per seconds. The GPU is mostly idle in my test application. "draw" means the common writeonly use case of buffers where data is written with DISCARD or NOOVERWRITE maps. "read" writes data the usual way, draws, then performs a readonly map and copies the data from the buffer into a separate block of memory. "lock only" behaves like read, but does not perform the memcpy. > > dynamic dynamic | writeonly > Geforce 650m > draw 925 980 > read 1.4 1.4 > lock only 390 385 > > X1600 > draw 167 220 > read 45 1.69 > lock only 159 11.24 > > hd5770 > draw 157 345 > read 40 0.39 > lock only 145 30 > Actually, another guess would be that the driver will hand you a write-combined mapping if D3DUSAGE_WRITEONLY is set. (And just always on NVIDIA.) In theory that would be visible through VirtualQuery(). Of course OpenGL doesn't really allow you to control that, other than implicitly through GL_MAP_WRITE_BIT / GL_MAP_READ_BIT and usage hints.

July 7, 2014

Re: [9/9] wined3d: pass the capabilities directly to d3d_level_from_gl_info and rename it to d3d_level_from_caps

by Henri Verbeet

On 4 July 2014 00:40, Andrei Slăvoiu <andrei.slavoiu(a)gmail.com> wrote: > - if (fragment_caps.TextureOpCaps & WINED3DTEXOPCAPS_DOTPRODUCT3) > + if (fragment_caps->TextureOpCaps & WINED3DTEXOPCAPS_DOTPRODUCT3) > return D3D7; > if (fragment_caps.MaxSimultaneousTextures > 1) > return D3D6; This doesn't compile: directx.c: In function ‘d3d_level_from_caps’: directx.c:1692:22: error: request for member ‘MaxSimultaneousTextures’ in something not a structure or union

July 7, 2014

Re: [7/9] wined3d: replace vendor specific callbacks with generic code that uses vendor specific arrays

by Henri Verbeet

On 4 July 2014 00:40, Andrei Slăvoiu <andrei.slavoiu(a)gmail.com> wrote: > +enum wined3d_pci_device > +card_fallback_nvidia[] = static const enum wined3d_pci_device card_fallback_nvidia[] =

July 7, 2014

Re: [6/9] wined3d: Use capabilities from the shader backend or the fragment pipeline to determine the D3D level

by Henri Verbeet

On 4 July 2014 00:40, Andrei Slăvoiu <andrei.slavoiu(a)gmail.com> wrote: > + /* wine can not use SM 4 on mesa drivers as the necessary functionality is not exposed on compatibility contexts */ Line length. (And caps, punctuation, but I don't care that much.)

July 7, 2014

Re: [5/9] wined3d: Make d3d_level_from_gl_info return an enum instead of a plain int

by Henri Verbeet

On 5 July 2014 13:06, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Am 2014-07-04 00:40, schrieb Andrei Slăvoiu: >> +enum wined3d_d3d_level >> +{ >> + D3D5, >> + D3D6, >> + D3D7, >> + D3D8, >> + D3D9_SM2, >> + D3D9_SM3, >> + D3D10, >> + D3D11, >> +}; > I'd prefer enum values like D3D_LEVEL_5 etc. I think D3Dx is too short and generic. > I think we'd want that to be WINED3D_D3D_LEVEL_5, etc.

July 7, 2014

Re: [4/9] wined3d: replace vendor specific callbacks with generic code that uses vendor specific renderer string tables

by Henri Verbeet

On 4 July 2014 00:40, Andrei Slăvoiu <andrei.slavoiu(a)gmail.com> wrote: > +/* See http://developer.amd.com/drivers/pc_vendor_id/Pages/default.aspx > + *· Trailing space. > +cards_vmware[]= { Space between ']' and '=', '{' placement. > static const struct gl_vendor_selection > { > enum wined3d_gl_vendor gl_vendor; > const char *description; /* Description of the card selector i.e. Apple OS/X Intel */ > - enum wined3d_pci_device (*select_card)(const char *gl_renderer); > + const struct > + { > + const char *renderer; > + enum wined3d_pci_device id; > + } *cards; /* To be used as cards[], pointer to the first member in an array */ This doesn't work: directx.c:2124:5: warning: initialization from incompatible pointer type [enabled by default] directx.c:2124:5: warning: (near initialization for ‘amd_gl_vendor_table[0].cards’) [enabled by default] etc. > + size_t nr_cards; /* Number of entries in the array above */ We'd generally name that "card_count", or perhaps "cards_size". > + {GL_VENDOR_APPLE, "Apple OSX AMD/ATI binary driver", cards_amd_binary, sizeof(cards_amd_binary) / sizeof(*cards_amd_binary)}, > + {GL_VENDOR_FGLRX, "AMD/ATI binary driver", cards_amd_binary, sizeof(cards_amd_binary) / sizeof(*cards_amd_binary)}, > + {GL_VENDOR_MESA, "Mesa AMD/ATI driver", cards_amd_mesa, sizeof(cards_amd_mesa) / sizeof(*cards_amd_mesa)}, Those lines are a bit long. Generally speaking, in wined3d, 100 characters is safe, 120 is the limit. Note that as a potential follow-up patch it wouldn't be very hard to merge these tables with card_vendor_table[]. > + for (j = 0; j < table[i].nr_cards; ++j) > + { > + if (strstr(gl_renderer, table[i].cards[j].renderer)) > + return table[i].cards[j].id; > + } Four space indentation, please.

July 7, 2014

Re: [2/9] wined3d: Make the card selection for binary drivers use arrays only

by Henri Verbeet

On 5 July 2014 11:37, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > Am 2014-07-04 00:40, schrieb Andrei Slăvoiu: >> + /* Radeon R5xx */ >> + {"X1950", CARD_AMD_RADEON_X1600}, >> + {"X1900", CARD_AMD_RADEON_X1600}, >> + {"X1800", CARD_AMD_RADEON_X1600}, >> + {"X1650", CARD_AMD_RADEON_X1600}, >> + {"X1600", CARD_AMD_RADEON_X1600}, >> + /* Radeon R4xx + X1300/X1400/X1450/X1550/X2300/X2500/HD2300 (lowend R5xx) >> + * Note X2300/X2500/HD2300 are R5xx GPUs with a 2xxx naming but they are still DX9-only */ >> + {"HD 2300", CARD_AMD_RADEON_X700}, >> + {"X2500", CARD_AMD_RADEON_X700}, >> + {"X2300", CARD_AMD_RADEON_X700}, >> + {"X1550", CARD_AMD_RADEON_X700}, >> + {"X1450", CARD_AMD_RADEON_X700}, >> + {"X1400", CARD_AMD_RADEON_X700}, >> + {"X1300", CARD_AMD_RADEON_X700}, >> + {"X850", CARD_AMD_RADEON_X700}, >> + {"X800", CARD_AMD_RADEON_X700}, >> + {"X700", CARD_AMD_RADEON_X700}, >> + /* Radeon Xpress Series - onboard, DX9b, Shader 2.0, 300-400 MHz */ >> + {"Radeon Xpress", CARD_AMD_RADEON_XPRESS_200M}, > The last version of the binary driver that supports those cards is more than 5 years old. Unlike the Nvidia counterpart it has never been updated for newer kernels or X servers. This is also used for MacOS, although it could be argued its OpenGL implementation is so broken nobody would notice if we just broke random things either.

July 7, 2014