Re: [PATCH 3/5] wined3d: Handle sRGB_decode when reading the sampler state.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-10-08 12:06, schrieb Henri Verbeet:
On 8 October 2013 00:27, Stefan Dösinger ste...@codeweavers.com
wrote:
diff --git a/dlls/wined3d/surface.c b/dlls/wined3d/surface.c
index 52eac16..eb8ca7e 100644 --- a/dlls/wined3d/surface.c +++
b/dlls/wined3d/surface.c @@ -5608,8 +5608,6 @@ HRESULT
surface_load_location(struct wined3d_surface *surface, DWORD
location, c } }
-if (location == SFLAG_INSRGBTEX
gl_info-supported[EXT_TEXTURE_SRGB_DECODE]) -location =
SFLAG_INTEXTURE;
if (surface-flags location) { @@ -5671,12 +5669,6 @@ HRESULT
surface_load_location(struct wined3d_surface *surface, DWORD
location, c surface_evict_sysmem(surface); }
-if (surface-flags (SFLAG_INTEXTURE | SFLAG_INSRGBTEX) -
gl_info-supported[EXT_TEXTURE_SRGB_DECODE]) -{ -
surface-flags |= (SFLAG_INTEXTURE | SFLAG_INSRGBTEX); -} -
return WINED3D_OK; }
This change seems good on its own, as far as I can tell all
callers already handle this correctly.
Are you sure? E.g. if a texture is used with srgb=true and sRGB_decode
is supported, wined3d_texture_bind sets WINED3D_TEXTURE_IS_SRGB. If
the application later calls PreLoad manually, texture2d_preload is
called with SRGB_ANY. Because of the set IS_SRGB flag it chooses to
load the srgb copy. It correctly uses the rgb texture structure and
binds the rgb GL texture, but still passes srgb=true to
surface_load(), which results in SFLAG_INSRGBTEX being passed to
surface_load_location, even though we want to load the RGB copy.
I'll see if I can simplify the sRGB_decode handling while still
keeping it in the texture.
Patches 4 and 5 should apply without this one by the way.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJSU/AfAAoJEN0/YqbEcdMwIP8P/iJUb9d3dfTQgdDAYNSx0fFc
wp7tJZSZKDNlSLz8oTNx7k2Lmcv7ZSInce+R1oaGxS7QjkhxD7U25CdnvgaXV+Oy
IInOFuauZ7m6zO+FfBbHd9ujM1pC1Mi7BtsE59LNypJT9ym6iqe2MLocLUjDCfbL
koro3I3rzjkMb3XVUQapMevobYBr0jfl3G3q7zirrVuh1fYnL3a1Ge4ckIGsRneL
98ZjmcQyfT8lo9zxtwXPTOR23j1oLnJDNWhn63he1sX6Vg7XQvPZwszXwbN30Jof
CjbrTzBmaKq/yY4jXnffu84tDygvWFr0a9sklX7qtaGd4cNBaiSscR6gBAgvZQdI
1533llMChhOqIUBrS5i8d3t24DLdAzd6PiD4LBCjJXzqfTiqWp3JjChR9FUvq+P1
G5gEldxF+MHPXKhZgpq1MoAy13NDYAFNT/EZSgIH/yRGcm9qVTnI98A6gFZnvel4
DQ3p05mMN4dSvGsQJt/l42k8I5IT1nYqetE1ybZd/45LgHKyjYc80z8lt6f0fhrS
j9KtY3Pu6Ks8hIjsIrnVPX7SSbiaNzytEwTpECXsmnB6T2Co+d5YOYzKmWLIqOqL
ZSTBkStiBzfxi+2KWlnfUHzWmOthaPo98ZRsiwtaux9W+8xvIDMnWD5x51EPlcjt
ca93bMIW9i8aPNOOMeKb
=dp6t
-END PGP SIGNATURE-
Re: [PATCH 1/5] wined3d: Don't bother about client storage in wined3d_surface_set_mem.
Am 04.10.2013 um 15:28 schrieb Henri Verbeet hverb...@gmail.com: On 4 October 2013 15:02, Stefan Dösinger stefandoesin...@gmail.com wrote: Client storage only applies to GL textures, which won't be created for sysmem surfaces. I don't think that's necessarily true at the moment. In particular, ddraw blits can in principle cause a texture to be created for sysmem surfaces. There might be restrictions in the ddraw API that prevent this from happening in practice, but even if there are, we certainly don't enforce them. No codepath in wined3d_surface_blt will attempt to load a sysmem surface into a texture. fbo_blit_supported returns FALSE if src or destination are in sysmem, and so do arbfp_blit_supported and surface_blt_special. Color fills will go to a cpu side clear because of the INSYSMEM optimization. (This optimization is needed for a few other things to work correctly, but that's a different patch.)
Re: [PATCH 1/5] wined3d: Don't bother about client storage in wined3d_surface_set_mem.
Am 04.10.2013 um 15:51 schrieb Stefan Dösinger stefandoesin...@gmail.com: No codepath in wined3d_surface_blt will attempt to load a sysmem surface into a texture. fbo_blit_supported returns FALSE if src or destination are in sysmem, and so do arbfp_blit_supported and surface_blt_special. Color fills will go to a cpu side clear because of the INSYSMEM optimization. (This optimization is needed for a few other things to work correctly, but that's a different patch.) Fwiw, the other patches are independent of this patch.
Re: [PATCH 1/5] wined3d: Don't bother about client storage in wined3d_surface_set_mem.
Am 04.10.2013 um 17:15 schrieb Henri Verbeet hverb...@gmail.com: I guess that makes it ok in practice, but I'd still feel happier about this kind of patch if we actually enforced resource access flags first. (At which point you could also just check the access flags instead of the pool.) My plan is to enforce this in resource_load_location similar to how it's currently done for volumes. That'd be at the end of my surface cleanup patchset though, and it'll need some additional work (downloading a texture to a bigger sysmem surface to handle get_front_buffer_data). I think my surface patches should work ok without the assumption that client storage and user memory are mutually exclusive, so feel free to skip this patch for now. The other 4 patches in this series should work ok. Some later patches in the big patchset need minor adjustments though.
Re: [PATCH 1/5] wined3d: Store valid locations in the resource.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-10-03 13:14, schrieb Henri Verbeet: On 3 October 2013 13:08, Stefan Dösinger ste...@codeweavers.com wrote: --- dlls/wined3d/volume.c | 46 +- dlls/wined3d/wined3d_private.h | 6 -- 2 files changed, 27 insertions(+), 25 deletions(-) What about surfaces and buffers? Will be updated as well. See http://www.winehq.org/pipermail/wine-devel/2013-October/101575.html for the surface part and more explanations. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSTVN9AAoJEN0/YqbEcdMw9hwP/insKmUabEOtn+87MOY8RSqw gEHY1dYyi8L+ECVcjJx/x7BzLGDDC8lfISWHQkVZ6RcF7X8TegVwxQwgJY1e1isM YD8ECNRW96mBgSumrvtLUJVvdOlOOW0HU9L4U7DvqXLTrc1n6toaCvALW2v+OyTz aZy2+5iRu6SL5zoTsdt5AAOVg/xqBaY1svnBvEAyDJ3w/ztPmLReMGaM95cLzStG 6NzPhg3nd4YCb2hHvpAXypM9PQLFgMAGqOIS/4PXIVa1N5sbnNABWs0tmqOeP8DJ Oul8vSsNysEViWdsRBvQFa9m3s5lvpY3RMXKdfWjQjjpDQv6Ii3f6D8xzEUnguI4 BrysvAkrz2dcQAdkLm2LmLIe9pCEbL+FHaFXjydgRWBLY7iK5Y68WMpVyyKA8SVv jYdd/e+hLu1IvYWRgSU9Z3tNBnIwTqZyrb6exwlsUztvkoMZvTKEGuDShnTvPLX5 FornFmxCYflneZO6fjFtI+y9OgAQLsdqCPKb6JzPlQS+d3baR1IZeY/j9/iS8U0I 0xknAEGZ63gVUWONJB55S6Kt7tSEjI7fTMZfKBPm+oDU36//2PxDtuA58K7aUnnG +dAOSz0Fndpnei7dZQSCSNyCwujWqetAdXK3n13uzHxL2QZIxWiHrEo8nqawVLWL wkzlLCqE9605fthCQYf6 =Q81u -END PGP SIGNATURE-
Re: [PATCH 1/5] wined3d: Store valid locations in the resource.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-10-03 13:45, schrieb Henri Verbeet: On 3 October 2013 13:22, Stefan Dösinger ste...@codeweavers.com wrote: Will be updated as well. See http://www.winehq.org/pipermail/wine-devel/2013-October/101575.html for the surface part and more explanations. It sounds like you have some ordering issues in that patch set. Correct. Patches before patch 24 shouldn't be affected by that though. I didn't get around to splitting and recombining patch 24 and some later bugfixes yet due to other priorities. Unless you mean to imply that you disagree with the ordering of the first 23 patches, where the order is mostly a matter of opinion instead of technical constraints. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSTWsrAAoJEN0/YqbEcdMwXnMP/1mN/d6iy/pXtftkIEvLsDLb Av1zqQpPs92UU/H/TPlkQ0B2jMgBaefpuAsIWFc856lRjPUXUlbZ6cz17G502g7b cqn6idjqEqIpPfF5dQ+U3SY4mAznUI0mxWqGdiqKNyq1uuPA1PoUxS1zTIrK68sQ TXf4CgVsz0wObN7rEdpLUrGY+wPAG0PeNSCQaQsOMkvV5J0QpOHy++p9bOlV7W1K IiwpVdorT7G3ru0KMYVChdsPiFvEVE0uj+/6+b1oewaA3r2XIOKiMeCLhPGgOTnh jJxWfJA+MO3tI1RjUxXC1Pxl5fcuMTbr9saj01+WSfI/BMAnNnzdumo84yX8ME5l ypAu2UwXWSSU4cFPRx4ok/+iQ/JW533QoSZ50j4MevFl4OPAtFl+k8tfpdhfuaop tC/NuvB8SlPFLLsN1ELiBNWXyFdW5LGruTl9Fxb5in1XwQIxy/t4u1aS23cbU30K 3cYYCfk14nG6XWnAmjBq7I+gTWY55P34dIqf/q0bQPtHWUD31lP/Vdi++md8g+32 6FbMQm+/2NZfoX/fJQyRIaDQSnE0NIjpsRfEtKRPqZGehT3D2KbFJIaVJrh/X7w6 LShdXa4q7R+bQyHT6weg4nMcyoHfHDUokUctSgvAsUpVdT/0kMt/Z/kRlEvtcygi KTaXODUsfmXBin8sKlyt =3Dy9 -END PGP SIGNATURE-
Re: d3d9: update locked_rect only if wined3d_surface_map succeeded
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-10-03 21:45, schrieb Henri Verbeet: On 3 October 2013 21:16, Lasse Rasinen lrasi...@iki.fi wrote: According to debugging output, Artemis Spaceship Bridge Simulator 2.0 calls LockRect twice on the same texture (for whatever reason) and crashes. http://bugs.winehq.org/show_bug.cgi?id=34271 This change prevents the locked_rect being overwritten with garbage in that case, and the game no longer crashes. I think this patch makes sense, but could you please add a test case as well? Ideally we'd also have similar tests for other resources (i.e., textures, volumes, vertex buffers, index buffers) and D3D versions (ddraw, d3d8), but that's not a strict requirement. I'd expect that the correct behavior is to set pBits to NULL. test_volume_locking() demonstrates this for volumes. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSTdihAAoJEN0/YqbEcdMwFOoP/RJbSrIe02Zs+3kZ3orWZTW9 kYDUNQd1kBPE4FPn4XxRBN4n8imOylpNj5M8hrAVSUlXzHhYJ7r3MWCGL9p+Xgra ycYCN36u9eRMgo3LLzw3HH1z/D3qObwzHEgVZFa6UVgBfUqKxuWmbRLRm51uF9B+ YslkqGyX6d3+BqFO3Xw1h4AA+BxeEBmR/dCmMhEdzcRhgUPaCRjd0UiPnAD9SNLk 9hNbkmp6P5dfvz4fbYFmtbCiGwy0ma6BuyA9Oh925fQ7vcka6OHmIU78R5FU1zMF GEMQ9rNz/coWGWs+eFh0u09WXK3BlgN+cz8YTF/bH6iRazsyfuKNrmyVXXAyxG/c PuqTt4HhJ459KuFUGsa+he/VdqOKeoxj/h/0s/aNRnn/k6L5Coa0HUVT2BqOVi3e 4wLnHog5nwJzPMzCu89QZtJVtg9lCpfkRPPSMxt5YuM1SRoZFXCjSs9mms9TBhtt b41UK9Oy3bJVh16YdPxNj1AFpdXpngeK19jpjErH+nhXtjm6uOKinFsKYD/8L285 cRLvyND3SYK2JxyezAEEuUJlA95qKFZdcLqUPjj2ZAoXEeMCgVefIJIRPQ/znM8V vZHH1ejo0SvtcpidTa4LLCyccbUqTPl1BpSXPLbrRiTqwdIeDuWHNo/rTVRVLGBZ JmhUXEaVBE3Uuo+VzPbD =38ER -END PGP SIGNATURE-
Re: [PATCH 1/5] wined3d: Store valid locations in the resource.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-10-03 16:05, schrieb Henri Verbeet: I don't think this patch makes sense before you actually unify the location management. In particular, after this patch you'd have location management in resources that really only does anything for volumes, while from the surface point of view you'd have duplicate location management. I think the harm in that is only cosmetic because the surface one will go away, but reordering the patches is easy. I do prefer to deal with buffers after merging the location management of surfaces and volumes though. Merging buffers will require considerable additional work, most notably removing the buffer conversion code and preferably (but not necessarily) adding an arbvp vertex pipeline that can handle rhw vertices and forwards everything else to the fixed function code. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSTegzAAoJEN0/YqbEcdMw85sP/1Em4RWi2dPAP+fNtGGhBSql sUJcVkGLhSPvqNxLqhzoGMzzh+3JzvmzPtrT3b/BLRZDYemm60x8Mcxirab0RIAv XRLPd0WG1W9xFoft8I8gYSf2MBxidfEKNc/wnusj/6hgni9rPDEfhJfK9AwJt0ok NnVuvSl6NCPEhyjPX0A/Dh/rqOC1+h8bmUnKKQaONnjNiOpcbrw0LHmLbPXC1UOE WjqUJck6tm6FmRHo+pLPQzRqHNZDNqyI4k5BhVy59rDC7wI4xlzSikQGjLv3/ik5 8SQIu6bn+Inq3Ruc+kSoskY1mThEdYZVi3yPkdRwcGHeyihb0klME68z9+xQPqWN ZA3hYpnNlMDb40iMwq0mGeMdbZufsFvYXqe9PsottOhPKeCksNavEe1TFlt0rQFi MukG514G7QMfKRUJtayxvvo5b/ZaxDLs9PCjOH0A9M1ki6nsViw/aAlF/xg2lTC4 ZCziB74bai2ss9OVAZwRWYMUqkDEhp9ot2SE4gnRPnQK/+KY8ncq7boxeohFM0/W ENC8F6E+IfkdENj4vhVICQ5Ttbo0i/NO4LsSe5MqFpvTidQbLTDYNIcKqW7lBJv6 aqw+8DCH7oragx70W4P2VEC0v2p8RHvzVa25Ea/SuktJTsQh/lkul5jijmVsAZPr zjQ6a8VOc+yUONvh/zba =xm5i -END PGP SIGNATURE-
Re: [PATCH 1/5] wined3d: Send present operations through a command stream.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-09-27 00:15, schrieb Henri Verbeet: -swapchain-swapchain_ops-swapchain_present(swapchain, src_rect, dst_rect, dirty_region, flags); + wined3d_cs_emit_present(swapchain-device-cs, swapchain, src_rect, +dst_rect, dst_window_override, dirty_region, flags); I think we should place comments like This function is called through the command stream for all functions that are called through the CS, similar to what we do for context activation. Also note that swapchain_gl_present contains calls to wined3d_surface_blt and wined3d_device_clear that are going to cause problems with the multithreaded CS. I have patches to remove them, so feel free to ignore this problem for now. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSRWaKAAoJEN0/YqbEcdMw9VgP/i2n/G2CHOA8XShC8CZnRzSq TNzbfIXwAQljQYtf66U98JmbMIoeS3SMPaJ4O1+mMiT062Udi3YddiTk2AVF9bi+ f6X4y9W8Q3jPolcuTxKpZ26/WFkViHtPEUtFaa5oBtksCNGZ0b3A4oK9zbrPBram EXwovsq649RqCoBf76aidtbypdkFKLfmC6P6KxtjB3C9cdKJ58kMD0YbVsua6zNc g8gUgExEQ0no9WEyWPtlN7PRf3tQlLtuUeqrRockqnK48cKbwk3VaEgfq8o6+INs EvgjoZvc2C/+YoEWUT+n7nCtIKo9IiMSG20Ey0sbmak/K/LrvZvsyHl78nQD4ss+ t5jRCS9QZs/VzJc0VakGsZARP9jGBvzapsrAcy6Ittu1d53fpji6ySwKeUrPKim+ wMtWGtu+q0FXtIRtgDYUOofd9b1o1sB3xPqUIpRm7+yBRpXiBvuGqbmbsa/14wBe vkI5b5S/djskw9M5bV1lAOCgGmo+zFIYyebxwvx8H+sqz4HmYql9uPLTOHqWvHtn J7iXcETOlcOrC+zOOT8nieR8YYuFcda51auvK5lnXtCTQvoQse5egV16x2hJkkjx Pujit58jX2/O0WS0hqR5oAfhYtPydqUf2BayXgkLUODiZa0z1UWD2eerlOvGSvcq AUs+vi2QpDjeWmQH37BZ =QcW+ -END PGP SIGNATURE-
Re: [PATCH 1/5] wined3d: Send present operations through a command stream.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-09-27 14:19, schrieb Henri Verbeet: Perhaps, I'm not sure. For that kind of comment to be useful it should have a clear set of implications, and I'm not sure it has that until we work out the details of the multi-threaded implementation. Works for me. Afaics the main implication will be that functions that are called through the CS shouldn't place any commands into the stream. Depending on the synchronization between writer and reader this may work, but waiting for the CS to finish inside the command stream will never work right. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSRYblAAoJEN0/YqbEcdMw7IoQAJLgxf8nlDl+wGcdBlZlFhF1 nAL67t31vRSVONK/gjffW5P8V7dwNGw39gwh5sFt08Bsj0by4KAkhQ0N7Rnb6peL 7WzQdqhGWGlg+9RVUgZJeNo1LcWlglWxskfU+33wBbo6yMI3NGoKS+xF0wE1s5dS UHeuXr/2aJU9rYzcJCXTjtm294kO6r1ortk0n4+ucdg+oK7RB63sVHZaYmP3757m IDNs26+3YQFGxN49JFRZSAnbc9591QVM5sNp5UUnQkKP2GyV0r4qRO+ZJkAhnRKk hF59lCkf7+t038/LjcHB2PEvgmmL6rODc6hAPS1T9OsfomGfCnNZcKDe+X8SEpVC keKWO5OMc1h12D0DUQN9jjIaGOw7r2/zrYv8lWwU6sodFMInxhZaECGaF4edkmmb kUGuqyFp8I4+OErQbkGPgh5U9srK6866TX6dBzCaLDAxwskk5m2J1Y/ZC2EYS+Eo Lf88dLDohNg6LARyrIWDO+4ujUtbeCmCe+/UQ5bVPr1K4/3n2/HJY7Ekq1qkpdpr t7FY5KsqXuC9b38M4UN3SOlGv1juM8n1LYb7rHETYuXqFxrOFHXqapiomrqNBSZt CaA6OqDfWgq4f4YsAdvuA5J8ihn0TtMKFKV9y1krCowHk15bE8puYbZ37zYQlNDP mlSk+X5yt03k+WK1T+xu =6HrB -END PGP SIGNATURE-
Re: [PATCH 3/5] d3d9/tests: Add a volume V16U16 test.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-09-23 17:29, schrieb Henri Verbeet: On 23 September 2013 13:29, Stefan Dösinger ste...@codeweavers.com wrote: Note that Windows drivers disagree on which format they support. Nvidia has V16U16, AMD supports Q8W8V8U8, at least on r200. I am working on a more comprehensive converted format test that tests all supported signed formats with surfaces. Just out of curiosity, do you happen to know if any hardware/driver supports these for render targets? I think d3d10+ cards do. This is from memory, I'll boot some of my Windows machines to check. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSQF7RAAoJEN0/YqbEcdMwI+MQAJBznCEobaSY1bBya6lKiwyt UbF8MjlHvyVZvKELg1IrbvlShuQiQ4Dt4QYHgYWS5NEmHCQjFM8VHubQagEambc+ QKh6jN/sVYgR9CwoI01LlP+UyuXZVWWauiLeCgQPr1pjp12ODV8fkuA1vyQBlVqj TqxX1tvjDEvyC822SHiK9qrlLNtl01x9O8m/xAlWiKV0Noyb0ZAw5s+Zeuei1N9S 4QGZIpYOLsD9qiTeOYTtZVgzWSoTxWbfHsReDNO082kgc3jWBkknH3m08OYsKPr1 WMeggnmkfjMxZfjPbnjN8Hp9i27jRFinWV163Ct7UE7jV7HfeHKr8PyFyPvgRpig v1yPSKrCwLAib9TOT14JCGI9Ix2/d3Qce+HXYc+40F0a5d9aFVt5CheKeLaF/9P3 OEtAQJ/lfD2GTrDW0bA6LetUJRe6eiFGJYT0e0Fne5TOGK0UvPkq1S5vukAHvhBO rOtbU/TijGTJnV0FsdYbfJfYruIX/vt47e0IfK3OvHNR41zX5PRC2b4cJ5rggdjB mxPH2ncLcfB11cWgT3RTE/v7zXznVELyjWJeJyuv35Bu3K/2i9H9KmdyfU+TzuhI Ub+cmcL5ZTZxOm5SXsG4wbpo7YxNTmrA2DOW6YipWGNgUQtqS9c4cwbJ635m1Tmu ybaF/+f2CJsy9A93tKDG =rO4u -END PGP SIGNATURE-
Re: [PATCH 3/5] d3d9/tests: Add a volume V16U16 test.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-09-23 17:31, schrieb Stefan Dösinger: Am 2013-09-23 17:29, schrieb Henri Verbeet: On 23 September 2013 13:29, Stefan Dösinger ste...@codeweavers.com wrote: Note that Windows drivers disagree on which format they support. Nvidia has V16U16, AMD supports Q8W8V8U8, at least on r200. I am working on a more comprehensive converted format test that tests all supported signed formats with surfaces. Just out of curiosity, do you happen to know if any hardware/driver supports these for render targets? I think d3d10+ cards do. This is from memory, I'll boot some of my Windows machines to check. My evergreen GPU supports Q8W8V8U8 and Q16W16V16U16. The two Nvidia GPUs I checked (650-something and 460-something) don't support any signed formats as render targets in d3d9. The refrast doesn't support them either. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSQGkkAAoJEN0/YqbEcdMw8VkP/Rz5xPDs+trDfHwwniP0P2gh pl4nzD7WHR5GSssnU8qKyKp5Tqvj75+AXV3VT5t3O7Oy6khE0L5WkgB1Y71wcR9Y LuhyLYR8c+ewQoGDx1twKtqKXVYBzQIGpn3lZnwT9NkuCtG+4uZSNKmtTXnkMweE LyNmfti9iNi42nJsn2DVDG0ZxFdk/WvUD3qqc1qcQylP4W+vYLiAHS/c/SrAd2rP SbBU1SXaWj+MjH05e7u6hGH602q8b41lQj3137rszDvgTiAbHjl2nkNCSYozut93 OWbriJm7w3oIvri9xqT/KbAR9dhsV+wmy8XKJ8WB4b5tjAhERR7dYQCr+dhj3GT9 HNxX7hCZ9bdSSYD8H6O6BIAdDSnPaNdVvJhOmB5bxLvBWuXSGBVLgjv4dpViDWwy qc3+j4CYpx2GuBpl8ZCW66/0wQ7IKD6fc7I9zZCVLf2Ntyz/6nL7XMvd6uoe/MeJ Ti8TZlApVwBwEe/u8pm4BGBz4zDE8h9hDK/ks8dD35Ik8munOUaLeyq8P6K9jmvm 2pM16Phqx6VYYSXhxgeJEKzSrcLTDfGi6CNX/+rp+4z82mCvcmZQk9oHeqBf1yp6 BwxhluZixnHvFyQBsIEHCDpCUjyb6bOTnpMYMaYf6AonLAEaULPzJQl2l3PhtRmr a6f8z/1P5JbtmSQRiLsP =u0sa -END PGP SIGNATURE-
Re: [PATCH 2/5] ddraw: Don't set render target / depth stencil usage on sysmem surfaces.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-09-17 09:22, schrieb Henri Verbeet: Setting render target usage on a P8 surface for example would fail surface creation, while such surfaces can't be used for actual rendering anyway. Tests confirm that surface creation is supposed to succeed for P8 surfaces with both DDSCAPS_SYSTEMMEMORY and DDSCAPS_3DDEVICE set. What happens when a DDSCAPS_SYSTEMMEMORY surface (P8 or otherwise) is passed to CreateDevice or SetRenderTarget? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSOCViAAoJEN0/YqbEcdMwj6wP/AhSGoeqw0JU261iEled6W4C vIk1NEn7VB2MSDKE1i32fHiE9SnPW/kC/AimNl8PU51OzHym1gs+CIh4ZfvUvOnZ 0GNSO/HLf0aKssbxSx8z+OW0PaHXFST/6OsanKHwhq3CFJy4JPBVasFTSBnjDjv+ yQXp1ZRQOT3mI6Dy9EHVZkwdMQzC+NbFYfv3xd3a1h884ys359E97rcg/1pC/qrA oay/Oq3aAZVdWBbMjx4KbLcEDbwzVc9naQ4riKFGUY97AF+d4d8t1/kdYnSKwdtn PlpFA8SyS4/HpHVPN8+4/SoMKJetMMz9nzDPOiVjW+yWMHqLvtR08sPawDQza06g sIis0QZ0lC78eK0ibcIqvdv7u43vVtE2MJgQWnujv2L2S3pXDFr8AnK4tjPjaoUr BtuEdAyBBvo30i05f+u3+lNI4d2jsLBhFBXrWVUBqz/cb26epfz98H3Jrs09JEZ4 zypVmPE5MA5dEAgd5D5DD6AO4pymP7gpX5lrX7ynkz+kfe6xO7RtcuYKyfuwQnAu rikTZDZgv7+Dxnx1hlvP1P1o2nmFT2LhETTCev7JmzNhoS1/L0pjmNbP+JkeMYn5 mwrrCMEpK7kWL7OmRlkoWfu6q98+iR1O67+ptqf6yCRX1L4C+zYG0WKLivIX/XbF Aj4w0H043EWv3VYLPAVB =lgos -END PGP SIGNATURE-
Re: [PATCH 7/8] d3d9/tests: Add tests for block-based volume formats.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-09-17 11:39, schrieb Stefan Dösinger: --- dlls/d3d9/tests/device.c | 340 +++ 1 file changed, 340 insertions(+) Fyi, I have equivalent tests for d3d8, the behavior is the same. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSOCazAAoJEN0/YqbEcdMwCyEP/R8yohA3eKvpUv5rf8Laui6k aety5Hn56PlrVvJhEaVc6x+7C6f5fzrmtKVHQ9BgojYW7iQvz3yzuRlm8EXSGlyQ 9GXMYPlSUEqSk9Y8COZPhxqzATSuy7HKBFpCQ4vdd1qt3SNbG82QG8aWW6aLiPA0 A1MVN9ki5h4NHXNItXLbuS/Gw0w3QN6WIbwkGw9Oa19Mi9uqAlV9oQpUnH9ToELJ X7lCE1/tlXBsDKcxbx4ugfASZS6V6pTJrauHkPa0Fk5jcmF4K6mxVzT0PfUXMnsG BVtx6TBOdgtwpIoygsM8mCbGxOiaN+SlHH36fnieGXLQ2sXc4jDs8Hj6vBTcfgRu Cc5SLOIJ1Wot4Mr2Yz1+crTkHE/xp7n7TPNyPDflIqHaZ50xKSH+leRBkyqPQnud 6V63vFHYd1I2rnVTYrvsUOQZKii9QlFoknc8wBkTTM8ChV2ohmfdtl5+SVR05/Sg aanNkmZYCNmpzj5qUmcNojNH2T8DJe2KXQlwjgt0bYfXu8lEoDAYdjo07kYxNnLf /byXb4ZfjKAB8DHdB9x9MvYa/9wq9Zs+kDZE1WGt63nQVNsvmAFCLkv4il+2G2Mp rOCL9qxDMZizZaSQqfw75UO8Y7A/OxBV3gU1HLLY5gUIKyhhqcWrLIU8Mbqdbwrs 13WFu9UmCZ3NzlD2aZ5g =vJTW -END PGP SIGNATURE-
Re: [PATCH 2/5] ddraw: Don't set render target / depth stencil usage on sysmem surfaces.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-09-17 11:55, schrieb Henri Verbeet: CreateDevice() returns D3DERR_SURFACENOTINVIDMEM, provided the surface would otherwise be suitable for rendering. SetRenderTarget() has inconsistent behaviour between versions, but returns DDERR_INVALIDPARAMS in in v7, and D3D_OK in v2 and v3. I wouldn't expect actual rendering to work for v2 and v3 either, but don't care enough to test that until something breaks because of it. Sounds reasonable. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSOCljAAoJEN0/YqbEcdMw/VYP/R7LeyfBDX0mS30LnSAtTXNJ KRFVnsfuu4tk2w1w9T0R9Dti1hzGH0H9MJ/2oeA3pA/yfSjq6/lekItGkqF37Igz 0osbxD2ktoUE7JwrpbuCWyIG5l4z3BnhnTeejmExxylQniNRzgdbyzvO2Nd64M9T Fo//+kRKqX1syQA5M4cc87N/Qp2PXL6CV5XlHgX+tL8oII4hcjYWgx06RKq2JySl ghmM7KreKlJ6cx9GJWPxVLWjz0Y8yHXa3/US0D7JTPzzO5JwB6rXH7oAuo4R6vL7 CECD9mmSb0ReuOxwjqE6as1faHkmpkAwYDRfVJu7T75hue0tpN1esXjpD6DhoZbe sB5E/02rMHP1eF8nlU+9ujG8tzeKf+jeID+0njoAIdSx8DfG2bzHCLhJDVUEA3xc 35588FDQ9Cld+YqlBCbxAgE4ir/1tyKb/ifGF4K0h6f6SdxK+10qHzpMnxpe8AAc N+IckfZjAu1UAOMUuhpB3Uu6evHGg7C+rnSfWIdSSTcEgqlfI4bswdOahi+8R3K5 H7mHX1ZbIF46MIwS2TKSc8g7nR+3Yff9SRC3yoq+7K0wad12m4z+/pQJkDuykaUs I4LTP7tUJTY6+db+3Otf5Th+u/dwPpeRmemtWRoIy7DF4ETpVzDJOHenvgJKEiCp 8LMnEktzuQmvtOth71NY =kb6x -END PGP SIGNATURE-
Re: [PATCH 5/8] wined3d: Implement locking of block-based volume textures.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-09-17 13:55, schrieb Henri Verbeet: On 17 September 2013 11:39, Stefan Dösinger ste...@codeweavers.com wrote: --- dlls/wined3d/volume.c | 95 +++ 1 file changed, 88 insertions(+), 7 deletions(-) Can't most of this be done on the resource level instead? Yes, but I'd prefer to migrate surfaces and buffers to the new location flags and clean up VBO/PBO handling before merging the map implementations. I also think it's better to have the tests in place without lots of todos before such a restructuring. Error checking is a fairly minor detail in this in my opinion. The more interesting part is MAP_DISCARD handling, especially with regard to the command stream. I have the surface cleanup partially done, buffers are still on the todo list. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSOFHiAAoJEN0/YqbEcdMw72EP/iEWJ0WE2Ayrm4mMsXZ6uNsi brxk0en0ltGfS5AonYefFfsHsdxRwvP/J+ybbR8fx4/vBtGpN40bGECk1kV1iyBp WjdfC4RINVh/blHl+DFjKEGfHhb2uodxIFiClEzd5QNRLVzZzJdfh1+DGEZWtcdy Kkkd3xwzYS9LJFRsIJ4UhG3JP/0N+2Vvqt8NnOq0ZCXFcurnmgKAzg7qYvsPaT7r 2bhLz6QXHXOCR9W8ZDMGJM58xYesJ02ctQTpj0xxQdq5bfhmRXcRjqv1vikHKq7+ sPUrtOdH+/FsliM0qY8LUIb4jbG5SDCEx1ZIvcmQR0MftgYHoTY36LOQy5n4L0lk ChMsAGIZlJMW0So/L88yyE0pyFnbYp5xK7oVA4WazxtTIIb89OhlqtERc31pYD// 6PVpzaGe4+z7c+qXRF/TiYSVJwD/Ff//n2UdR9mbQiJmkUYjFIXsQNoD8Ep1j6fw J8oXvWgUDQRre3asoxNFadpNYBrHxb4+xypaIfCitKoJDJ6lOYvUiKSSZOOITAd1 yOCWJUy37HqCvKt4h7S9HhXFTNY2Gx7JBnMWRdABBjw+VuFHVNK09hJdcAFcX2ZK ry0TYXFebTkIlBVXXjUFpDczg+dgYmqWOOPSC3xZac+9BMR5H8ERr3dUMyT73DnR 7qowSJjPsi330yrIOPSu =BfCu -END PGP SIGNATURE-
Re: [PATCH 5/8] wined3d: Implement locking of block-based volume textures.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-09-17 15:05, schrieb Henri Verbeet: I was mostly thinking of merging e.g. wined3d_surface_get_pitch() and wined3d_volume_get_pitch() into wined3d_resource_get_pitch(). I don't feel strongly about doing that first though, so if you're saying you'll get to that eventually that's ok. The rough plan is to make load_location, validate_location and invalidate_location generic for all resources, with a resource-type specific callback for load_location. resource_map will load or validate LOCATION_SYSMEM, LOCATION_BUFFER, LOCATION_USERPTR or LOCATION_DIB, map the GL buffer and calculate the correct offset. It will need some information about the error checking behavior, e.g. if nested maps are allowed. A field is needed to specify the correct map memory (sysmem, buffer, user-specified memory, dib section). The resource can flush the correct memory ranges in the BO, but loading the GL texture or renderbuffer has to be handled by surfaces and volumes. With the CS, the resource code will also handle swapping the sysmem pointer and buffers in case of DISCARD maps. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSOFfkAAoJEN0/YqbEcdMwf/cQAIp3gD1NVYaPEwFVeIOyxbTM Nw18Qic08B40TsWwS8RYPyFU19Y4hcQhuVIw9iGOSxqst3zv+NTHfQzQ1bPw+Bfo 13l3hTJSeE+zFaaaGy8EZiZDNAxF6DDfdRyULLGdLUUjEhjTV2F4Z7dfhh8YYOVW nETdayk2pxX3FisP7LOQOFwM5juXYn5/UarWXDYeXTv1KAFXVSEE2wFC5Q8FVLQk YBW2WYXYw9a/1s+kvYk2l9vcSMgyq0JqbyjjX8oE/IuVZ8E1OwBS5QyvKZoA17sy y7hAqjL3yhjLWtp1ElnDL2mXhjfL3rXBILaGURAp1WnRXk5FMhMl+tPuX8ANfL6d RkxfBAf1jc8STB1vmP0DG2nL4eyAtriu+27WMmUKaqXKF+8z5lAgdYeZTywBldLR 6NYMfVFcv+nPgtSBW41BodTPtWMRzxJtefTVaVTnjhIwVuVFFwhV5hVLJoTZhA+f TXtmgC2OxryeSSPv0DCcUkTAEI8SNYs8Nl0ZBaPrIkPJnVBrtK5aAiY10plWQ7zB oU57w3GCI+VxOnKL26VmBj1c+mxrip49dsqlzvOC8mGPfh3PkGEYaqUzv3apJZ/O kbBemp1+uF0eXdH0FPx0jfh4KyJdo9smNaVetVSSdnZoeXebJ06Y7zSf3poiFQiY /jZgCSoInE41umVDpJbd =5pXV -END PGP SIGNATURE-
Re: [PATCH 2/8] wined3d: Introduce a format flag for volume texture support.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-09-17 13:55, schrieb Henri Verbeet: I don't like this approach much. I think we should either do the right thing right away and have separate flags for each GL resource type (i.e., vertex/index buffers, renderbuffers, 1D/2D/3D/CUBE/RECT textures), or just keep assuming they're the always the same and handle the exceptions for volumes like a quirk flag like WINED3DFMT_FLAG_BROKEN_PITCH. In either case this should probably have corresponding support for ARB_internalformat_query2 as well, and I'd prefer TEXTURE3D over VOLUME. I don't see what your intentions are exactly. I guess the goal is to have something like if ((resource-type_flags format-flags) != resource-type_flags) return error; in resource_init. I'm not sure how this works with D3DUSAGE_TEXTURE and textures that don't have D3DUSAGE_TEXTURE set. Check_device_format can't know if it should check for 2D or RECT support, or both. Renderbuffer vs 2D is tricky as well, although that might work ok if we equate D3DRTYPE_SURFACE with renderbuffers and D3DRTYPE_TEXTURE with 2D. (If rendertarget or depth-stencil usage are set. Otherwise we need yet another format flag that says that we can stretchrect from that format but not use it as a texture, e.g. for YUV surfaces.) I don't like the idea of negative flags for 3D textures. That won't get us anywhere with bug 21708. Changing the format flags to have one flag for each resource type wasn't exactly on my priority list. The goal of this patch and patch 3 is to make the dxtn creation tests in patch 7 work. Adding a TEXTURE3D flag is a step in the correct direction. My preferred alternative is to drop patch 2 and 3 for now and flag the dxtn creation tests as todo (It should still test locking properly since that part of the test uses D3DPOOL_SCRATCH). I can also move the flag check in patch 3 from volumetexture_init to resource_init, but I'm not sure that this accomplishes much at this time. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSOGy8AAoJEN0/YqbEcdMwVGQP/R3o19l5B5+ZPY16pVQk9+JU qRAy3J5gJH/RgE3CaG0vr3sSEadqqE+aflKesPxE4rSvtC3oDRS45lC+uk4JbhsR NQrkpiooDJiOl4hBkkyiKKsdKZ+S+iTdMM0Z2rntX5IBZ+TPDwJGwMvv9phLAOkt 2ZMxtkvPnOczA9WQXCUL0DMVOKIIaEdQ92j6Xcg79NK9w3/87U4oNXCgimreRcPt 9oBjh8i5e+/FLWVlHvApzyjBOa7wcymBuZH6KAJexbCM8CnVfPcLedrCR5ZfRB9t BPE/ClxKe+Vpm5OsJWyYsF9LFrR4rEzI3UnJaB1DUTaFar3mARhvgkPNpV8IeDDn 0AkreGD2ZXF+OHwRDKs4ALFC7sQS2E4naoBpyMy3z28gK6JYRZlPe8yeBv/ph0J7 wBwmubB1+onTERB38wiHDKPSsDWKtUeHaCXBzd5wC6j1LEnMqU6nvpcJbaMSfM3g e5BnO1s7JE+5Qu9Wg4h0aDPTaOZ6I8iD16SO5laxZU9nTpliF3fSP6CA54br9zWu bVq3RKcnLPdyfOMUsM16gMqFbsxQkX2UIxIFuxZRkXnmH4rKYq14bFp6E00+RWEC QvSoE2EA9j+sktO0hS8ydPfZoWItHSgGxLorCiu750Ds3Tyu4r8XIj/2WuE0A37J qWhNo61OeHr2STOSwGbn =PJkb -END PGP SIGNATURE-
Re: [PATCH 2/8] wined3d: Introduce a format flag for volume texture support.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-09-17 17:12, schrieb Henri Verbeet: The point is that the distinction you're making here between volumes and everything else is a bit arbitrary, and I think this patch as it is will make it more work rather than less to move towards having a set of capability flags per resource type. The advantage of the alternative is mostly that it's less invasive, so easier to change later. I might have misunderstood what you meant with separate flags for each GL resource type. Did you mean something like this B8G8R8A8_UNORM.flags[texture2d] = RENDERTARGET | TEXTURE | ...; B8G8R8A8_UNORM.flags[renderbuffer] = RENDERTARGET | ...; B8G8R8A8_UNORM.flags[texture3d] = TEXTURE | ...; Instead of B8G8R8A8_UNORM.flags = RENDERTARGET | TEXTURE2D | TEXTURE3D | RENDERBUFFER | TEXTURECUBE | ...; ? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSOKiCAAoJEN0/YqbEcdMwdzwP/2+jmNXdtZNJY6KOFXgAXAS9 qvER27doBcBdgBYfOn+1EuntCqFgF/mWFdt4Qt9bsNsjoffli90vjymmW58CgXjl 6403DPS17Zw01dWQYtNIeIDdzP74pcIuIbaZ9l63XDDk/k42ne4VleJW2UehQT8/ 91Ft/K1puR/ENQ8ka9WxAirJAqV7CV7hgpUrraAE0xWNXD3tXhDnVvEL9bnuk226 gGm8jeDsl8GX9/LL+Lcud5KK1R66xD5SJCbL8rXmZijiq5molBLMMDO6HMV2z9Zf XDFekLqTs51pQjNc163yoKa3vfA0sUa2tOwA+KzPTuiimowAZy8qS6CkAyhJGOJn aTiCOLW6p3Ywsct6NkRwKXjbbi6RJcXRbKsLsBklHPFrhmNthbgdQoKkdDX+G3qZ +kG7N8w402bvNqUv4eZ3d6vwwrKd2ma35kjw/CrTObliQfWgPmSQM1gXA+zGtkPc q/1e1VufQ34+QI7osIIdpl5uIaeg/gGrYB1qCjSmpQQWUiJB2WfLRLj2Czw0+uUJ gTK41YrU3axBQOl7NuZu8d6P1RkSfyZkFUX6abfF8NGFCn4CSOXuCOr5GlEblI9O o2s0cKH43Zu+s/mk4xsnb2pR+WiKSU1vFrrvLFIecP07y53w4eqxhaL7CcEBphOu 3kYjieSGTr6zGho/PaNF =vnJi -END PGP SIGNATURE-
Re: D3D command stream patches for testing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-09-15 21:47, schrieb Forest: In the past months I have been working on a command stream / worker thread for wined3d. It moves most OpenGL calls into a separate thread to improve performance (bug 11674) and fix some bugs that are otherwise hard to fix (24684). Thank you, Stefan! I applied your patches to the Ubuntu PPA that I maintain for Guild Wars 2 players: You are fairly lucky with Guild Wars 2. I didn't see any improvement in this game myself. But as Henri said, it depends a lot on the game and your GPU and CPU. Afair GW2 uses dynamic surfaces, so the patchset doesn't achieve its full potential yet. Even if it does, it removes fixes one potential performance issue. It doesn't magically fix everything. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSNhVlAAoJEN0/YqbEcdMwDFsP/iAUFAosFIGjlfPkEKm8n+n4 NSdwb9C53mHBQM8zYyFfwAgAGVxuH9HMF0g12+xpSaS2YSTZtzlZO7/4lswZ2uM4 IDVSYALYyy4gEfMb4YEC0c0qJBvm2qiJhPZPo0FGrw26H+yGfEPDmW01+PI+scbU krlwtKlxJtOcIBhxpcO7lCMyi1ALJ2ir7w9RE5CBvwf2sMo0QrtHvd6TuClKhEbJ PpIWcJn24Feu14CutDk2dVwvCeIccuRzWH7ATcPhYk44FSyZjm83GA1wvZH4NEwP jjuq1H8hIgFSyJQkfGnsCrHLQGVgiAYuhE3KSa0eEebaicfhlIrCz9Ts0cjnhCoq Wka4L+lHIBYGy32y24q256B+M/MB2/k80FXVBOCFkqV5HQetYe033B7AVHew6HCV g3n7LLfZXQO2h8+OCwGwopyE6ltTpqvB/Y64/tR3yKzacbGH9xiI+WfF+LFZIod9 q5Vl3bbT3rgnqfkMJki+uEGYK9xtNcFZRnz7eb4bsAD7XX6VGVLW8p71a9nUeUvE TW1YMbPU2ZRDFL7X0MWS4HE1pgGX7gIASQiPSdUWtcYmco5xSTWmrnCkh+B6zuA/ XKvVdc+cCE4IXaxxJiINmUnCnqKumwZudqF2vqqxdpHIvXhFodIhxaYPKW1lh6yB kV+hKqlEroLRsheS7KP/ =jcSo -END PGP SIGNATURE-
Re: [PATCH 5/5] d3d9/tests: D3DCMP_GREATER is broken on r500.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-09-12 12:44, schrieb Henri Verbeet: On 12 September 2013 12:23, Stefan Dösinger ste...@codeweavers.com wrote: + * On the r500 driver on Windows D3DCMP_GREATER and D3DCMP_GREATEREQUAL are broken for depth + * values 0.5. The range appears to be distored, apparently an incoming value of ~0.875 is distorted? Sorry, I wasn't able to find out what the driver is doing exactly. Everything seems ok when the value in the Z buffer and the incoming fragment's Z are 0.5 or smaller. At first I thought D3DCMP_GREATER is broken in general and behaves like D3DCMP_NEVER - that was when I investigated the failure in the d3d8 version of this test. On closer inspection it turned out that 0.501 is roughly equal to 0.0877, and 0.95 roughly matches the 0.75 we write into the buffer with the clear call. (The numbers are from my memory, they may be a bit off.) D3DCMP_LESS works correctly. I think D3DCMP_GREATER also produces expected results when just comparing geometry Z vs geometry Z, so a game that uses it and doesn't depend on a match with the clear value should still work, maybe with reduced precision. D3DCMP_GREATEREQUAL has the same bug as D3DCMP_GREATER. D3DCMP_LESSEQUAL works ok as well. After two hours of trying to find out what the driver does I decided it's not worth the time and marked the tests broken. It is after all a no longer maintained Windows driver. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSMaaBAAoJEN0/YqbEcdMwX6sP/jGI6S2Xjsan6U17f+NqGPs9 D6rT0MoQsFW1SPkv3hidjcaIbMfZchpoGs27VySmPK0YvhDPjgaMNbH5SDJKMh0A 6vYTSmAKBL68xLJLR1u0c4F1iofnt01l6LhdUstHt4YGcZyZVXawaSn8fJ9Pry4N Pg+Y/3uli8zAiT4Gm0lsBm8fxyFPFhZB8gWwOT6fgt/c59p2W/wT0JUf2GEj1Pk1 m+cieaTckKgZ77RVDWOtv+FfKHjmOEPgWSGAf42D9Mp7qpKHKFMM0taliFKfB4oj vktcX4yvw+8afMcO4MLIkcZZOv8jmr/KwK5ySrlKdw9h15ONFIPmBqJ2uDErLhWy 8//KenelM1OVpOH0F/j93yWNr6NyqGkXbNvwlJSoKWbxHCBrhoSzyR+p4MxhFX/4 x9dGy2ZKFwz1gmWYpHmUdNOMc6snwxMGU0I+uy5WrBKBdevTMcwR6meEFa49dguC F96uDIxwbg3nO/3nacoeENgqjPw6aiDmYM3C+eURNjPJ1NPqFLUlAmT60yQA3jaS LYIgvhHbuyNfw6RWFCF/q7u8XlHSdTjwL/HY8xWu6zWtZmeIVsOqkyKdgjRxcvlF OUCseQp5swgP+lTolC6nMNiqwclmMHYaVNPeZr2a5xM7pCfFIDsOj0NTEaI3sjzX gq3mhzK0w+Ru25qPxAiP =/uUv -END PGP SIGNATURE-
Re: [PATCH 5/5] d3d9/tests: D3DCMP_GREATER is broken on r500.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-09-12 13:36, schrieb Henri Verbeet: I really just meant the typo in the comment. Ah yes, that should be distorted. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSMafeAAoJEN0/YqbEcdMwEuUQAIYa1wxf92DwRVItKXcYwaYv AFVAAP4eCzkf7txTnIXVpcIQNy+GhvsjBNy0uAG2yqAYktFujPu4XxViuLaWnj9q ubzpnarMq7bP7+ew9fU2sdMNSlCe+lCrCOpjOCPkSvECaXEN6mpalmrDBiaNZ4v7 GJ3edD39gOiIhQpr5gVHEsdUp0NyrFoF0Gt8HcCP42iu4QuHKKic+8G7iev2wdxB L5QMYkl2Dqew5LP2FJ8gWAsYkLJyu4PAJm45sBYEGaX64cHMdAA9U2mDDu9SeJOW kBtnAYRIW9WBJC75hvL9HTvfb6fT2utHdyl3HRSMH1YIFzHnt8RxU/48OyktTZ8p MtCN3otEYeNoQrA11EU+HGh/kQUi7qQxa7vaSSmvzh5LeLUVpKRtH2dHXEIr5OWM X30qRBecS84epWHjhPXD3FmpBRq5p5A8AGDh9x/JYctvamHoCDZhAbg4sZCPxfP7 H1YDdhL4AZYuZCkMgcZgllELN3TS4c/lr+FRiW/qcuDTID+A+ojrruxEDAJjrxmF XevQGW42l622/XNv4AWZ5o0laxdimJiKHdnBxFm4LXTZlhueowPpFYCM1hyUqUmt 9dFTmNsjG5YFd4jX6shIu57SsIpDkVM9h9j3OyTRfzi9vHdZWG1NEx/iKHWEAZSO 9phzspBehOeheTiYjjCV =jFVG -END PGP SIGNATURE-
Re: [PATCH 4/5] wined3d: Move the decoded stream info into the context.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-09-11 13:32, schrieb Henri Verbeet: On 11 September 2013 11:31, Stefan Dösinger ste...@codeweavers.com wrote: @@ -1880,9 +1888,8 @@ struct wined3d_device WORD d3d_initialized : 1; WORD inScene : 1; /* A flag to check for proper BeginScene / EndScene call pairs */ WORD softwareVertexProcessing : 1; /* process vertex shaders using software or hardware */ -WORD useDrawStridedSlow : 1; WORD filter_messages : 1; - WORD padding : 8; +WORD padding : 1; I don't think that's quite right. The next element is a BYTE. The 8 bits padding were stupid considering that, it just generates a hole. Now I am removing one bit, which leaves one bit of padding left. I can send a separate patch that removes the 8 bits if you want, but I didn't consider that necessary since the padding doesn't do much anyway. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIbBAEBAgAGBQJSMFYLAAoJEN0/YqbEcdMwPCEP+JBvqr+U0mPGMoapURDqm8V4 ERRVfT655e+K1G6xPZZfMAq+y+3gCrZTTqMrFx8zTvBScRMjsnbJDLi9NSSMYVNl mO9Yszk28JYAP5MRN6qpTLkLxrX4qQkb0ZT2xQBeSSo2LCqplvZ2FmAiPlvwhm20 5inqe4j+JOuPmX5QwSMeqHj89ARgc2VZ6l56V0n7QDwTgqVOt5Zhqdge2g+GB6tp jyxqPeINJBL8qrhom0oVjyxOI6uU/p1G2GMKdAzmCbwh7lKp8yAi8nrbscvAOYXF ybpHDExZv7RxHMX2DuSnSVgFEULiTgjVqkKdkC+3lOPACjZTPAzgSqUY8RhAQbyc ZHpHTYpAafovURstJPgp+2fGIWV+n4Z/PH3iy/wCai1sdESwFFvcZf6p7xc+NqEP LSlGpuMD5YX8DDUxvR13OudqT7WqsB5mAmJJAyahLczxnztpWAMKrHmjnty8H9B2 J/WVhfbYAuqQbMClREVZ5SXDQNY3NKcp1Hpqp56GrtIAu9B6M8oGHyStB7KHvaEa A4CNUcStrwAACpKO6SZF951C090/y7It1aaYVVklyygU50Cj3M+C0LWWj8m51t2n nazC7AL79DY7JEjlbyrHE6Qc61ZsIKn1fTDQ92NzzxxFNuWrZIPRItSzASzvvgzf Q94g3yVHblJMWDZ2CMI= =7fwi -END PGP SIGNATURE-
Re: [PATCH 4/5] ddraw: Avoid LPVOID.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-09-11 19:05, schrieb Marvin: === wxppro (32 bit d3d) === d3d.c:1260: Test failed: Homogeneous output was generated despite UNCLIPPED flag Fyi, I am seeing those on my Windows machines as well. No idea why it suddenly started popping up on the testbot though. So far I didn't get around to investigating what the actual problem is. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSMOZuAAoJEN0/YqbEcdMwjQcP/0V9e0zZ9UUczZVEQTQBwsz5 Y0F2N5+mS1ccf7Td+kkcKM89/gLxLH+1oq/6u+7x1+R4khQzT6hIFi7dr1iXG0MC KmFhwScCumN/8V6+6/BHxS9rG2NgaLrq3rj9aOrnBgumB1+Ox3B0dDQY85Jha7iO PW9fTXPY/UDkLVrO+K/AOcsJMQebG+kjVH85fsB/YrsbJ+WfIraqTks/ttN9feYg zLbR2DPF6xCILUKfu84S8rctM3uHfIaiW2jLJcXjVKbqhxcvAV05XFDMsvr2WNCq FdOEg70IKcs5Bj+wX6sA6RdNQ+mPWh9tgCdo5Qtrk9LOmoG1/0Oi76k0RUD64hSa DlUDll/Xd7tFarSDwzwywZ5AIERV7qKkfdA+6tj/+HCYX5DmpQmcRmJAdWryzXuu E+brPjBCV6h/VzL7iqbOWEj8mh9tQOpJ89nE3dp727KhvMNsT1FUIXlB8qd46p8u sizKufRIZbSfp9KZip8nSoOK+YUs3BX72g/Qna+lwZT3JqpoAPphWbFjMKCRMPS4 Q/CviGoJd5Z+vGxwH0MtKPPG9L8cozXfUCPozppBsIgRgx+et3Wy20qiUJrqPq7H 3fOcjx+TwLWyRLurMt7qvjB7GLCDWco10PyUokjfeDwLQmB5DZQUUifIyMzo5OqZ rk2puTjxLof/19BBVRGx =Qw3d -END PGP SIGNATURE-
Re: [PATCH 4/5] wined3d: Move the decoded stream info into the context
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-09-09 13:42, schrieb Henri Verbeet: I think that's an unfortunate place to insert the field, and you should update the padding. @@ -1880,9 +1889,7 @@ struct wined3d_device WORD d3d_initialized : 1; WORD inScene : 1; /* A flag to check for proper BeginScene / EndScene call pairs */ WORD softwareVertexProcessing : 1; /* process vertex shaders using software or hardware */ -WORD useDrawStridedSlow : 1; WORD filter_messages : 1; -WORD padding : 8; Padding? Do we need it? The compiler should take care of it for this structure - - unlike texture_stage_op, where we don't memset the structure to zero and explicitly set the padding to 0. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSLbW5AAoJEN0/YqbEcdMwRDAP/0coCS3OKzCZw/qcjZ8GbKCY J2imUtGc6aOhlWPgpzPrIs1yy4JWGosrobYjRKaYpfN7IuxsUgZ011vo0gCSyC0q YRNIo3ExRgR5gSal4l9v4o6UvPgvWhTiSa/ay9Gwqwy/1FXWhI9wEne0miJ75JLg 5BhVl54kaa2dKOAZac9xD3hL+3lKZadsvKO78VUGenGUYo78IQp7tRlAA2IRwKrS AfywhobK3v0yA2eA4xMMV7gbjx3lcLBSxG7z4+JvkWlaSTUG13ndSldyDwZ4kCwl LuD/MaZZem8oVBiYnWLuGbXJ3hfvIcmJTiGKzPFbirE7eZMA3g7wgBJhUGPK5Urx kRA0zbF6FNq0GfoXg/FVbKL2mcaahzIpm3qOHGkv/U5sv4g+6SSEoGyi69Kyjq6o ixqOCmuY5Yj+AHTzcorFpcDxWQX0eqOZnlkhwI0yCyiIQm0rNVOcZ5DmzwjVKnfb jRLcs7TwazoEjVfhfzSMRez+r6cngxsXsQMmbnvp9O4BZactJnYT62OmfRCvJ5Zu RXrppcDhpIr/adw7j1p7htDqCzWgUVLhKvxQUaNBUeBhRnNCdJjSMlVcCiNGOvkl VCrFUYYQh0bMpVmhx4BsnjgkcKixxYHsWBSf8VKUOLL7jKwXzg/gjSIC1wPZrKUb R4MgltrET/xMpgL7j8CB =KW1K -END PGP SIGNATURE-
Re: [PATCH 4/5] wined3d: Move the decoded stream info into the context
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-09-09 13:55, schrieb Henri Verbeet: Not strictly, but I think it helps with keeping track of how much bits are left and avoiding silly things like holes in the structure. Fair enough. Please ignore patches 4 and 5 for today, I'll take my time splitting 4 up. I'll resubmit 1 with an updated title. Thanks, Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSLcArAAoJEN0/YqbEcdMwmocP/3hCs8OymvtGVOrgykbNFe6w 9JigmRYwhT9R40XiSFwJRTcvyaGQ0zHSUM0q39xWnsA4MXiPfTUBMKa5W9N1pcog Z4ZrguLzYVjHlgVh2tlY9KruzfCw+9Z1WjqhU2MMFwioMndzQRSmlzN3WCsG3hbz iGs+5U1R1jt4MemzloAOpUtne9JtRYJonCAZFp4/doQz8GU80IGISKRf1Mp1Z4xO /yjYeMIt/us3dKhAUlH05nA7yLpuqD34qouoVI3DJwgI7n20VXsv9u4nEMKn+8rs 00pNPwQnG+ZiSTNtHgoHRzBwugI1XTbaR/9HtfBy5s9wWE2o6DCuUAyGIkSsRGrb /ymCh02HABPMO/bhdCvYDO+vOCrhXmrs8umTJVtQnn4cfaNjmqI89gTHv9c0kpIC wJ1EdGSk+lLfc5LzBrkIB4epqSx0Rhjx88eT6kSPAgTt/3uc3zUlayn00oPRVv1z 8GJ8MeVhsp3vjSn5zROMTDd6+N5pJEgUBqH9mG5q2Lbu5uHBXJOy7rKBqqI5RVSq 1uEPT/I1LNmbmVf9Ev3dmAoQZXBGYS/D/3gLoYm54dba2wEYd3tpHEEacrC16UhB 0JWz7pQU0DTMhUQVBZ7dZ8upqR5UmegplDdSq39MmpaLqOR/m2/rWkX0bLaqcz3t WIf4u/+o4dEeKrETIvQK =fB5u -END PGP SIGNATURE-
Re: D3D command stream patches for testing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-09-04 20:11, schrieb Prot Secret: Hi, I am interested in your work, but after patching wine171 of this patch and enabled csmt, i have seen this in SC2 http://postimg.org/gallery/1w8y6jbg I use nvidia GTX 680 with proprietary i386 nvidia driver 319.49. Where I could be wrong, or what else can be set that would be normalized image using the patch? Not your fault, there is a race condition in the surface code that was recently introduced. I will post an updated patchset in the next few days. Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSKDfBAAoJEN0/YqbEcdMw8WgP/RoPby9sd8BrVCeCU6MpjNYf 5belZtZir82BWGbR5EyO0bUq6gjVUaIMRK1daeoMLbv3TXKTGc8H9NdbZNZKldjl b2WIXHWTNC0wS6xuEeNNasCuX9TvAzpMUOuLtdUBzaGSYqpW2hHW4h6weTL/ytfO moQrbL0C3KZb/K6nPJiwDAbFR+gHk8C+aog0NUFJDj/kvRXHif+6yMyDzFsK8FX0 U5pnVa9/eyoAV2Qc42gruD3PP/VLulua9xk0nB4sDp+hBlqYtOv8IULY0D0J7nTd XwEvDczy4tf60lhoivcIajDxP2CvTAbQSlM+nbPN7kJua6S/5CRlHzaI+cyWiWII za6I3UKcMJP6J8aPg7Rbt/lVhN4xGwYQrSih5cZg3iIzFvuXPbDwg1ZjSzdyK6ya xzd3t2BrOt4yrq3scGw3BcbMOKCvnq5/PiNgw2HGhnkISIAzv1vHcizMQDTHmu97 znlRJ/ynYxXuOinSBqM7Y44mKXx+IwgQBQjBI1TZLHIJYB7MN9+YIuDT7GvGY8r0 20cOS9pkdaYVXNyjRZ8bQkoQ14lCnsHaZ1Kre3fQzhNCuWRcCxq0jKFORnFZ+A+w 8axUENqD1frASvVtFQ0uKMiRXRmk5bIJZ1uJscupAGRWQbV4yflEiQ9eTODH+1Uc NMTqvTumhE5/CdB3mJmF =dIov -END PGP SIGNATURE-
Re: [PATCH 3/5] ddraw/tests: Test DDCAPS2_TEXTUREMANAGE compatibility with other flags
Oops, will resend later. Henri Verbeet hverb...@gmail.com schrieb: On 5 September 2013 10:42, Stefan Dösinger ste...@codeweavers.com wrote: +if(DDSD-ddsCaps.dwCaps2 DDSCAPS2_TEXTUREMANAGE) Minor formatting error here. -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
Re: [PATCH 5/5] ddraw: Enumerate DXT2 and DXT4
My understanding is that we should do rgb *= a in the shader. Writing tests for this is on my todo list, but very close to the bottom. (Sorry for the top post. Stupid android mail program) Henri Verbeet hverb...@gmail.com schrieb: On 5 September 2013 10:42, Stefan Dösinger ste...@codeweavers.com wrote: Yes, we don't actually support those, but that's wined3d's problem, not ddraw's. We do. The difference between DXT2/DXT3 and DXT4/DXT5 is just a convention wrt. storing pre-multiplied alpha or not, there's no difference in the actual encoding. -- Diese Nachricht wurde von meinem Mobiltelefon mit Kaiten Mail gesendet.
Re: [PATCH 3/5] wined3d: Don't set WINED3DUSAGE_RENDERTARGET on the front buffer.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-09-04 08:56, schrieb Henri Verbeet:
We never render directly to the front buffer, and in case of e.g. a
P8 front buffer, we would fail surface creation if we were to
enforce format restrictions.
This patch uncovers a problem I am not quite sure how to solve.
We set the frontbuffer as render target in wined3d_device_init_3d if
there's no backbuffer, i.e., when ddraw is used. In theory this
doesn't matter because we're not rendering to it, just blitting.
Similarly, dlls/ddraw/device.c calls set_render_target to set the
ddraw frontbuffer on release. The call fails now, but that doesn't
cause any visible problems yet. There is a zombie wined3d surface
left, but it goes away on ddraw shutdown or when a new ddraw
IDirect3DDevice is created.
However, when we create wined3d textures for standalone surfaces, the
ddraw surface isn't destroyed until the wined3d surface goes away
because we're waiting for the callback. This keeps the ddraw surface
alive as well.
The ddraw tests notice this because keeping the IDirectDrawSurface
alive means keeping an IDirect3DDevice1 alive as well. The device
holds a reference to the attached viewport(s), which triggers a
failure in the ddraw1 tests.
The test failure was lingering before, I fixed this by adding a
similar set_render_target call to ddraw_surface_release_iface_destroy.
See the attached patches for reference.
The easiest solution seems to create a separate dummy render target
that ddraw can use to unset application targets. That still leaves the
problem that we're initializing wined3d with an invalid render target now.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJSJ6NiAAoJEN0/YqbEcdMwqEsP/3We5UyaUsuUmh8DuqpUDozy
OPFdfg0defIGBB3xdcRPYtwz265jsThxK8ek/vb24E1fJXJsm7zE1CJq1jUh/Beo
X1zkewvL29WpriNvh11AW0+FIrE2XMwmr/5ekHQMXM4Evv2aRWG6zmWj0Wv1zR+x
EcFgHE7J6boOIHtogPoge8KHiVULjxm91Dpnariab0YzUNDUfaHUXopWH0N4hb3T
W5ds4cnHLOapOk8ihDfyAcBXOH4JlvConKKG4zDtbcuovp01yLR+eF03m/eBqt5m
0x3VpPyyaIJpFtOERAi9CqbN0Xuy3wOLmtgHsjy8Qh1wKr/I+DmkuakcsJYELmrY
Ou7n+fDRceJyxdqP8vGtwlsP7Skkyxet/KYt7xbWsMcIcMjFDv6KW6YMyOGg2aJM
O4o8gEFH3zgBQqLBsOf+O85GbQ2ZTLFoRaWkbRYFYYBaypd+S4TBRn9i0gL0Qw/q
KImvYV47HcBK0uTuuV0dG/2YzUs/JraKGMU0sVmUNiDqfOm7+R+NAlU86jQ4PNo+
G0cV2IpEt9Bk/06XmSWI944X7NTe/ZDXs8Fa5MveLk87wETzg54F3RK2AoyHPY59
UK/3nisrRmUDeRZHiRp53E6eSW7VSXoHUgqeHt04fvLheMXpAnuibKJcKGTYqYMe
kfkNuq73chpb9uZhe0EJ
=PCrO
-END PGP SIGNATURE-
From 14219846c7e4b8b2b95fb26221a99c5144437fec Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Stefan=20D=C3=B6singer?= ste...@codeweavers.com
Date: Mon, 2 Sep 2013 17:46:42 +0200
Subject: [PATCH 10/13] ddraw: Unset the render target when it is destroyed
Reply-To: wine-devel wine-devel@winehq.org
---
dlls/ddraw/surface.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/dlls/ddraw/surface.c b/dlls/ddraw/surface.c
index 62d3218..037ada9 100644
--- a/dlls/ddraw/surface.c
+++ b/dlls/ddraw/surface.c
@@ -495,6 +495,7 @@ ULONG ddraw_surface_release_iface(struct ddraw_surface *This)
if (iface_count == 0)
{
IUnknown *release_iface = This-ifaceToRelease;
+struct wined3d_surface *rt;
/* Complex attached surfaces are destroyed implicitly when the root is released */
wined3d_mutex_lock();
@@ -504,6 +505,14 @@ ULONG ddraw_surface_release_iface(struct ddraw_surface *This)
wined3d_mutex_unlock();
return iface_count;
}
+
+rt = wined3d_device_get_render_target(This-ddraw-wined3d_device, 0);
+if (rt == This-wined3d_surface)
+{
+wined3d_device_set_render_target(This-ddraw-wined3d_device, 0,
+This-ddraw-wined3d_frontbuffer, TRUE);
+}
+
if (This-wined3d_texture) /* If it's a texture, destroy the wined3d texture. */
wined3d_texture_decref(This-wined3d_texture);
else
--
1.8.1.5
From 9cb01bbda830b0bc548d254503aac53c437d284c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Stefan=20D=C3=B6singer?= ste...@codeweavers.com
Date: Mon, 2 Sep 2013 17:51:19 +0200
Subject: [PATCH 12/13] ddraw: Create textures for all surfaces
Reply-To: wine-devel wine-devel@winehq.org
---
dlls/ddraw/ddraw.c | 16 +---
dlls/ddraw/surface.c | 9 +
2 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/dlls/ddraw/ddraw.c b/dlls/ddraw/ddraw.c
index 26f1984..99ec4f7 100644
--- a/dlls/ddraw/ddraw.c
+++ b/dlls/ddraw/ddraw.c
@@ -2863,12 +2863,22 @@ static HRESULT CreateSurface(struct ddraw *ddraw, DDSURFACEDESC2 *DDSD,
}
}
+hr = ddraw_surface_create_texture(object, flags);
+if (FAILED(hr))
+{
+if (version == 7)
+IDirectDrawSurface7_Release(object-IDirectDrawSurface7_iface);
+else if (version == 4)
+IDirectDrawSurface4_Release(object-IDirectDrawSurface4_iface);
+else
+
Re: D3D command stream patches for testing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-09-04 16:30, schrieb Vedran Rodic: Using a blit copy to avoid stalling on 12b glBufferSubData() to a busy buffer object. The long term plan is to use GL_ARB_buffer_storage to create buffers that can be used for rendering while mapped. That avoids the doublebuffered buffer thing and glBufferSubData calls. I don't know exactly what the driver means with blit copy, but I guess it creates an additional copy of the new data rather than writing it to the mmap()ed GPU memory directly. It shouldn't hurt too much. I'm not sure how much this really impacts performance, but even with my Dota 2 wine perf hacks [1] it's not faster than current Wine git (performance is very similar). Mostly the nvidia blob on Linux, but also some testing on OSX. I got a lot of reports of crashes on Mesa. I think there are race conditions in the driver that won't go away until I've moved all GL calls into the worker thread. Are you GPU or CPU limited? If you're GPU limited, those patches won't change anything. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSJ74YAAoJEN0/YqbEcdMwtOEP/R70M0MDrQcwwYVfE6JO5oqN ilBs6sWjcYing2ynTwD7jjHjEK9HuO89gOmVW1khD/gBEPAwSomrCW9AHQKhDUra ycx9smrE9zqejBvpXSPYQQDgy9u2D6o9pY243+veAhNcuk+27GmsLBnZOWs2ggAP P93pNPCS3KTqd2aGSILqZ0fmHipommvA08ftNKfVTC7eqY7p+w6gatuJVKtjBDBd ZVo5Em4x+UCwjv0Vm/qIHiA2iaspl3aZr+TKIlmU8KuBoO/O9z4iDhHwa70YlBss mATg9yrh9eFhtIX5aIolS62GfpbmFApjzllULjJzJ0PYz51oknBAlVEG2emKvqmg JrINQJrv/u4OPBU5rOTH8A4XdAgFjN5nVVrF2Yhw6su6z7tyy2xS11kcOQiTTs9R U2s/EaqiKIrK9wu1Sq2Vwb8afoBgGB6eBTOJJTaxi7+IkbRh9KBy5EN5s38LyvMe JtxUS4zMeaIDIePM76nBYZAulo62p2vDDtrlTIigt1FZEpth3oCV9WT1l23SUV3C 8dniiSZoxOh8G2I88J3FjbWd3CaBktS6zsAUuw3r8kL/TzeOwXXVIQeZSZxd5TsN 64GmvFm7RpOncnOb09EQmlgx150jRBi9kTfDfokryfnHdNVAhamIuPxX6P8QY4bP IJL8AEIU9lLa/z4DVzWU =vcwM -END PGP SIGNATURE-
Re: [PATCH 3/5] wined3d: Don't clamp texture lookups in the GLSL fixed function fragment pipe.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-09-03 09:47, schrieb Henri Verbeet: This originally came from the ARB fragment program implementation, but I don't see a justification for clamping there either. For the texture formats typically used with the fixed function pipe clamping wouldn't make a difference, and we don't have any tests that say we need to clamp. The idea behind the clamps is that the fixed function pipeline is generally limited to the [0.0;1.0] range. bbf313e7 added a test for that, and there was e.g. 14706 (which doesn't contain much info tbh). Personally I'd keep the clamps in unless a test says otherwise or there's another compelling reason to remove them. But since it is quite unlikely to matter that's not a strong opinion. The ideal solution is of course to write a test. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSJciCAAoJEN0/YqbEcdMwQ2gP/Ayrnyv1b7VmviOCBLdKpW3P YjEgLSFtaiEMGjJ6DD3iTLTRBaMOWZIryKyXdE5QLecKx35xuk6GbC+OAXgCCZfU a558nJwymMtMpiU9Wa2nuUXF4p+KuC8CHkCgfOGF1D4wDZcQQxfEcvKcwAGPaZwV PWiKKI8SWO69XlawZHOLyWz97gghYpLrHIexOxbCVXGMXee7pqAQTSz2oRVppHot 39T2qbFo21qtoyK7sgqMgnRko52eiJGSBVHCfcfhhMPh+mksQvPoZDcdK/KSAl6r K5Py0kbVjBDjE9I6uCGO9+bt6a6RrJpC/6JGIOypDvicnjd/7X4LK8SYfGv3Cvr6 qejlsAouxrQgdYARrdjnoR4IEK8WviBzOZDnvxOS8dlEsJxjMjxIScnemdNacNKO QY3DJ/GmfnsnOXnrrvADKkLvCkeIUCE5v6U9Kv+S9GsMgNeJs1IEHzQpROBmt/iO ukUH+aOe4JReH1mtynrX+GsjwZkDPzatx48SxOOopWW5akiCbEsJNFirR4m1St9E 5+iOCkGQkjWVz95XgZt3VRpUBxx12JHsX1/UscBmprvkutmbUOYvRIpgqdTyZknD dW4x79KWQ6YUu3k8Lho8EfChR8rzPoDeaHwclY/WrwE+yuHugk+z0dv/gclC3eiL HAQ0T8GuuElJvdPfgE3F =8XAf -END PGP SIGNATURE-
Re: [PATCH 3/5] wined3d: Don't clamp texture lookups in the GLSL fixed function fragment pipe.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-09-03 13:41, schrieb Henri Verbeet: It ends up being a performance bottleneck in some cases. This is particularly visible in the 3DMark03 multi-texture fill-rate test, in other cases the impact is usually a bit more modest. That's interesting. I'd say that's a good motivation to remove them. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSJdGuAAoJEN0/YqbEcdMwapcP/1vrDRVNZiG8OxbpJdKrcAnc UhOBAFGgQynarSu/clL//ln5HPxpttgD5sK75U8vCbuEg+4pJpQb7dfnNRGYekSP n5ntF+I8PfoFZC5bbvA2L4MLO/Svoev8Ti/nCl9/Mi+vpwTulFYHIZiIl26RrLXF LgnfFfx6OpICRss4BA6+UbDM5XdAOnL8I5m2iiRXTafZTeIPdBU0PhGN8lQeReuK ayFWQoTAG0Hq1g3RXy5S2v/tF4nEvAEpvQuw6PHWNniu9lG1wejmqpZmxs886vRX RBtSTD3PzbJY3+w4A0atvBhq6xjP9hzMv5Gl6fUf1SdliEAd2Jsf+xW8gb5eOuGh Ng8uAqtoYAEcKlUoa3yAN+iYA0ECa8q368BQLCZmaOL2vrPdaIWN04pTXAZ7Ybgt 5Nz3pA0iUhjwZo5axvG25EU6eIBVlGt8ajZlRjKxG0Czom+eL3NaG483mIVTD+J7 WTqfe3mH0F4uDt2ZF0WDY3TXAo08JoyiFppn1F3xQXkbMY3DASV8MDba2TMh2dBc rzQSrX98lA4gMG3geVgJeGMiHXNVnkZrOX/lOKKtOM60ARRlm3a6n2HDcuDhKMfK TfE2jx0ofRrZ/MysQl4zY2mZUFUhE5xkvUjwZPR4WXOcMeWu2uLT66Zzn6Fb8w4i OvpGr6YLpMRI9IvPSy4H =yVNO -END PGP SIGNATURE-
Re: D3D command stream patches for testing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-09-03 15:57, schrieb Rosanne DiMesio: On Mon, 02 Sep 2013 15:55:18 +0200 Stefan Dösinger stefandoesin...@gmail.com wrote: You can test the attached patches by applying them (git am /path/to/patches/*) Third patch doesn't apply: They are against Wine 1.7.1, not yesterday's git. I haven't rebased them yet. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSJexEAAoJEN0/YqbEcdMwGk8P/0Q8N0OWjO0PfdmiQjfJDE8x 4Uqw+om97nE9TCl4gyT32iQgh2bzmd4+FYXJnJ1aFL995iYO/Vmqxy62chmnD9uq 4wH0T4PlHQDn2gA9nWqhrTWCjVEwkhJCM0I7+SD8jzCELgtIS6Ggb6BBNh6Bt6nZ xC97uvejM4ann466I2lii86kNN8zGQwyenZXaimLc8RJptqmTz0xV4adr8WDGINO 2eVV2YwGWBZo8RCQXCQdw2fneCIL325JxlZ3l1PX+tVUhLKRcg2AxkcnL5TsYuRV ZzlQ5bpt+aaFAoqqGpy2vrBwiaJjidXnwVNitzfdKDU2QN5Z513COJF0nmPi737z U+sgDh1Sl231KPlVMrkbQvRujyNlmf//ufvBYPYuFrBys1EFSGht7zCS8tpKG4+L oFR+K651bA8T4nJZuNGmOk5E21Xfzy+H+W3IyyrXbskka6CJEpvfTH3EL03iaadW xXzQ1+H4FKvewDYG2bVmDs/6SX7S8voA6gdg2mNLZzYkHh2PTh1j0Zq4FThV9STt I5KriTDxR9ZBBJIJC0C2YgY4qkZ0sIWyHhJ/gX1I2g6Um+DJfhlARYDYp1IEN4/I SjUQePGKdQKPzNjcVGilvf304Cz3cHe2MHZx6NN+LZ/0Hec3QGGUtuOndd+Q++mb Q5uh8m0TrRJXM70BPrmg =LGn/ -END PGP SIGNATURE-
Re: [PATCH 2/5] d3d9: Check for support before creating textures
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-09-03 17:33, schrieb Henri Verbeet: On 3 September 2013 14:07, Stefan Dösinger ste...@codeweavers.com wrote: I'm checking this in d3d9/d3d8/ddraw because we create textures for everything nowadays, even stand-alone surfaces. For ddraw that's not true yet, but I think my preferred way to handle this would be to introduce a WINED3DUSAGE_TEXTURE usage flag, and then handle the format restrictions in resource_init() in wined3d. I have a patch for ddraw that changes that, it's one of the changes necessary to make the ddraw version of this test pass. My main issue with a WINED3DUSAGE_TEXTURE flag is that create_texture(USAGE_TEXTURE) seems a bit weird - we might as well call it create_texture(USAGE_I_REALLY_MEAN_IT). The other aspect is that the capability check is the main difference between SCRATCH and SYSMEM resources. Having the check in the client libraries makes it easier to handle SCRATCH resources in d3d8/9. Admittedly it is not enough to just handle the format this way. The POW2 restriction and maximum size checks would have to be moved as well. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSJgQ1AAoJEN0/YqbEcdMwU1UP/RrVyhgHnisRuhzIQYkRLeaD jLR2MF2q4f7d39TnmuezL9pZD2xJrlwlKt+K/kM28h6PTux+I95uqMazVxX73+YO 2vyxLrNQrsuTUa/mKvGltxt5NiequQnyP6AGj5FV1vosfNzplJdz8Zrloo03SD/R ZrBvyT11C88PdEY0hd6N9m/RQMzxeSJpMHIL9jsu2AjhZHNVSC8O5CdtuOLsqQOu jWJH+6MhOlAtfmntR4iJg6tUdouDcHZFMfD4ThJ6yldbf7l32L6ozjhm/+yGzy3I BV9nEmUbp78pKbVQjQBvJ8aFEJMmiEX1SCuSgWdq/XgCuZnmUhGgkXoU3MKSSWzu i3+1PX2iqa7XqtgrtPbGehxdCWhZuAm3B4lTOF7+Sky6hd7AnQYUoEZqUIsp551H 2qLXpFgHUCzJR6d36FsW+uODCdcX9V6RYzY/JNqU3dpVrxOUts1Yn/HIow40yN1x 4+m19wZ8EYuEPPjtBp5RhBMi2AVhZgaDXSOdIvFmTHeTQ2r8KhDR0jQKIrVZBVXX ZUoLXu8SKSVNKy9BCwUrC79zGGpG9UWsc3dJXwbOclT+7dAuUUrYn6kiyGi6j7cA UK3KQ1JV1pl37ePyyFSolOjmKzHY4dlD6Ov5Tcr7NQKd6PZt13Wn3HNyKIFHrfRX fZIWpjCeoXRvRx6ieGdA =Ljrf -END PGP SIGNATURE-
Re: [PATCH 2/5] d3d9: Check for support before creating textures
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-09-03 17:54, schrieb Henri Verbeet: If that's the main issue, I could tell you that it will most likely end up being renamed WINED3D_BIND_SHADER_RESOURCE at some point, equivalent to the d3d10+ bind flags. That works for the name. The other d3d10 flags should take care for most d3d9 flag combinations. One open issue I can think of so far is how to represent D3DPOOL_SYSTEMMEM. There's no exact match, since it supports CPU-GPU and GPU-CPU transfers. MSDN isn't quite clear on what STAGING usage means. Lockable render targets (and dynamic rendertarget / depth stencil textures) are tricky too because MSDN says CPU_WRITE resources can't be bound to pipeline outputs. I guess that will need tests, and we may want to ignore it inside wined3d. The rest seems pretty straightforward: *) Textures and plain surfaces are handled by setting / not setting BIND_SHADER_RESOURCE. *) D3DUSAGE_RENDERTARGET and D3DUSAGE_DEPTHSTENCIL are handled with their equivalent bind flags. *) D3DPOOL managed and dynamic default pool have CPU_READ | CPU_WRITE set. *) D3DPOOL_SCRATCH doesn't have any BIND flags set. It does have CPU_READ | CPU_WRITE. Usage could be STAGING or a private usage flag, depending on *) Non-dynamic default resources don't allow CPU access and have D3D10_USAGE_DEFAULT. Either way I think a D3DUSAGE_TEXTURE flag should work for now. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSJkrMAAoJEN0/YqbEcdMww0YP+gP8QdgAiNpRLBBSMwFQDPuN 7QdUX14v6f6dk7WpT4ZLJ6NwVPdMFA9P495f45cBim0G4NWdUKxhvkdZA2/lMrYH Gf0I4Zfp0C8aio6HElz+0h0RJ4nCFCjv/enVytCDk5cZfYBU9t3ht7Uoq6HzA6hi FRvFunebLdOl0B/Ps11G2irWlLCq2W39AePnu/G/Nf4L1JNExM2Kw0xMFEU+r7u8 DGCQlnyc1hJLdz521e0BOPAMrtFj/Npn5E21dizewZkzouu2/+RXsCySEXcMOv13 aoBwHGAhqTJHnJTDrEWPZB8p1dHhEWMBvuADbawGovjHtMygura5CrWtAGcREuSw EaTUb4QC2NhBqwK/Pc4WpWirrnHYYHCELwh8kjZXVGghatiV+GfgJvvMVPk7ed3u gdwKfnjyzoRsEIU6W5Fi8iif8c75ipzkMk08uIyWGOqKUDUzVV3ToNCDrb++DOuI eK6NLRJeHNklIHfacoapc5YBc4k4oIuSFM8Ci7CM5Qwv84uRUpht4zcKWv0UhHdd BhMNKEoQdGFijTpueah5y/BMPe+vkBLdcz0gLU/lki38aRMx1DeVA+dPpOYPIvmA 5hG08mff+Yu+NLZDagcSRTZ4QOuQmZq1IQuXwj8KiPYF4cWCi73ARaAzG9U0iqwn onCMoU7APejBmVMT596H =yPzh -END PGP SIGNATURE-
Re: d3d9: Partial implementation of IDirect3DSwapChain9Ex
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Am 2013-08-30 10:19, schrieb Michael Müller:
This patch implements the IDirect3DSwapChain9Ex interface as an
extension of IDirect3DSwapChain9 and thus fixes bug 34252 -
Silverlight accelerated graphics cause a D3D critical section
lockup since Silverlight does no longer try to create a Direct3D
context in an endless loop. The functions
d3d9_swapchain_GetLastPresentCount and
d3d9_swapchain_GetPresentStatistics are just stubs so far.
Good work on finding out what causes that bug!
-if (IsEqualGUID(riid, IID_IDirect3DSwapChain9) +if
(IsEqualGUID(riid, IID_IDirect3DSwapChain9) || IsEqualGUID(riid,
IID_IDirect3DSwapChain9Ex) || IsEqualGUID(riid, IID_IUnknown))
For IDirect3D9Ex and IDirect3DDevice9Ex, the Ex versions are only
available if IDirect3D9 was created with the extended method. I
suspect swapchains are the same. Please write some tests for this.
+TRACE(iface %p, pLastPresentCount %p.\n, iface,
pLastPresentCount);
+WARN(not implemented.\n);
If a function is not implemented we write a FIXME, e.g.
FIXME(iface %p, pLastPresentCount %p, stub!\n, iface,
pLastPresentCount);
If this causes too much spam on the console, you can use a static
variable to print it just once.
+if (SUCCEEDED(hr)) +{ +if(pMode){
Please use a code style that is consistent with the rest of the file.
Tbh the existing files aren't as consistent as we'd like. The general
rule is a space between if and (, and { in newlines. 4 spaces intendation.
If there's a one-line statement in an if, put that statement in a new
line and don't write curly brackets. My personal opinion, and the
style I use, is to use brackets for both branches of an if-else if one
of those branches has more than one line.
- * IDirect3DSwapChain9 interface + * IDirect3DSwapChain9(Ex)
interface */ #define INTERFACE IDirect3DSwapChain9
DECLARE_INTERFACE_(IDirect3DSwapChain9,IUnknown)
You have to create a new interface declaration named
IDirect3DSwapChain9Ex with all the methods and the invocation macros.
The header change should go in a separate patch. The d3d9 code should
be changed to always use IDirect3D9Swapchain9Ex, like it does for
device and direct3d.
Thanks for your work!
Stefan
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJSIFimAAoJEN0/YqbEcdMwbW0P/jC/gsziWzCtxBH1gDETnX6+
j0csX5cORWKCaq/wsPbT9ZDVV/OYFYlWRB0QZiJIUWAp4PzdGXCxQN8srdybT1hp
PG3HTDzv4Kmq57fYSXEoLnZNO/pgfr4JiGmhcwQSyheJ1+lcb5Z/GE09goHwcLce
CJVrIQu9f05TQb+r0BJCxIyGAIuq8to7xdIJ1tPR2MmKwYzS0XWkB1yN8QIGy/Qm
z4aH7JGsOJ37t/90D4eHVBX6EtiI6pRHHiaO3hFrgYiu7wf/CeiE3E9QWnwycG1h
DdPWjreQx+6/JQfg71eXDW81WYgdRl7TfMfBOc8UFh7Byj9b4llR0E+NFSkQ81NL
XAQkB/PthmEpJIH1tSo91aNrZkfN/jw7D1gA4kUHFEtr5n1yuUXQQvKLYEOMWrV0
lV1plnzzLEZa50c0Y3/zCgQFCbzgo47ohO/4msMHOU33n255oJg/Bd6CLoA1oPFq
hxQkkv0bW5VL6Jn0WVAC1FPjfmRF6zD6h9n8KKPWU2rz/tmkoEhoJ0Nd2a483N86
6EvOTpecczmNBlICFvyUOVAisHnVdwk+cPI+6hoqHBq0C7fGXi7R41pDOvf4o1yH
wZyMH4e+kiG+7qaeGRwsTEDW1V77VAbPXJkNZPU2Wvb/gVzLU1TVQ87Bz5T83tpv
tFvZjJrjOYO4qL4Afm14
=zjgo
-END PGP SIGNATURE-
Re: [PATCH 5/5] wined3d: Enforce volume texture block restrictions
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-08-30 17:31, schrieb Henri Verbeet:
On 30 August 2013 00:19, Stefan Dösinger ste...@codeweavers.com
wrote:
+if (format-flags WINED3DFMT_FLAG_BLOCKS) +{ +
UINT width_mask = format-block_width - 1; +UINT
height_mask = format-block_height - 1; +if (desc-width
width_mask || desc-height height_mask) +{ +
WARN((%p) : Texture cannot be created - width or height not
block size aligned.\n, texture); +return
WINED3DERR_INVALIDCALL; +} +} +
Is this different from surfaces? IIRC surfaces are padded up to
the next multiple of the block size, although I may have that
wrong. Not a fan of the (%p) : trace formatting.
Padding happens with mipmaps and stand-alone surfaces. Level 0 of a 2D
and cube texture has to consist of at least one full block. (If my
memory serves me right.)
There are no stand-alone volumes. This patch only restricts the
creation of full textures, not mipmap sublevels. Mapping of blocked
volumes (part-block mipmaps and full ones) is part of a different
patch and set of tests.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJSILvEAAoJEN0/YqbEcdMwV5YQAJF74cyIS4XTQArXg4Zb8QeV
PXva1oNZdUnuDcJFtSY8O5FORyY7Z/xcxA8Paf1GlNXios8griZNdab/RVcsaFDY
pV5xng1xm4dPI8yTGPZJlW9sXs9L91idDGR/NTRYbGOvoa1xXZkToGDUPKOOCfU+
jdUMGJXu7FAz83R4RJ73d/b/LMgguyrw+okYpXcOwjxKbLLt9x6phyw3SfLPPcKz
qKEBxM3H6v3U1FwUOzoh4OpM3fiZdEtFGxZvl1Q75fqmvnx6kXIxChM7TWKIgniK
3g9xGjPDciKdXZCnBww0M9RN45HvVQOSELAj59UBuRgJOZaLg2eReRPeVx09aW/t
Ff34nInTDjL/YML9bgbvJNxC0f1W8OCRiReITujMBkeaoOQ4bRSAbDHHABrEAQJP
eNTYKSgysIAdgaNmguAiJcQ4X+JvkkcaOXsXmEwQj+p9HTC9xLt1NC3L7bCLt+eL
vpS81ve/U+sZgezneihwzQOtmW96I7eC5POAmAk1XodsO+EdkYRdyhOFKg7gXDCq
D7Ge9OkOh9kyHm8qIgzdsO01RPH0el3SFNFTteynBSLTO5TdsEDlyUbsQPX4mk7C
HWQkozpcT8THqes93e4077FpE4cGjCGU/kHbY6Z1jfxDJnl8RpHLrV8gfqxzjedp
4xjEhXWpkiLEvOUXnUuO
=O9F7
-END PGP SIGNATURE-
Re: [PATCH 3/5] d3d9/tests: Add a DXT5 volume test
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-08-30 17:31, schrieb Henri Verbeet: On 30 August 2013 00:19, Stefan Dösinger ste...@codeweavers.com wrote: +/* A 8x4x2 texture consisting of 4 4x4 blocks. The colors of the blocks are red, green, blue and white. */ + 0xff, 0xff, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xF8, 0x00, 0xF8, 0x00, 0x00, 0x00, 0x00, +0xff, 0xff, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xE0, 0x07, 0xE0, 0x07, 0x00, 0x00, 0x00, 0x00, +0xff, 0xff, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x1F, 0x00, 0x1F, 0x00, 0x00, 0x00, 0x00, 0x00, +0xff, 0xff, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00 In general we're using lower-case hex in wined3d, but I think it should at least be consistent within the same test. Bleh, that's what happens when you mix copypasting from a hex editor with typing off certain parts :-\ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSILsbAAoJEN0/YqbEcdMwUqYP/i6zGdefv7x8VPNpuutNbPu0 mFFBGmmVjMVp8jrj38jjck1E2MHyB9qETp0oG6RJAg0oizPWOtomE8L97ifh6uKb N5/GXnlg745DMzgKrx6AtH73bJl1V6yft7COUFECWX6plLQWF+a4KLfIG/Wko/88 1evSuqhqlHzTz03BUKgurqC3s+IZbc3fIbYvwibCjGTYzCqNxkncWyNhRUNeHHuo 4t7tMv5/oh3w5lkS43Bl8EoJC9RcGzODFqR64qMXQA6MECCaXu0oFOqOGVjHmQN0 ZxBk41Oz0an5Jk5fW4hJXozpUkMXzxTj+8me+Jnxw/4b2X5zaaT3v7mDQZan6NJJ rHFEDHqr5W3fphHQQ140EGnERbYExKe85Brze0+CL8OHIehTe4XiP6Xg4cmd3Ozs z5A9hUVZWF6QS06tSJxQ16+6SXQ+3YbWHA93EdWaYmlnnXqVyz/6U0e9yYc8d7yq tpo/y80Bs5KhxTXNO5NMa9OuXNwvQy/Zcx+cS92oW50/y+FWv/0xCNpaCfmpBNFE cgdP2CoDBUTKQrFLYFO5f3hld2r+NIXGzlkr/mv0iYhvZbMTUuNiQ/T+H/S27NkT ZIJjcsGqzAGaeQoVKjUhc8lPMmYIeR0vxmh9Z0k9FZ+iCIJ03RJAfNx8RafjZwdb yd3yMXM8VPSBw8qk44jS =gtFo -END PGP SIGNATURE-
Re: [PATCH 5/5] wined3d: Enforce volume texture block restrictions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-08-30 17:50, schrieb Henri Verbeet: Well, regardless of which one it is, I don't see a similar check for 2D and cube textures at the moment. I think some tests would be welcome. You are right, there's neither a check nor tests. I am certain I have written and sent some in the past. I suspect they got lost in the discussions about how to best handle non-compressed block formats like YUV. Ignore this for now, I'll resubmit it together with the tests I have. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSIMIbAAoJEN0/YqbEcdMw6ykP/3vdOX0PWbC5drr3LRcOu+2p sUBc4A+uq/Si8rEQz4XGqjrPSYavIrtjO/LMk5aQ1CrB/K0fAne25mxf+A0f5g/b yMlia2UfAOIoSEpu/XkdtqPRx/VOC0002YhLA4VTkchCTHdmvsnsO6JyNIXmUjmz Ts4ubUVG0c6eGS/ABw36oSZk3vYL66rd8B1jvfXhVEt1FqKeBQIqqbBT1PGRRJKr H2aVjFuiz/elSSk6IBfztbcLb5DV46dP9h7PF2xR+YhLfGZnl0UgHj0r6GyfabrF TwUOqzsDkjwBH8mZVcWaciLBBqXTaGgLrSX8zpsjNTgXdpeARNRHbZeXdB0MmLA3 EZ77EiThhqmxDQNUGrLEl9AVhHASlbv7MLKQDlPqpQS1Ai7AJxTdSnt6ff7YyMNC YBEYn8KQG2C0mVdwFeN0wqcOZYquO1MpXspB2ouGjzUzay2yFPRSmcol/s48Opyw V7t9q1EoMmnG8Hw3QjFa4bYXwyfcChQsk/mLbK76e0iGGi1gw1uo7Hwr//M8xKrM 8JTdJhyKNsdH9miLHFlWZ3NFhne/cQwVf7GmZvhtfMBEot5sAWraTsZIuNYYj9RY RcEXsO9YpsZLHwqw/hCZ9/uDzpttxC/05dGucnK7+EDu5P5XwEdzzYD6VqRpSYHM FuD3i6T9Yy8+oEHj0FZ1 =q9pg -END PGP SIGNATURE-
Re: [PATCH 2/7] wined3d: Use PBOs for dynamic volumes (try 2)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-08-26 16:16, schrieb Matteo Bruni:
2013/8/26 Stefan Dösinger ste...@codeweavers.com:
Try 2: *) Require only GPU access for buffers *) Reduce number of
checkGLcall invocations *) Remove a return from an ERR case ---
dlls/wined3d/utils.c | 1 + dlls/wined3d/volume.c
| 168 -
dlls/wined3d/wined3d_private.h | 7 +- 3 files changed, 157
insertions(+), 19 deletions(-)
+case WINED3D_LOCATION_BUFFER: +if
(!volume-pbo || !(volume-flags WINED3D_VFLAG_PBO)) +
ERR(Trying to load WINED3D_LOCATION_BUFFER without setting it up
first.\n); + +if (volume-locations
WINED3D_LOCATION_DISCARDED) +{ +
TRACE(Volume previously discarded, nothing to do.\n); +
wined3d_volume_invalidate_location(volume,
WINED3D_LOCATION_DISCARDED); +} +else if
(volume-locations WINED3D_LOCATION_TEXTURE_RGB) +
{ +struct wined3d_bo_address data = {volume-pbo,
NULL}; +volume_bind_and_dirtify(volume,
context); +wined3d_volume_download_data(volume,
context, data); +} +else +{
+FIXME(Implement WINED3D_LOCATION_SYSMEM loading
from %s.\n, +
wined3d_debug_location(volume-locations)); +
return; +} +
wined3d_volume_validate_location(volume,
WINED3D_LOCATION_BUFFER); +break; +
Not really an actual review, but that FIXME looks wrong
(copy-paste remnant probably).
Right, good catch.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJSG4LPAAoJEN0/YqbEcdMwGAwP/iqKhyveAbNI99/ZIGAIqrEj
qIcDBaeOLm6Y/17lW2VV6WqU/puRragzyN6IgAA2ikE5F68avBoYAIDuX2EOPsdm
Szy8ssm814aSULRGomzKv1ABWi0dtBU+SqoDj0o5e3k5JHM+R+3A3DglvdWfXfav
pKdi6nPuKEwJ5KM/lEdeAT6iNSjbtXlF/6FWw2DNwgQf8Tm7wbiQp5CqCN+9ZYtB
X3/uvbsGoBLgH/XGeB7P2CM5WL3hldCqjpAbW7HI9Tveg6iIvv4SR3fraMIfBmKs
CCIbLbuWOCFaKfTJFD5mVowdREOJgPLbL08UCYCPiMtaFY0wGDZinAsTBOYMJBLH
np9PyaftGJQ1uoSizk+7bIHMOOvtN+pBi+hwVqM2/wwXgb+lD8NUwmivMcjHpaH1
ofUZ6ZepFWP1mOEV5Lsr4ioAteSbcq8ExAziXfSyFQQp2WR6vZhKZXI3CWvEC5Z0
LiY1Bmr5M5shTwAn7RB3uGNTPU5G0qHN7Buz3fmycJGTPNwAfTzh9GRdEu9OdP9H
QZ1D90S68BgNXWpiShyjsCnWfEq21JV98058OOaELQMrRNcMFizitBup1t4KkO7J
Qj9KDgUcQ0czeuze422OPjfODJINeDpebtr21RNFO3v8+9+JJO4xYAToN3tq6HGW
04W0HIj+a22vGYBiY+pQ
=JWIJ
-END PGP SIGNATURE-
Re: [PATCH 5/6] wined3d: Use PBOs for dynamic volumes
Am 23.08.2013 um 11:34 schrieb Henri Verbeet hverb...@gmail.com:
Why does loading into a PBO require CPU access?
The only reason why we want to store a volume in a PBO is to map it, which
requires CPU access. If the volume doesn't allow CPU access I don't see a
reason to load it into a PBO.
Well, there's RGB-sRGB loading in case GL_EXT_texture_sRGB_decode isn't
supported. I am handing that with a temporary heap allocation and don't go
through the tracked locations to keep the matter simple. The correct fix for
this problem, if it happens, is to implement sRGB_decode in the driver.
+case WINED3D_LOCATION_BUFFER:
+if (!volume-pbo || !(volume-flags WINED3D_VFLAG_PBO))
+{
+ERR(Trying to load WINED3D_LOCATION_BUFFER without setting
it up first.\n);
+return;
+}
I think there should never be a PBO without WINED3D_VFLAG_PBO being
set.
Yup, but it's an ERR path, so neither condition is supposed to ever be true.
The thinking behind checking both is as a safeguard for future code changes.
I'm checking resource.allocatedMemory and resource.heap_memory in the sysmem
case for the same reason.
There's also something to be said for leaving out the return,
since that would at least in theory allow the compiler to drop the
extra checks when compiled without debug messages.
Good point.
Re: [PATCH 5/6] wined3d: Use PBOs for dynamic volumes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-08-23 12:29, schrieb Henri Verbeet: On 23 August 2013 12:04, Stefan Dösinger ste...@codeweavers.com wrote: Am 23.08.2013 um 11:34 schrieb Henri Verbeet hverb...@gmail.com: Why does loading into a PBO require CPU access? The only reason why we want to store a volume in a PBO is to map it, which requires CPU access. If the volume doesn't allow CPU access I don't see a reason to load it into a PBO. Yes, but that's more of a higher level policy and wouldn't hold for e.g. VBOs. You handle that by just not setting WINED3D_VFLAG_PBO for those volumes. The rules for surfaces and volumes aren't applicable to buffers anyway. A default pool buffer without D3DUSAGE_DYNAMIC is mappable for example. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSF01qAAoJEN0/YqbEcdMwUFMP/2WONMZuleeqh3cdEPr+px9m BdyQ3vsXJxmFPGRMx2+hU1jrISLKfy7sgQ6Q7/884eZPFTiIVc6icD60ySK6iUVt lKU+M+ymX88icMyVaN8AUBqP1oVTlXFVHqMpYQAfm8O4I5OTliAaiYp50O/AtAvl I/5P85eUUUxhVXFFfv7+XkErMJeFlZ5plWWHZXXZnG4rJ+4neAR4CPVnwJ7h92Gk 40U5GHmIAw0NwZBKVjj+HuSAUVxKV/ssx1zpXtDC0zaaOjPP7Zpt+LxjIqWLeiCi WA+FN4zbg+njU2tpUBemFwIPFPBQLu9vZWSxgyhP/Kxa6SI19dFTMTKRl3SyjJo1 HSfAy+qwyUmIJ/y93PgT6MSj5siJfF2gDUpZhrSf1FKkCa2l7FrTKphOVSatVyPp A6s76N2FofRG93+x10Wrd5Xsf1w5lFBRjXiGdyY1cCFzfC8z/y7xn51HLPc59c33 kBCZsmy+lYz1fOzhLRh1FTt/q8H+DpAucTxjKQL1jPTFRLzUKW4P6CiNgK3C2yqY SJ2BIEaUufq35lD3xO6Aj5HUvCE7e2tNWvQtgBHi//Daz9DbxcXqR1DnkO9gbEAb 7AT/2taH643O+vR9EDOdeXBGFQDhFrX9ueF+8J9jL6BCEENTw78eAe5Fc1yblyNg XuBJ2Za2sIR0p2iPF1Gy =DCmb -END PGP SIGNATURE-
Re: [PATCH 5/6] wined3d: Use PBOs for dynamic volumes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-08-23 14:01, schrieb Henri Verbeet: On 23 August 2013 13:54, Stefan Dösinger ste...@codeweavers.com wrote: The rules for surfaces and volumes aren't applicable to buffers anyway. A default pool buffer without D3DUSAGE_DYNAMIC is mappable for example. I don't think the differences are insurmountable, but the main point is still that I think this is the wrong level to enforce that kind of policy. Ok. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSF0/9AAoJEN0/YqbEcdMwmCgP/RmR6JR90aHjc4AzKD6lS1MG Pmz0PFzsgxvtoNmX+jHRPhwu4QBCXXzwYUaBPhilSZIBUwnjFOBVdIFhMzG3k3hc xJFNQfbc4wiEagNjZp5i6o3RZLrq9gfoUaAvySMekW11MkJarWTE6getgZJrh50z 9qEB2nxxYS83EVC8iP3WTsmJ0BI9X3DA7a4EU3dnMQqlHpAUA/mMYddy3LbBC0h5 mvYXVGLJEAMBQU4sOcx2rl/MxqIQqQcbqUT04+1U16uVJItB2QgSTAsVKAbmw6N/ uDImq6ISS+6NYpSEyrXPGfMUKJ84GBzErqLMIK5UquvOXARu0pkgWytICwpbRgfx wlMnSMq7rhxNmugb8BDvbd9GnwVXmio/uA6xix0Iop8xoLpun5xJMMeyXPn9HCFH S2Ph4tuMpY6ubUehziN1l9HiUAjy3CEghFESv/kD83GwogEQ13NJlITNowfUcbps XKZOCSuZfUe9PkSWAYJw2wbwFTbjASy9tW7M03fj0jHlKJoQUhYZL6HF0IHrmDpJ KK7LyqJaQh4AT3DtVX9YVVPubqKWojDm1iwuuAMv6BF9PNY9aaX98TYRaY9OzJ3g N0qy9hQXvDXI8IxeuMrzEmmVRMz34s7cl9fegOCBuErbfsDasZP5r75TpFIkhc/V 0hUE7kOMV8vKwCHdS02I =SzlX -END PGP SIGNATURE-
Re: [PATCH 5/5] wined3d: Implement basic volume location management
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-08-22 09:11, schrieb Henri Verbeet:
On 22 August 2013 00:30, Stefan Dösinger ste...@codeweavers.com
wrote:
+const char *wined3d_debug_location(DWORD location) +{ +char
buf[238];
That number looks a bit arbitrary, although I suppose it's at
least large enough.
It's taken from one of the other debug functions, so yeah, it is
arbitrary. The amount of location flags will grow with future patches.
+if (volume-resource.pool == WINED3D_POOL_SYSTEM_MEM +
|| volume-resource.pool == WINED3D_POOL_SCRATCH) +{ +
if (location ~WINED3D_LOCATION_SYSMEM) +{ +
ERR(Trying to load a sysmem or scratch volume into %s.\n, +
wined3d_debug_location(location)); +return; +
} +}
In principle we have resource_access_from_location() and the
access_flags field in struct wined3d_resource for this.
I didn't know about that, I'll change this check and the mappable
check to use resource.access_flags. I can't reuse
resource_access_from_location until surfaces are migrated to the new
location flags though.
What I'm not quite happy with is WINED3D_RESOURCE_ACCESS_SCRATCH.
Scratch resources are mappable. Having the extra location just
complicates things and I see no gain from it.
Surfaces are much more difficult, fixing volumes is just the warm-up
:-\. The rough plan for surfaces is to enforce mapping restrictions in
the external API, but ignore them internally, so we can do things like
update_surface on a non-dynamic default pool surface surface with a
converted or color keyed format. Maybe staging memory can work for
surface-to-surface copies of converted surfaces.
+if (count_bits(location) 1) +FIXME(Implement
loading two locations with one call\n); +
I don't think we really want that.
You mean just drop those two lines?
I'm a bit unhappy with the persistent flag to
surface_modify_location(), and this is essentially the same thing.
I think it would be better to just have two separate functions,
wined3d_volume_invalidate_location() and
wined3d_volume_validate_location(). Perhaps
wined3d_volume_update_location() can work too, but in that case I
think it should take two location masks, one to set and one to
clear.
Ok.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJSFcSTAAoJEN0/YqbEcdMwx/0P/361Sz0YfrOKDwjtex5mddmf
L4IVlDb+a3U+Qwg1H7ecEMTaYAdxSy2WEsUn9MSZU6co24ZZcylSWG1ptaOJ63t+
QYVbsjtEGeLbEimUmywvjCfRxsvVbUBex48+Mc5yx20dNywbpJLuX2OfCUBOfpOH
Oh1AjmBmsKpEP4f06AAlUnEvKq7NmNO5ieTrklYehPUQAU8Fn94h5TgteEpoLJeW
N90nV0GoIrJi9S2O76MvVG7OkTZn2kqaUO74TyJUqz/IDRJrYsqtftcjHgibR3OX
jwPZu8BClCS523VWQppIfsQj2O6Q0k95VXGRMfHqasdBz79SRG4Ix7lDaSoqFb6B
r/tS8iA6ppTeWxWfhJYC81griA5RSWTWpUXuD76Bl6qBjpnX+kDFQNqV+5ls+1UB
IercXePRE964TtZO+Liihv2ygWiKPC9K0HLH/P7bC3znoqgVT2fyRLOdHPAAnnY9
w2PWqtb4sjSnisMsL6+6s3Q/FdKU6/fmS85Zau5AreNs3wX7UZgOZSA2wstBKknW
bjgAz+pFwkQWgeS2KkDC5Uv8SjAew+Ed8fU7LQl551Hwj+JY77cHBiPGaLrKOuO6
t3dN6Q6kLbz4qmW8ZWZeCQIk3V7c2fFsLdTQDc+CcVUzPe/kxXKf1A8+jt3N4LBy
j7dOZKslfvnvUUDh1zYo
=TKW/
-END PGP SIGNATURE-
Re: [PATCH 5/5] wined3d: Implement basic volume location management
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-08-22 10:25, schrieb Henri Verbeet: Yeah, I'm not particularly happy about it either. The issue is that scratch resources allow some extra formats over sysmem resources, but can't be used for resource uploads. The idea is to eventually push the concept of pools out into d3d8 and d3d9, and just have access flags in wined3d, but we'd still need to be able to distinguish scratch resources from sysmem resources somehow. At the moment I'm thinking the better option would be to pass that through the creation flags instead, i.e. have a flag like WINED3D_SURFACE_SCRATCH, although ideally at the resource level. I think it's best to check the pool in operations that accept a resource as parameter. We already do that in most places. Update_texture on volumes doesn't, but a later patch in my series fixes that. And yeah, long-term we want pool and usage to go away from wined3d and stay in d3d8/9. Wrt wined3d_volume_validate_location and wined3d_volume_invalidate_location: Should validate_location(LOCATION_X) just add LOCATION_X to the valid locations, or invalidate all others? (i.e., should it do a logical or or an assignment)? I currently implement it as logical or, so in some cases the caller is responsible for calling invalidate_location on the other locations. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSFd+sAAoJEN0/YqbEcdMwkJQP/30+RdD61lcUYmTOm8S2vPqR nvcX6DTdcuoKV0I7W/9dg+lOx4tKgll37pSCyp7B0nsXKcHS3keXlvc9gTnNSgu5 LDJRsIc4DYbHU9BR5nbsG7gx6yjWg6LcS63DxIaIZLk0MbhKJaPKs2enXOVPJyVd e8UW2bf855MACPFIeBRI8o5vNH5L8R6jFsXb0P5qHIu1c/L4Du0VAYa3EaFtGWYj q2pAsAfKnjxedERIYIQ33FGHPucXhJ8254+silvgKwkfGLZTF40sKxFLnjxz/XTW eM7kL7LJOfcqcgmpb+wgjfQMNXeNiu3YERYoIwE5+jFB+uPZy0u+WCxpDa8xI8HF K4hpMIW0F01NbG6p/rSJWS75YMjlCJT4w/La0UTbSQ14ML8s+1OtrZBEvksTikFl KmiXhzTNNwDLUL2E9EEboQHsxJZ9AXjOxEm3xlfB2afay5+gPg6Kox2tiG/wyN2M ReGmvpOC6Ddrdf7Bvror1AOVni1h4GTsF3yh/507ea1gU4oaKBz33nz4DPVvvVzD DvHlMQUGenxANYzskqAJT9KygpNuK2bgsBawGxqYKo7DyEF8wO1suu3pzb0vPwiT SRr/VWtD7e2HksrhTjlE5ToLr9nFFO5Xk/dhOzOCetAayBJ5jbil//gtD1fparw6 5ZYIdkWufcxTALuA6ZE8 =Wym2 -END PGP SIGNATURE-
Re: [PATCH 5/5] wined3d: Implement basic volume location management
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-08-22 12:58, schrieb Henri Verbeet: Yes, but if pool goes away we need some other way to check for scratch resources. It's just that in retrospect the access flags probably aren't the right place. If pool goes to d3d8/9, the checks should go to d3d8/9 as well. There's an argument to be made that we shouldn't create wined3d resources for scratch resources at all, but that'd mean cloning a big amount of logic in those libs. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSFfDvAAoJEN0/YqbEcdMwAJgP/j2Mm/gqxQWLpLJg4xSWDBkB jqVndRtd1R8u2ScRYWuzFjuCgBegjCr27WXU4BJdxOJGOvREWVW14lL6fLSY+KCH Z+4XFIQJk4h0lQziTIJ37hvS82IY9gYChZWS3YuePtVbKlbpZBl9RbTrZxgLvbSn Gwr7tud9XjEaKEFchIKXczcxLXR3GcRnfqb6/aYqM58PnMByH42dPESXW9KnjCS1 62dq4HOzvDNwyKxVsn9fHjf51ltTuBph8gATHbFvjRPp2YR/kcsNIHDy9Yc7S+ww gpCjK4ptRtvtNYv2Kv7xzR9OX/7F6V9a4J9LUdd1r9bUQJIbJMga7zPUrQU9m+o2 cl7f6hH+u+VpDL7R2eAXsX+ebCd4rJU3EWM6RN50cc+2nRwK1ghLzu6tFOV16Po1 zzUH57n3/GYEH0AolTgDi4F3K4EIq1Nt9cdQTU51dokzSQqOR56Gfro4wEMxwb+C XsOisLQje2RvjbX+PYqHYRJPzxAZAPLxEbl1iNg9d8MpmOO8wwC1IQhrJ6YYseDk yaXkTgzttq0XUmBMNbLbFmC/SN7N9UaaZFqWARfPYWsbQBpsoxlS49Vg0EAJsrJ/ cznSxDmKPkx+L8P5g+U60oTuchtJTRAUXHG13jYEghMCqCafDUDyNKBtvJEMNlY9 lz+DuMbYfVFJHDsh93Oo =trd4 -END PGP SIGNATURE-
Re: [PATCH 5/5] wined3d: Implement basic volume location management
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-08-22 13:14, schrieb Henri Verbeet: On 22 August 2013 13:07, Stefan Dösinger ste...@codeweavers.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-08-22 12:58, schrieb Henri Verbeet: Yes, but if pool goes away we need some other way to check for scratch resources. It's just that in retrospect the access flags probably aren't the right place. If pool goes to d3d8/9, the checks should go to d3d8/9 as well. You can't do that properly. The basic issue is that some formats are valid for scratch resources, but aren't for sysmem resources. Right, it needs at least some sort of way to bypass the resource limitation checks. Is it ok to worry about this later and just remove WINED3D_RESOURCE_ACCESS_SCRATCH for now? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSFfbOAAoJEN0/YqbEcdMwqvwP/RlJtU0IhJ4gVaDRsIY9Jv5P 6+r+kL2phq6LuBcO/mhid/RqVl1yiB2gc5Mh0PHiAst7Rsor5Ozhzve0KI/Acgwb yYwZzNecSGtIIID+YhVErfoDZGhknUw4luXSIcTH6NTHv9WGg75GErClF4SejfPy N2I0RUElfXDLxQXHcWuftjZcwX7RBkPrdNUbqNAoRQBnXxqkWhbCNTdH4O6hv1lz 4g4nF831JPpznkWURZpdqEmPvDqMdP8j63wVp39TLIqtXMQR0B/SPy+M9YPaLfEL BeeDOSDkY5mvp4OtGIQ1vd//M9TNS4sz9RHUjrTqzc3k4DrlxdPRY6l5ImQnWKEc noNeELLdYUcGUPgwkNLndOuX2jACdWF3R3Y82RXSIEOpuqgmZ+ifAsRqsjmLoj/p l+SyMnDcgMMDhnqxFKrkeZuyDFeJu8h8esEoEuSTjKuWwjv3JuxFE8DSlraJwDVw 6nwToBHMnD0kRZuCrdDocHOHMCCExT8OZJVmUh+JXHufr7IF2g9gf0SkWzr3mpW/ v6PxAZHcD7NbBPg5rCCl3F6goNGtosw8cuvEJzp176ifYONCibpsG3qQuG6n0/wQ vRYcexRWmK8TgU7fxCa4xzCykGkBPeNR5ukIM4iuwjHhx1nLsuk+45v15vyMEbRj DqkYAnjFTWlYNYqSvCv8 =N3Hp -END PGP SIGNATURE-
Re: [PATCH 6/6] wined3d: Implement basic volume location management (try 2)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-08-22 15:33, schrieb Henri Verbeet:
On 22 August 2013 14:57, Stefan Dösinger ste...@codeweavers.com
wrote:
+if (volume-locations WINED3D_LOCATION_DISCARDED)
+{ +TRACE(Volume previously
discarded, nothing to do.\n); +
wined3d_volume_invalidate_location(volume,
WINED3D_LOCATION_DISCARDED); +}
I don't think the location invalidation here is strictly required,
although it probably doesn't hurt much in practice. (I.e.,
consider the sequence DISCARD, load SYSMEM, load TEXTURE_RGB.
There's no real reason the RGB load needs to do an upload from
SYSMEM in that case, although it's perhaps not something that's
going to happen much in practice either way.)
Ya, this is a pretty academic issue. The only situation I can think of
that would trigger this is a read-only map of a newly created volume.
In this case the application is most likely buggy and writes data and
wants it uploaded.
My gut feeling is to keep it the way it is. The combination of a valid
location and LOCATION_DISCARDED being set is somewhat unintuitive and
I'd prefer to avoid it.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJSFhinAAoJEN0/YqbEcdMwWtIP/Ar/RY/qEmuDwuiIbMw/rOqr
nPkGYNaLvLJE8YDfAXcCWFkElMc6r5d/VZ5ljbY9606gJoytI61zghqvJ5+oyhbv
vyUbDeL4IX6o/71QMmc31fkATb7zpClESwKmG43xzktIpFurv5BzK/8JPvmVTn1J
Lzab4LNNhBDwYXZMDk7lJbmfivk3gNDAR9bPT1OuRxZlZkyOKwcnP3KujeXHu4LT
RnBSsWq+RunH5YawS1SJmEYziLszLhpKcOKO6sMqVD85nIt5wmo/UAUloigYLXCT
9uJ7BAaJC7vS65m+rwbaxEzK8RT5jQM7MmyRTBOmMEZ7azkU+LaJ8tdNJVroGiQs
B178SAPUotxUkQ8Y+trjuFfLBBhiEKs/YoYJ7O6/GChJ8Os7Sq2MkoSYsyIF3cEc
n4NokEXihwmISd4cZ7wMcsLxcACDQcuweVwvFLsDD3BBuM3tOCeMXOvTEuIp454d
4b3yd6FP4KJLG3OEs0ritaARfU8pyBa70Wg3KmtFQ41QilzmB0lnOEPYfHDOQmMA
nE44c8vZSe7vCMhgWowllv+el0KdRNW8f5WL/0+e/2LJqNmdqUlmG3p2CYaZls81
1hzSnMIox8LB1PLLnRZADjYiVUApQ2c+VDDOkFWH9rCJTE8usYl0gwoupgbmAXex
3gf85pZfNQqKWSYyk/8v
=8ZRH
-END PGP SIGNATURE-
Re: wined3d: Add a function for allocating aligned resource, memory (try 3)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-08-21 12:43, schrieb Alexandre Julliard: 8 0x68e5fba9 wined3d_texture_decref+0x48(texture=couldn't compute location) [/home/julliard/wine/wine/dlls/wined3d/texture.c:449] in wined3d (0x0032fb28) This is an existing bug, when running the tests often enough with the existing code I get heap corruption as well. I'll look for a fix. I suspect that the size of s3tc volume maps isn't calculated properly. I wasn't even aware s3tc volume maps existed in d3d... Obviously don't apply my patches for now, the different alignment handling makes the bug occur much more often. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSFLEpAAoJEN0/YqbEcdMwJwYP/j4hpY9bSTnYydicBlum7jpn sM13jMPrFpJ+dh2lTWh6NIRyhbinE6Te8rDHVpF5GA4kIs2PLi6Me6Hrl+mThL/M /z4OuBnEyyLgNfaTGRZbK9vGA14oVQcgGHVW6g20kIji1nKMxAbZW9XEIFnAhDD5 gS9HDJ9ODc+ob2YB6ajNjtHPHhzUumw+cmXcVkBKiUqrGjmSN/ost8FV+lFYPWDG exeei+AnzMVL91TEq19YyZRTByWYHTuBTsESdk2yP+VYPXe4akRjqhTCbb4S2oo0 h9aqt9cFTzm4yDeyuooskf+h/evATtpm69CE9GPJIeHYOag6q5BQRlcg/WdyllsY +F+uM7/2L5KmSxHm1nZrtMzSJkGIDy9v0eJ+oN+Z/r5A6Bjq9TZNUkMarnCm0D2x WfPVupyrWS9rW8EttnbAhz+kv2mdVJYKbizX5lJiF9NMla6H51fhc52L693ftrU1 iCRdXDBvvDvaUKhM14IA/TQKNOR7xvEjykscdr+1mq8j5OmU2obFNtn1z8cQXugf 0kbTURPzEUz+0eR8jk8G3ckJkpPnbqJv7mL9rtYVv1TRv6WzzA9BcxCS3+fQ+6cA v75rukox2fqgf2SGpGvGp3g6mzeYI7R1mM4iLLoZAZuIhvjINGly1HSrJyQLIrag IB8m1SNZAhWdci3U53f2 =woGO -END PGP SIGNATURE-
Re: [PATCH 1/5] wined3d: Add a function for allocating aligned resource memory (try 2)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-08-20 13:12, schrieb Henri Verbeet: I think this should either be called wined3d_resource_allocate_sysmem() and live in resource.c, or accept any np2 alignment and be called something along the lines of wined3d_memalign(). The former probably makes the most sense at this point. Ok. Somewhat related, I don't think there's really a reason to have both allocatedMemory and heap_memory anymore. It should probably just be called sysmem. That's a cleanup that doesn't necessarily belong in this patch though. Surfaces can still have DIBs. We're also assigning memory returned by glMapBuffer[Range] to resource.allocatedMemory, although that should probably be changed. The main problem with the latter is that buffers can be mapped multiple times. Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSE1AZAAoJEN0/YqbEcdMwgVYP/irliNpSGEvrH/kIwQHrVD7U Xq0umCSvvZm1K2V1FysG/27L7FB1GNQaD/mMH9mTIKVUUKrC+CciTnNqi42ki1I9 PtdfqRemQ7e/+GoAyfNwP7coIuRKbBH5ZvTVPRvy0rNHW9IEUwr7mWOBbE2NZgeJ eBoHIjwoKCw7oeWV8CYbjhINeJlYoOAva2pAFE/d0D629mielIRdKIc4oc0fa+oD f9LPKOe4NTPP/3Xu87PVg5QfnlpZu78h+WmTNJRwCi8GdzXKL6zTPeKFGOn9/+5T 6i/i7oYxw84R1R13Vv2BxgHoqkC93CUofDKGPGViGG/cxr5q22+VnHScWp2YrEGN 7Fjey+6TIeTd+h4urxNhNdfDerigIKMTTl4yBVtL9VNagxv2E1ow2m08NeaUF+9J /5MHq5cWjRi+34V2mD2N1sU6LcwCCVPTq/xL7lYLgHWYL7LTAkQau113nzgrwrT9 EVieN5od56oyCdzmQFqX3z7IBSZ9l/kirMjcGQeFnD4eaF1v2uE+/73X955HgbqW 3pjqXEEPsPLXllh5hnm86Bt5XbbSrY42Gx4o5X4uWn/OSt6oZctoh3mXTxgW7eIQ qBcFR4i2WIvk++ZM6cSNkKHbUNXR1DEb5YUo2NtiU4y3WTDg6qA3kKC+Wf1vQS69 aFF9hb7e9dr4BCCnt66k =ecTB -END PGP SIGNATURE-
Re: [PATCH 1/5] wined3d: Keep GL_UNPACK_CLIENT_STORAGE_APPLE off by default
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Henri, Matteo, When reviewing those patches, please have a look at the attached archive. It contains the rest of the volume cleanup patches and some tests. Cheers, Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSEd58AAoJEN0/YqbEcdMwGygP/3UsMheQPv6ZmMMGdX+QXltj 0LfSKw7wJiNFFc2+rR/NAP8s1+iGtXKvABLvTINv5ZXwngPxUc10g/5MveV1MRzQ lgU2ebRjFnFFCv0ytcSeb5dutH5EMnIplxYQEDvPR+ojkjwS5bvRENtdh4/BZPGc gh0KoKk4YwsBl3GyWwM6hM8NlEFrwvtWeEU3UdXzZiIYg3WfT5CaXGR3A4o4/G+i WBYar5nGocKHs+5Wgfe4BMC4XNuFD/RFT9R7gB7nrIYQgPJ6j+J46Zkt4ux0ivtH eBHQ5QQNB4SdVoCwPf9H56cBYhtmC6iEFYJg4wEGukZPIhaZ0Je2KHUIXuXumVfB ciesPUN+7DhuZCLSFm5eJUO7aTF+WHOD+uyQKZkLN1oK3JkXy2wflE2d8O2BQKTo qCZPtcA8vmE0DIvk9Q6j8Xt2nAmTnnqIh26ZCsCsj9vZvPn+pNlXT1lduwoF3x2H oKZufHdCdgRKLmRLpVnmPdwKTqwmlSZa9u1RVhDAypLVv20VqykOLAh6mDJC9zl7 k/2ozgsfYsl0kYMTVw5o6dx3f3pJGfgGjsw4vuJHN08aeZmVl1EFY8nMlqzrT8Wa cRjSHKxqk+W3BxTsQz9Zi1u0J3v8nE4KM79IpLgfjm8M9Rk6eTaLkwCe5XpFuiSw MJbpYdZZGZfZuP71LMmm =gRPu -END PGP SIGNATURE- volume.tar.bz2 Description: application/bzip volume.tar.bz2.sig Description: PGP signature
Re: [PATCH 2/5] wined3d: Wrap resource-heapMemory into a structure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-08-19 12:29, schrieb Henri Verbeet: I don't think this is a good idea. How about something like the following? The corresponding free function would be trivial. I guess this works for the purposes of this patchset. However, in my command stream patches I am using a structure similar to this to cache allocated blocks of memory to handle WINED3D_MAP_DISCARD buffer maps. In that case the structure had additional size information and a struct list entry. I guess in theory any kind of payload could be added to your implementation, but growing this larger than RESOURCE_ALIGNMENT(=16) bytes moots the point I guess. I'm not yet sure though if my cache is an actual improvement over just freeing and allocating new blocks of memory. The other unknown is that some ddraw games write past the allocated surface memory. The extra 16 bytes took care of this, and before we aligned the memory we just allocated 4 extra bytes. I don't know which games are affected by this (it was from a comment in old ddraw), and I don't know if the problem only happened if the memory block wasn't properly aligned. Your code and mine differ when HeapAlloc happens to return an aligned pointer. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSEgO5AAoJEN0/YqbEcdMwmiIP/iVETzzMWT/yDSmFNSOAD3o5 59TXEer+KeWUH/tVUr+WA6vxnT3CR18hV7LZl9fPWt9d3pRS12zyYSIz5i/5f9eJ BgK15qFFrZhzFu8c1hzYIhM76nUtInPMVi3zd/7xkgUI3aemuP0dUkJIYd+wrUcz 4S50ppMIgJhqGReFIdTiOz57OPQWUFUoBKDxFlv3WSKgV8b1it99IwXgX/IPuvbQ cP6REIW1WtI6dLvOjoT6D8v2yUSmNmSDAMVBx4D7LEBhVTmxPMuFjbn4t5UJ1+wY wpr2mBNGdiwaLU+XQA5X1UrHDTYPDEQS0pJ9hub8sotwl+QiXWrcTNtw5avai3Xy uztAF7kkCNQpbHopp2GjHXQaGxGoKyXQTI1okFd/R1C/9q8TOCA1gG8c/Ntx9Vhd ORG+HCUr+x+coPfRBwgxdl/22zLHSotVXhmT+2r4uoklnZN+0TX0AKtctwIGBMpR 0Kw9fnBPngpmEHheTDhr94nqZL3FIBLyqRDrdWxiy0zmDu1hShcC5/ox8MutevaR G4bXHlLc4BbW+PN6/wJDNCG3Nt/avdwU0rj4Ix6c7X/Cns+kmyWECiCjRkYo4xQK nlr8wDZC307fcrIH6jfh7DqdPhcMKA17LeKRm6ygpDp5sYqpsTb4r7NOZXJA6h63 nK3qN+FJ4PEbK90d+tg4 =sh5J -END PGP SIGNATURE-
Re: [PATCH 5/5] wined3d: Store the mipmap level in the volume
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-08-19 12:39, schrieb Henri Verbeet:
On 19 August 2013 10:52, Stefan Dösinger ste...@codeweavers.com
wrote:
+void wined3d_volume_set_texture_level(struct wined3d_volume
*volume, GLint level) +{ +volume-texture_level = level; +}
I think that's a step in the wrong direction. I think this should
be set on volume creation. We do have a construction like this for
surfaces, but the reasons for that don't apply to volumes, and I'd
like to get rid of it for surfaces as well if at all possible.
That's certainly possible, but it also means adding this information
to the public API and passing it through d3d8/9. I can do whatever you
prefer.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJSEgbVAAoJEN0/YqbEcdMw54QQAI7eJh2TgT8J104fWK2JXGDa
ClJ1ERE+dZ3LDoS2qkN7SlxZfFq/l4R5pzuO0Jk/xCLnGYwAxc7jW88R6qUC6RrC
NRSAZF66EQqKBXk+0cE09IArGcra1EOmP5N/hMyNoC2S2yRDuSL2BsZDYzfdxk6f
2Trp5y/k4Zcx8IRol7C9v5b1oKQ67hpJ0Io88ChZH7vgJbpiP/J872/G9F/p3cYh
9UNXRSrsS7ODhvYCRVfvlRSuji3EQNqzZWPVitco7EJjSWOGLCSdj+9qEKHzTQA7
a3WzkJFJ60vtLLvqbdysYMP3uUo8yOMpZiL6trwYhr4jnNrdVExsNdckPvRxQeYD
pURsY0lNEga9XmodYfvNa2CvYn/bt+GtK66uFbYH2elPxCBgmR7DoK3RC/ZrlAFn
ethCEPDRFt148Osv6KH+ngEAa+zRT9yJSOVbIM6MmUahUitsPxbfAhDeBGr0LJF7
zFzZj9Ibd6bTFB0s9m871HrH1zfd66QZuOCD41qxYR9gfxellLnw/T1irqzNNeKS
/vW5F78lvOaHiq1XS3uh7YKXDiZ9fUcLTUV+mbqu3WwPzec5CaB45pszYZR+d6Bt
Tii3cZMhDYSLDM8zyGyw9EggYZ7Y99BGVGw1c11zj+MD8J1jbCSDfcWEMjrKHaPU
vDfMO13qYmKgeDzUUBRN
=dh6d
-END PGP SIGNATURE-
Re: [PATCH 2/5] wined3d: Wrap resource-heapMemory into a structure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-08-19 13:53, schrieb Henri Verbeet: On 19 August 2013 13:38, Stefan Dösinger ste...@codeweavers.com wrote: I guess in theory any kind of payload could be added to your implementation, but growing this larger than RESOURCE_ALIGNMENT(=16) bytes moots the point I guess. The point is mostly that I don't think we want the wined3d_heap_memory structure to need a separate allocation. I suppose you could also just embed it inside the wined3d_resource structure. Storing the pointer inside the wined3d_resource structure won't work for the command stream, but I'll ignore those considerations until I send actual CS patches and know for sure that my cache is an actual improvement. properly aligned. Your code and mine differ when HeapAlloc happens to return an aligned pointer. That's actually a bug in what I posted. What's your suggested fix? Allocating size + align + alignment, and adding alignment to mem if mem happens to be already aligned? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSEg2mAAoJEN0/YqbEcdMwOEoP/iWfAY48+3DnewhUbKbuN2L/ 1hy4E/4/66lQYn/Zjh0OppmyyKYbVmphUGMFOsoVEgMr2pXuoorkoixaSR/gA2k2 8UBKHxKahRUIIfHrUUiHopD4WqN7D0RNFppPF7kc3o/lrFUgTGSbTCSbu4+1v/1S 0Bku9tQ+0pG4zv5aHivtXNUcZeEmK+8NjXwk9HOL4ro6Eg8by1QpSW/ZdsnsPWci aH8HhfShQN6jmGfe04r2L/dP/EILhsNgJ8bRzrxi48M+IHX8jUdX10bwlGYy9BRi 89YvxFXb/jyHk2NdpYfHjntDLy1wWs/tMI5F9ns/p95L6VVSnKQUROMFz4iyRrT8 vJRmeiXeIFTyMLs+XfXioDzZTh6+iMtnmuCk/xTH4pzTeMWJTosJs2vcWQVf5aka SF5fFxg3HuT3VNFqql5s5oTKXJ1MiB3sDkPHgo6s68AS/TpCFicCUca+WPHfriQO FrW7kr/wUe9Krzh4bQQQt8SB5rJJWVYYXNPV9A+BOAZzSAbGMMXIi2QVTb9FHDu5 znspnnZbHUs4fyehJpzCQEwR1WcAkaEVT9t9owNefxvwrZhbGq4GTd8YwNtr61UL xkixy8z4cA0ul1lW/QGpBMswtYYBKa1m43HzLcZ+1sqtftLkgApDbOxW5BCMdDLO 56TMnG+BJCGaRgQVzoov =nHsF -END PGP SIGNATURE-
Re: [PATCH 2/5] wined3d: Wrap resource-heapMemory into a structure
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-08-19 14:34, schrieb Henri Verbeet:
On 19 August 2013 14:20, Stefan Dösinger
stefandoesin...@gmail.com wrote:
Am 2013-08-19 13:53, schrieb Henri Verbeet:
That's actually a bug in what I posted.
What's your suggested fix? Allocating size + align + alignment,
and adding alignment to mem if mem happens to be already
aligned?
I think it needs to be align = max(sizeof(*p), alignment);, but
that's actually for the aligned + 1 case.
With some inspiration from _aligned_offset_malloc in msvcrt I came up
with this:
void *wined3d_alloc_resource_mem(SIZE_T size)
{
void **p;
SIZE_T align = RESOURCE_ALIGNMENT - 1 + sizeof(*p);
void *mem;
if (!(mem = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, size +
align)))
return NULL;
p = (void **)(((ULONG_PTR)mem + align) ~(RESOURCE_ALIGNMENT -
1)) - 1;
*p = mem;
return ++p;
}
void wined3d_free_resource_mem(void *mem)
{
void **p = mem;
if (!mem)
return;
HeapFree(GetProcessHeap(), 0, *(--p));
}
I'm not entirely sure about the SIZE_T align = RESOURCE_ALIGNMENT - 1
+ sizeof(*p); line though. Msvcrt doesn't have the - 1, and allocating
size + RESOURCE_ALIGNMENT bytes might be enough. msvcrt allocates the
equivalent of size + RESOURCE_ALIGNMENT + sizeof(void *).
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJSEjTlAAoJEN0/YqbEcdMwHhsP/3jldV7GHrhg8Asj1wxksNbz
vXorIHDwBQQQFmcj4d5o7zyXsMho/SfebMeesmtJCtmfZeOasWjE02vgnbZSbU1T
OA4Aow7orGeGWUCYddtJYLoDwC4HSaIXb/8HO5rCNnM1tVboHn0XXBM5q24t+fZo
jbmX6Ma6QtD/b6dV+TCvh8YUih5Yy/lTr0Fq1c3nrodz7JTbHqu7qfdpK2QPqB4P
ekRtHofPTLKLAxwZFw5Vc5hdUZ1xfejUuKgzQWnPFbb/jHFdN9gC+2mZdn0YbyEs
hATXQX8N2oakjgzkBg1eyZInhPLHFTNrz5EfR0tolv+ytXdy0YfcOjSYkYOODkNb
bUr1l1uTBw2trVYFtx52XqkhuoXZhj2DAbGtM2vmd81Sttce1CnZd08jcedDllon
sSZ28lkvwxVL6N6pNkrpTWjaKj3RcaAhqJm5zj+MHX95w8gPl6oFps1lCrLXVaDP
gsC9FeHL3QPf7Hb5arJvcxbH17CVRi+i4irJIgnOgJMLkZGK3+jbadKHPHA0D2i8
lTewyhf70+FJd04yZ0yoiXTYcJbZU9BkQMKxbTpywoUP8+3ZJ3n7PMe+CoFyphr1
fzZFR0sV/T4kCLBbH8YeTsiWluB0ioOCsh9cyNZrz6C2Dy5PmNmwTN0dWpi7LukF
tamCuVqBu//pY5YUuq9d
=7d25
-END PGP SIGNATURE-
Re: [PATCH 2/5] wined3d: Wrap resource-heapMemory into a structure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-08-19 17:08, schrieb Stefan Dösinger: I'm not entirely sure about the SIZE_T align = RESOURCE_ALIGNMENT - 1 + sizeof(*p); line though. Msvcrt doesn't have the - 1, and allocating size + RESOURCE_ALIGNMENT bytes might be enough. msvcrt allocates the equivalent of size + RESOURCE_ALIGNMENT + sizeof(void *). After going through all the possibilities I concluded that size + alignment + sizeof(void *) - 1 is the smallest allocation size. The worst case is a pointer of the form n * alignment - sizeof(void *) - 1. In this case we need sizeof(void *) - 1 bytes to get to the next aligned address and then alignment bytes to store our real alloc pointer. Not sure why msvcrt allocates one extra byte. Probably because allocations below 4 or 8 bytes don't matter anyway. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSEjl3AAoJEN0/YqbEcdMw/JAP/iw92FaWRGOMoOMToYTuBqyC K9xgwOXxPuViICgR92uAMv1K/vn+38WWmuTULGKjRx9qdddOBEuYd2cIS1xUjLub laegv8EIxn/g426xqjZ8mSqXBrFyHMhGVTREuWbr4G4yIH2CB+yzmIg7IObgaPoS G9Gleeg0+pjzyPnqdCy9NWu/HEWDKVQ4Zdqms2oBmgfpPNtSblwh/BFeoIf5+eON 4hzIcY+rYKK0prGaJ7GEVFIocLqZJuF4Z6KiDS+jg4jRx6pCXQ+m1GcNDb90fYZX i8nWO2TfVmTZ8j5yb3Z5YTW5C/3UIQDJhBlKCqZyu2FhR+PTDzTEnWow9fp1kfCK KHZYcJmomSRQX+xWinjKAqatzUtsM2HbT+cyUeiQKVVpSNOjSFCM6tzsT0q9/PQd 89G4kfPIwArKyNHffNXeiuEWTKYY4/a3E5/E4dbIFxVvxrqxaeg5jDuG6Ic0LQK/ IEAfJHH5LLwM6Ef3s3lWmkgRTMYE1oWyys5uP0Ht3C0xUoomohpXQrrgRZNfTjtL J49rvEQ+yZKPPrXOqjLtIwKFC/mdb3/4x33b2UMob5HRN7Jjusvg7OefqYmOGprr UFB0iIwg7oOuqThZ+Ce5jnu5p0vvvPYq1vEuW7Oz/wth+aENibNatvKnJFj/tWOe i40GHsaztVcRtNGbZsap =zZYQ -END PGP SIGNATURE-
Re: [PATCH] d3dx9_36: Filter out D3DCompile warning messages that are not present with D3DCompileShader.
Hi, Am 31.07.2013 um 09:10 schrieb Christian Costa titan.co...@gmail.com: +if (!(strstr(line_out, warning X3206:) strstr(line_out, implicit truncation of vector type))) +line_out += line_size; msvc localizes compiler errors and warnings. Are you sure d3dcompiler.dll doesn't do that? Wrt the parsing code, wouldn't it be nicer to use strtok_r to split the buffer into separate lines? I am not sure that parsing the errors and warnings like that is a good thing, but I don't know d3dx9 and d3dcompiler well enough to give a final judgement on that.
Re: [PATCH] d3dx9_36: Filter out D3DCompile warning messages that are not present with D3DCompileShader.
Am 2013-07-31 16:01, schrieb Christian Costa: AFAIK no. My localization is french and I get english messages. Any idea how I can check that? Should be ok then. The parsing code handles missing null byte as well as both unix/dos text formats but maybe I can just simplify it by using strtok_r and assume dos format with null byte. Is there any reason why the format would change? I'm afraid this is the only solution. AFAIK there is no option that disable this warning. As far as my reserch goes, D3DCompileShader() is d3dx9's function and d3dcompiler.dll only has D3DCompile(), is that correct? If so, parsing the warnings is probably the least bad option. The obvious alternative is to ignore the mix of builtin d3dx9 and native d3dcompiler - but at some point we may want to write the same warnings from our d3dcompiler and the problem returns. In either case, please write some tests that demonstrate that d3dx9 does not generate those warnings.
Re: How to get involved in Windows Store API implement?
Hi, Am 29.07.2013 um 15:33 schrieb 中川祥 matyapir...@gmail.com: I do not know much about the store apps development. What is Windows.winmd? Do I need disassemble it and create wine version ?If I need C++,I wouldn't do. First of all, don't disassemble Windows DLLs. Wine will not accept your code if you do that. Use black-box tests to find out how APIs work. Is there any planning to support them? What is your goal? Run applications from the Windows store? I don't know about the legal status of the Windows store. Is it possible from a legal and technical point of view to take an application from the Windows store and run it on a computer that doesn't have the Windows store installed? I'd expect copy protection schemes to prevent you from that, backed up by legal terms that prevent you from taking an app out of the Windows store and run it in a different environment.
Re: [PATCH] wined3d: Implement per-stage constant in glsl fixed fonction pipeline.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-06-25 18:08, schrieb Christian Costa: Are we really discussing about a typo in the subject line? Implement just comes naturally from the fixme when I create an empty patch. It turned out after coding that Fix is more appropriate. I forgot to updated it. This will be fix. I think the typo Henri refers to is fonction, which should be function. While I agree with Henri's statement to some extend - patch reviewing is a terribly exhausting task - I think the statement was a bit harsh to say to someone who donates his personal time to the project. I'll try to do a better job looking at patches myself to help weed out the most obvious mistakes - right now he's doing all the d3d reviewing work. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRycSuAAoJEN0/YqbEcdMwOHwP/R98Fs+ZunKuRIPnenvXFEat hP3C1JCrGhxANiYIggkdcvfjPxCSbgz+LM4nfZC4qARSHnYzvxhcQxALN2je/lwb 1iWx/xZ0Czy2yR3rHqJCEW0jXkV53O/Lkqbs/Nf2ue0I7vJWuhaA3Tl+P1esE3m8 rdeRQY89SyXuvfZGtO1tPnGwsYMU/NuSoIffKkLjjWpBhScvJmcSUYOL9RuFk6Tj +r7zGp9niSfVO9N8JY7BTAlXTcAK9p0gKaWzAuCXYFr8gcbOaGB3kDSsbIhtHe57 8oWEDA9pn3tO7l1fXGZdbyfamIPyjg5boh1yHireDze9eefGHrd/WQqEu1xqVd95 BVlFUt2nMPZoR9A0MUT3/0kbq/sfJ05ytCTZ5AlbNAO8msA0fTX58gw6UA9QXrET 1dpE+tjGHzN49qjcBtUmFUII6zc+m8B91Xlhplupda2v/TZv+tzQvrsMIuwRvLvP hTzxaZo/kFr2Pnlx8Sgk0ImNUfi9AIXpLo/h7geLgMi0kMTzkHY4qW2LGf74GNhU NtBgN+4Y1iFLeK6dbKIenD75MN/JGOp6eOHK53E2++RykLxJLyqCTPqplShE/Zz7 hnt80SQTR0jYttA9KsHGE3GnqKPc8RndMnjGnMCyNhLj9Jm27te2VMGLbw4mK0yD C+nOcltXE3Hu3AYpzEXd =C1yJ -END PGP SIGNATURE-
Re: [PATCH 2/2] wined3d: Avoid calculating 1 / (fog_end - fog_start) in the shader
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-06-21 13:05, schrieb Henri Verbeet: On 21 June 2013 12:06, Stefan Dösinger ste...@codeweavers.com wrote: This also works for fog_start == fog_end on drivers that don't handle this situation correctly with fixed function fog. Tested on nvidia, r300g, r600g. What does this fix? It's a minor GPU-side performance improvement. It's not visible in any real application I tested, but it improves my World of Tanks shader test with fog forced on from 155 to 160 fps (GeForce 9600, Linux, Nvidia). -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRxDgXAAoJEN0/YqbEcdMw1PEP/3bhqU1Wl9LP/TcloMFvZv/t VW3zVpCAqwd7aAiTQAY1nt0OttMptRL7d/qRKc690J6ghPvTv1FDhpWtmxKnVmND eqwaIHbTpv9cTHn5775/kn/XwMi0QrDh6WxMRynw234Z/A7xv4bxNtH3c0jOyom4 oiHFq3uo/FsrjCyby9ePRfVH8IbpRwSHBpSG+cO+qRa5aqec/pBAA+NngntrUL2O FxCzhzJHepiRNdPsr4s3TpJi30p5mxma0cPnc3gAZDynZtDtUNvHkwPCWY8bXZrW 9U2ke9jevfrEe8eZsmcBFVKNDrZkvLMb5WjN47r/1bDVlYLyB0bJzo9b5c4oafu6 c5XxUxq7N40VRXbFue3o0gwAPTfqPge6UuzjB0VxZ+nH5uE43Xgdzx8CFgE8N0hn +5zTFJTRYLgnIjaBR7CmGlFz26FTIzrTQs/gWD0Z8spgA+xhZRc3FqtzwvaNUN/I mAaMYnLGWQdfM4SDO7yfaaDkn4Y0Kamh05crYm6QwPNIp+QK6HZsn+lPsMM+K9Yv 0YDndUJDttDJ5f0UGmT1a2x4kp/slt1wzEe/YTab7kjRQi9lnqNaIVyUk+415tsr M8bbsF1zoi6c8U9/L+Eajd9k9RMOSzZ/F0+iOAq4CjI2Z57u5wgzkNcmU99YOH8W kN7jNL78AUfl2t7ox6JQ =pfmE -END PGP SIGNATURE-
Re: [PATCH 2/4] ddraw: Send device2_Draw* through device3_Draw*
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-06-20 13:02, schrieb Henri Verbeet: On 20 June 2013 12:17, Stefan Dösinger ste...@codeweavers.com wrote: -return IDirect3DDevice7_DrawPrimitive(device-IDirect3DDevice7_iface, device-primitive_type, +return IDirect3DDevice3_DrawPrimitive(device-IDirect3DDevice3_iface, device-primitive_type, device-vertex_type, device-sysmem_vertex_buffer, device-nb_vertices, device-render_flags); This is not introduced by your patch of course, but I don't think there's much of a point in going through the vtbl here. Right. Although it made sense for calling device7 because of the fpu_preserve and fpu_setup vtables. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRwuMCAAoJEN0/YqbEcdMwqWoQAJdGD4wWu1uAGmew+mj5kn3K Ys/EzJqN5Njf3heGad60E5+8Gpv1xrVH9I4BsPpmAhE2NaAXkOH5/HDmD8bdy2Cv tlaqvHQueXs3kfTMLswk/3I3A4Y3NJk2HqP9VRv1mBRbzk3MFV4W8ZcZS7wIRZEw ikhkH7EeB351wN1NFJE/RJ9w+rDWCcBSTwGWEBCzRxku8MPC1ueUpNDWzqkWUklC 6sFea0BR32XaANqDhxo4vMmQL3NNqTSLBpIIwfP7JpABpNTYJp4dRgwNLWQxCG2x fqL/KnCQe5kM7Hm58qvdF2pZo/Iu3sFV0F//jb5k7Ku9yj0pJOHp9uXRlRsJVrCx JAjUC3hit7xPu7MjJEStRhBEfqlSH1pJ2M4kE1pQU6sO0rR4ZE+JrQJzYl9E7mLq Gj+IF8823SpBrYCYM97fcfgX2gzbYp0TMuzgn7TMYyD/IUzyDaqrEQdL0hXLQJBB MdCF2eZJKXGftzM9DUfwO/bbKCUk+png29JT2gP78asTu+9/AJEE3+Kw2MIEv79i dN51tY8wqGSrieZvIJ7h5kSV5pLGxjIqwlfgK1f8XFo7qYfJLmQ+Q5dB1zpYq5tZ w7LmXEck2w4yYLXS9QRXrGgmt9YdEmkvvuXpBcnje/d3kDctuRKtDFSXPf0DhtNw YLx3zQRpPdUe3Zk9Tiox =O23d -END PGP SIGNATURE-
Re: [PATCH 3/4] ddraw: Device2 and Device3 do not have a lighting render state
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-06-20 13:02, schrieb Henri Verbeet: On 20 June 2013 12:17, Stefan Dösinger ste...@codeweavers.com wrote: /* Light state */ DWORD material; +DWORD dummy_rs_lighting; Considering the render state doesn't exist in early ddraw versions, do we really care that its value is preserved? It seems unlikely that anything except our tests would depend on it. I don't know any application that depends on this. It just seemed like an interesting thing to test to see how far the interaction between the different APIs goes. Just to make sure I understand you correctly: You're saying that the test should still call SetRenderState(LIGHTING), check the initial value, and GetRenderState(LIGHTING) should return a hardcoded 0x? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRwuUDAAoJEN0/YqbEcdMwDCAQAJAGmdgE2CP6ZwMudC1x77eh SORFI6G/U8vO+6zv39KWAStA9S6KB9MOJuHGo8ytVxscn5UxXo7QR4+WqtKc4G6M 75Qry5gsHRvHEa9YeJIcJttjZq49+htZ0rWmt2HxI4+XC4aeIpsQWBNDoJLBE94P +M915aZPrBB7rurhGqgWBQ/lDt9o0ov2obH2NUJj8Ze7KKPYIT150rRVxbS1qqbp D0DpIKT+4rgUukx77zN6jQ7+gegUGTQodbhD1VKaD0HicCBEPJ4l8/dB3Q8bvfa+ Xe/E69/5YmslMO74rYD702grNOiGhHAcRQbetqxllcGivIOrO1CWCP88465uhfED pLD+7aIoVqcroj5ifgQkGtrZ4tcSN6GoJcvy5x+7d0OtiJmf8xHeHjw8SF7fqCQk Uy4/t5IRrAcOzR9v81lp+38hVUUpminc3cW9YK8nEQDCyHTxi9MWalOoU1xR0Zlm qtkpYPxjZoNl4aju2xC2t+AanjsX/9+VRsmiY5hj4j5QE2o0Wsp9c6Y75XsdCuGR SHMJkeq1DfthNhMJTpF4eMG4HdW00nxtrAT14WRUq+I6vlgRXjgUYrw4GgJRFFYW diqeqj+KJtDErTP/X3jlnLZhw6Dy2sLq0J/inoXjom6oZPvgCXfPDEq0nupQzE8y ef9JQ1JCpo5NJ4E8rZZU =oVUh -END PGP SIGNATURE-
Re: [PATCH 3/4] ddraw: Device2 and Device3 do not have a lighting render state
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-06-20 13:23, schrieb Henri Verbeet: Just to make sure I understand you correctly: You're saying that the test should still call SetRenderState(LIGHTING), check the initial value, and GetRenderState(LIGHTING) should return a hardcoded 0x? I think it may be enough to only ever set it and test that it doesn't affect rendering. Ok -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRwuupAAoJEN0/YqbEcdMwzfAP/1efoDdVK1cUpx2z3w0dFVxS ftaHF4MW4vywyFOIr6bjsNBAly0movKiWLMSoZ0HhDPD5l7ooY6kXCdqtiiSsulu id9lPx9OxhWBBubYGvinOe/j/9gQnjnKk9UWDT3/CJbHASwezTlAt8kzdPhvOFs1 iYTwc55M1c3RanUn4IWz6AovBL0iTAYKfM9mq/Qj+m8XWc9SRNVA6pTycq7hrpLh vJuIvb4gRuRxufzwdisr5HbGqsOPW9X/HflmgAbYZ0Jm6DAgsrjV71Nzuqj8A6Ry lc2582BqAuctBGfsWvJfDd00w+0hPfHKpnrh2j5UyRTH7NWX5MZV21wr/sOYSZTp N8fblKoiULniDOy0+xMfFjMoDhCzy8WAAIuBuSehsz/1pkPAn0SiH1NVzOMpl4t/ p3NviOBHCcbvKH4aw9S71Pvmoft00kH2CzZt0CIfIz1RDEV+9w4OFBpCCAIYADcH Bkduwp5DzB3UBaJjm/kEblgPW5spajKPohGvyA3N7K3g2hwAKj36eqBcsU7S1iC9 m5ZjR7bO/7aOy+au/1M4+4ASB5RtHP4Jo5iXC6Bmtv/A33dz3aJFt2+sSvKdfWi3 /x4YvR6kNMqWYqixRe0H6K9psSqTceMYSwDvfpX9uh9mYNNeJZdqmqBL7U7osjQK WGwQ5nKCz0OCnneCek6N =5IQX -END PGP SIGNATURE-
Re: [PATCH 2/5] wined3d: Handle fog_start==fog_end with table fog(try 2)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-06-18 09:12, schrieb Henri Verbeet: On 17 June 2013 22:53, Stefan Dösinger ste...@codeweavers.com wrote: correctly with fixed function fog. Tested as usual on Geforce9 (OSX, Linux), Geforce7 (Linux), r300g, r600g, i965 (OSX), r200. Which of those is affected by the quirk? I think all of those except r200 should be able to do GLSL, but you say r200 is the only one that doesn't pass the tests. All Linux drivers. The OSX drivers I tested get the special case right. I don't know what exactly goes wrong on r200. My plan was to look at this (why the quirk is needed in the first place, and why it doesn't work) once more important Wine 1.6 business is done. The quirk works with mfcfog.exe, but my tests behave as if start = 0.0 and end = 1.0, no matter what values I set. Either there's some precision problem, or a different state breaks the driver. (That said, r200 has another regression documented in bug 21708 that I have to look at.) You may be able to convince me that this is a good idea, but so far I don't think it's worth all the extra code. My motivation is to make the tests pass on as many configurations as possible. I can deal with ARB in another way, by implementing the fog equation myself instead of using #option ARB_fog_linear. That would throw pre-sm2 hardware under the bus though. GLSL is also lucky in the situation where fog_coord == start start == end. In that case the linear fog evaluates to NaN, but clamp(NaN, 0.0, 1.0) is 0.0, which afaics matches the spec. I don't know if that is lucky wording of min() and max() or intentional. (Windows drivers disagree if they should use the fragment color or fog color in that case, but no windows driver uses a different color like black or pink) #define WINED3D_ADAPTER_CAP_XYZRHW 0x0001 #define WINED3D_ADAPTER_CAP_VS_CLIPPING 0x0002 +#define WINED3D_ADAPTER_CAP_BROKEN_FOG 0x0008 Is this intentional? No, good catch. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRwFBFAAoJEN0/YqbEcdMwhHoP/2rcw/hv5X9JJKqasYYeVUJd uQJETFicWlnZ+BZ218VNxxFMVmaNlEkeDB7P6deimC5I+9LTbXIVOjPdVloLR7eF HuiB+hk7PocZMYm/PXAc1I2OzDmbbErKWs2Tq+gvkUnWccioZArLFODrUopOzzMy 5aoaFXp4unMQ0ZzYGYPZD8fHKDV6MBYIjhU24gO85MaNQi/3zD/OGWzfalthAEG2 /yzUOR4GdOkF09i39ORqaQdL30XYqXSPVKdjoN8CgKwx1D87dvGOrj7351/LObcW YwkBtFKz/d0huSBOX5wgNyAevUqc7PRA3fD69tbQ4yEW/fIg5Q6fftAOWapLPKFc n1AYXUUouuK3iK52I/LvQM8QbQeqjdyJcmh0ld8domyMrmH7fQrCS9QyLi6baNLM wPrRiHWRQJWOJ8gZgMhw5BcYbBGH8qn41i+UCecyK07gEHhWii9bNaC4H1rlzdgb Q8P/dZLsap67dk8YEEWCyEC658oPYiHeJkL3j9FhCrpsPCPbfVIpwkVwIqKQ0OLz LkwO9pW9x63b1vZoncOns4JVBWHyRF99Ex+WSuMNx23Iwja++wJ8Q4Zwm6cjxgCt AZFhE3BaF35tMIWLEpRfxdXeZNf2tJNQ++qfup1DiNVEJH36xa2pokobAQFVILCC pTTtyZMVwnBSJKKkE77o =iZ5n -END PGP SIGNATURE-
Re: [PATCH 2/5] wined3d: Handle fog_start==fog_end with table fog(try 2)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-06-18 12:53, schrieb Henri Verbeet:
(And that one is only supported by Mesa anyway, so there should be
no reason to not just fix the driver instead.)
Well, in theory. In practice I'd need the register documentation. I
had a very quick look at the mesa code, and it isn't as simple as
removing something like if (start == end) annoy_wine();. There's a
register flag R200_FOG_TABLE that may or may not provide what d3d wants.
Supposedly the register documentation of r200 is available, but Google
doesn't find it.
I can deal with ARB in another way, by implementing the fog
equation myself instead of using #option ARB_fog_linear. That
would throw pre-sm2 hardware under the bus though.
Yeah, we probably don't want that. I think the value of the ARB
program backend is limited, but it's main target should be pre-SM2
hardware that can't do GLSL. (And potentially still has dedicated
fog hardware.)
Since I'm still maintaining the ARB code, I prefer something like the
attached patch over failing tests any time.
(It's not quite done yet. The patch needs splitting, the quirk test
should test an ARB shader and I'll probably limit the custom code to
start == end cases.)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJRwE4GAAoJEN0/YqbEcdMwweMP/3IZhKiTeaVnhmVg1nfHBpjG
hegDyIfFKVa1Xy2yxV3fYiKhYxuXHzHRl7pQ8qJlNLttoq2i/MMYZuQcZ9Ww3xWd
sHs/UD+RTQgGasNxYYx1Ody/yjHt+fx+98rXSR2b31/oyjmzijnLZqmSr/8JSB3/
JYSNkKSW91GG/IAlcp2C4QZZo+upg4t29+WPHn4aeQeYX/oxlY6rQFVrlWwb7UBN
FQL9WV29ah8Wb3jeGp5UZM0Z8C83cu5efRH5kyGsdM/8YcPzqHAoHuFv3vmnpJxi
dze41y0RqgZMsocFog/VlegZqCheH1alDEmRuEkl1/1jIBGgHnJsw2FggjJ+veEg
zkGmt9GXPjn2u0+gcj48a2FDpLZw5UAdwaI5jKyoDVsTY/cSk8RdoxlqcQVcu6BI
xWx1XaAyjPwg81mvVyugyR0B+GSIsfXXhYl1kCExwLXuFam4Vn0RkPbwcdj1WHem
g3ufGT9FHGeftCmnXMLR9ETSiHdgnB6/oabwe7fc5zLBAGfgi8fTYB4DZvXpqWas
ZWAcunRRpDuIA4w7xqjYFqWNF8J6WIouki1sUrCvd/lNtBXM9ieRHgG28qY8h9JO
9xeC7UCh950juECgocTYz3W1qqsrEL9fmmbVp0HdltiBtqmTBfFSxuDtfWIN7ViZ
9HsSdt/Bw0tiXy3uRvlN
=8SHq
-END PGP SIGNATURE-
From 63d8e32ad4dc3606f641472f4844b5e439174196 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Stefan=20D=C3=B6singer?= ste...@codeweavers.com
Date: Fri, 14 Jun 2013 12:19:24 +0200
Subject: [PATCH 1/8] wined3d: Handle fog_start==fog_end with table fog(try 2)
Reply-To: wine-devel wine-devel@winehq.org
Wizard101 triggers this when running on a GPU that does not support
shader model 3.
try 2: Make the fogend increase code a quirk rather than using it
unconditionally. GLSL doesn't need it because it implements the fog
equation itself, and some OSX drivers handle fog_start == fog_end
correctly with fixed function fog. Tested as usual on Geforce9 (OSX,
Linux), Geforce7 (Linux), r300g, r600g, i965 (OSX), r200.
The follow-up tests pass on all GPUs except r200. The fog table works
correctly in the dx7 sdk mfcfog example on r200, and I didn't spend a
lot of time trying to find out why my test is broken on that old card.
---
dlls/wined3d/arb_program_shader.c | 56 +++-
dlls/wined3d/directx.c| 78 +++
dlls/wined3d/glsl_shader.c| 4 +-
dlls/wined3d/state.c | 13 +--
dlls/wined3d/wined3d_private.h| 1 +
5 files changed, 139 insertions(+), 13 deletions(-)
diff --git a/dlls/wined3d/arb_program_shader.c b/dlls/wined3d/arb_program_shader.c
index fd2df68..8c67f1c 100644
--- a/dlls/wined3d/arb_program_shader.c
+++ b/dlls/wined3d/arb_program_shader.c
@@ -278,6 +278,7 @@ struct shader_arb_ctx_priv
BOOLmuted;
unsigned intnum_loops, loop_depth, num_ifcs;
int aL;
+BOOLcustom_linear_fog;
unsigned intvs_clipplanes;
BOOLfooter_written;
@@ -1160,7 +1161,8 @@ static void shader_arb_get_register_name(const struct wined3d_shader_instruction
break;
case WINED3DSPR_COLOROUT:
-if (ctx-cur_ps_args-super.srgb_correction !reg-idx[0].offset)
+if ((ctx-cur_ps_args-super.srgb_correction || ctx-custom_linear_fog)
+ !reg-idx[0].offset)
{
strcpy(register_name, TMP_COLOR);
}
@@ -3559,6 +3561,14 @@ static void init_ps_input(const struct wined3d_shader *shader,
}
}
+static void arbfp_add_linear_fog(struct wined3d_shader_buffer *buffer,
+const char *fragcolor, const char *tmp)
+{
+shader_addline(buffer, SUB %s.x, state.fog.params.z, fragment.fogcoord.x;\n, tmp);
+shader_addline(buffer, MUL_SAT %s.x, %s.x, state.fog.params.w;\n, tmp, tmp);
+shader_addline(buffer, LRP %s.rgb, %s.x, %s, state.fog.color;\n, fragcolor, tmp, fragcolor);
+}
+
/* Context activation is done by the caller. */
static GLuint
Re: [PATCH 1/2] wined3d: Pass fogstart==fogend to GL in fog table mode (try 3)
Am 18.06.2013 um 16:33 schrieb Henri Verbeet:
On 18 June 2013 16:17, Stefan Dösinger ste...@codeweavers.com wrote:
diff --git a/dlls/wined3d/glsl_shader.c b/dlls/wined3d/glsl_shader.c
index e14d7ab..ad9be6a 100644
--- a/dlls/wined3d/glsl_shader.c
+++ b/dlls/wined3d/glsl_shader.c
@@ -7107,7 +7109,7 @@ static void glsl_fragment_pipe_fog(struct
wined3d_context *context,
new_source = FOGSOURCE_FFP;
}
-if (new_source != context-fog_source)
+if (new_source != context-fog_source || fogstart == fogend)
{
context-fog_source = new_source;
state_fogstartend(context, state, STATE_RENDER(WINED3D_RS_FOGSTART));
You shouldn't need this.
It's needed to switch between the different handling of fogstart and fogend in
vertex and table fog. The ddraw test shows this. The d3d8 and d3d9 tests
succeed without it because they're also switching vertex and pixel shaders when
the test switches between vertex and table fog.
Re: [PATCH 1/2] wined3d: Pass fogstart==fogend to GL in fog table mode (try 3)
Am 18.06.2013 um 17:25 schrieb Henri Verbeet: On 18 June 2013 16:52, Stefan Dösinger ste...@codeweavers.com wrote: It's needed to switch between the different handling of fogstart and fogend in vertex and table fog. The ddraw test shows this. The d3d8 and d3d9 tests succeed without it because they're also switching vertex and pixel shaders when the test switches between vertex and table fog. Right. Perhaps FOGSOURCE_FFP should be split up. I was thinking about that, but didn't consider it worth the trouble from a performance and code-niceness point of view.
Re: [PATCH 3/3] wined3d: Handle pre-transformed vertices in the GLSL vertex pipe.
Am 14.06.2013 um 09:07 schrieb Henri Verbeet hverb...@codeweavers.com: +shader_addline(buffer, if (gl_Vertex.w != 0.0) gl_Position /= gl_Vertex.w;\n); I think you have to disable the rhw divide in drawStridedSlow in case the application falls back to it despite this patch, e.g. because of specular fog or float16 emulation.
Re: [PATCH 1/4] wined3d: Handle fog_start == fog_end with table fog
Am 15.06.2013 um 10:40 schrieb Henri Verbeet hverb...@gmail.com: Why is this needed? When end == start I'd expect (end - c) / (end - start) to evaluate to +/-INF, and then get clamped to [0, 1], which is pretty much what you'd want. In my (very limited) testing, that's also what actually happens with at least the GLSL backend. When I looked at the same problem back in 2007, the GL fixed function pipeline disabled fog when start == end. Admittedly I did not re-test that assumption. I'll have a look at it later today.
Re: [PATCH 1/4] wined3d: Handle fog_start == fog_end with table fog
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-06-15 10:40, schrieb Henri Verbeet: Why is this needed? When end == start I'd expect (end - c) / (end - start) to evaluate to +/-INF, and then get clamped to [0, 1], which is pretty much what you'd want. In my (very limited) testing, that's also what actually happens with at least the GLSL backend. I re-tested this on Nvidia and r600g. GLSL works as expected on both drivers, but ARB and the fixed function GL pipeline have different behavior. On Nvidia, everything is fogged (like d3d vertex fog). r600g seems to increase one of the parameters like my patch does, with two differences: It adds a higher number, so there's a visible fog gradient, and it increases fogstart (or decreases fogend), so it produces the opposite of what we want. I can test other drivers, but I think it is safe to conclude that fogstart==fogend is not well defined in GL and we want to avoid it. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRvNhFAAoJEN0/YqbEcdMwjfEP/1nPD4/1hIZAG/YDroQpYTqQ KuoSdCxs6eq2RL8sm02e5GhuODUL9In1rsoNB26vPEMYK+Gvl/QfxufqTM92HAdU AD3E/1rS1ALAKJ276Betu6Fkkp6ZFUcKQrRgN4HEXyi0zn3Xf+5PsO3XYvgwPjln Rl9EbSuy2j2eQvH/ybbokwzZ5btb62CvhhwFEttwkZtXj44hibF72ofGCsUh/NIl 5QZSKPE2f9r/wW5KnqfYRgP7a+UrHk1wpmoAmBIZ5H3Xua2n55k7ofVeitYcRCYp 9+qh3k/Vzk7sqggos2s2cSt7gnzfgdz9o4oBetGufwMwAJ/Md8HeR7fRLojb4oru vxcfIL3Q2G7BO4yeQ2Kk1dIxR3rkCKiLh9OoN3ACDjfMvQZKvYzOnhUOVbxLzBqW Jp+AzHX2ZqqsHChjuPFF2zroBXkEz9zXyKkpz/Nbo88vqgVMg9VFSLepou6X9fUn Xw3goO/fOCe+kZ3bEKb+jhbqAvlU7qaHAm8Qs8xxMoeHTtVfWwSlN9fTm4z9wrHE dZWQ5fCGpsmuwxY6hm0MhDbyfMpV5xPdHvxFA5glX5wC4rJqdrfQMVLvImEhbl4T Qgq5ZiYojmit3jpr1MAr1h4nOyRhmdUPjCL6BEnFVp1TfSylxVA/yZtQatW65QA5 6FApdSgz+lTEilXT0cD8 =6pcA -END PGP SIGNATURE-
Re: Fwd: [GSoC Mentors Announce] GSoC 2013: Mentor Summit Travel and Details
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-06-13 20:52, schrieb Austin English: FYI for GSoC mentors. It's a ways away, but have the date in mind if you'd like to attend. Remember we have two slots, so if there are more than 2 people, we'll give preference to people that haven't gone before. For those who haven't been there before: It's a bit like FOSDEM, except that it's a bit smaller and in sunny California instead of rainy Brussels. If you can make the time, I highly recommend to go there :-) (I'd love to go myself, except that I'm not actively mentoring this year ^^ .) Cheers, Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRuv4xAAoJEN0/YqbEcdMwvcsP/RQrm/S9hadA97+fOD0T6y/Q rzEm3xg+cFBnLUgR5oFOtlbYm+FforMcj0pDogvpVUoOEBJiMwlatAyugaIWHE8/ RNTojjpq/nVkgWD/DF3UJ3quJyAxMN0Kk7mGhERxjqPzV1ZX1kgrkxqvZWl8iBfL QOwqmoD4rYX/64QWly0r0T4dwsBMnzlo9rkul/V4diZ//8l+aimjM/YNz4o4SOpm Lo2Gj+GRXQv13e8THnpbWevkisPKKfiWT3WlCBOSviKVZdlMqDeSLnBiua2XSs9E POamT/X4QI5Ztx5phFV3DptrrAMNb3PN2eAYT4khcwb8EvJ8yTTy8VEgkihwW8ql wlOsBB8UMKrVA0uodlKEBtfxNztTmf6tXG796dwUTLrhFx46j/HalnHvWc740WrF v9wD8HMYZHmR+S8zMkwBBEW3qk7HNbwDz5DMu+UVMN1W1tJM67zYPCzmNwMu1j2i ViRyMIPeWNO/HzZAxNgZYY6QcgAxLMVpyNzTlDtojS5zdS/eBw8RkFNPN1L6Qfx2 ylgCiuFws1rO7b6Cqbpyps4N26wpsb7tV8yGFjcTYuleUUOro85JNrlrRnl0/GLr YmSYbsKUaXtqHkNtRI4EPwIz78QwBOCjRFTvZTONA+Xz46YpuovD4L0r4JCLm3G6 TDUVknYJ51sjRPJxt9/9 =QCzD -END PGP SIGNATURE-
Re: [PATCH 1/1] wined3d: Introduce a helper function for printing floats in GLSL shaders.
Am 11.06.2013 um 09:27 schrieb Henri Verbeet: We always want to use '.' as decimal separator in GLSL, instead of the locale specific one. Reported on IRC. I think this should be added as a code comment above shader_glsl_ftoa, I don't think the reason why we need our own conversion function is obvious. The ARB shader backend will need this as well, but I can take care of this. What external software triggers this behavior? case WINED3D_DATA_FLOAT: -sprintf(register_name, %.8e, *(const float *)reg-immconst_data); +shader_glsl_ftoa(*(const float *)reg-immconst_data, register_name); break; shader_glsl_ftoa doesn't handle inf or nan. I assume that's intentional because they would only trigger a parser error.
Re: [PATCH 3/5] wined3d: Pass a wined3d_resource_desc structure to wined3d_texture_create_cube().
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-06-05 11:06, schrieb Henri Verbeet: +desc.width = edge_length; +desc.height = edge_length; + desc.depth = 1; Wouldn't it make sense to either set desc.height = 1 or desc.depth = edge_length? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRrwNtAAoJEN0/YqbEcdMwLkoP/jN3ooH3ur4ZLMgSc96VT+WR b+EcwCmK1yigPrY04UPiHmSVSS/g9bgR/BsVoQB9d6Fa2UfFeDEGGgOYdVOE6/9P guRWs6RAMTv4AfuDCjmRC3h2fO0nigg3sLkmvqG5qZF8hmGbItijB5zREWHys3Bk kedPMQaWXWuq9wwHa7ZM1B3wcMiZsxqfcyitFa1FsB7LvbLHIYuMzNQrViObGvT5 75J1Ux/WmFu9ZKTvWjIyFzhWg9oqeHPpB1lXgj4w3ONkOa0Rw27EUsxHRTlGiYm+ 4qGyvclsE1Ep2A2NK/kCUU1SuxeSP/bW38P9Lc8J/xNb8Si8zNu2VApTYjOIOk9q 3wHKgU0MuRRnw5ophMM9xNhIT/lt+0FilNZYosvEul+A0tAhncthCege0ZBRIeSf ZKlRGrInBMSy59BJwxVvPxaF702M0xHdkpKEMnML1NYCRg9+gbm862y/KRczvBxL kRWs6AIBr0247voTHvhRBJTtEanCeKP+qGLoatNVimPFaEDnSj9xxHIA+4XaThPW 2A+WjSPc7ni0Z8IKGQB9hOku0ZKvX2BJIAXiFm1KQW23psqUHF5CTR3w48yG7Dmh pm8SETIud6SwakKTW5ikp5ObjLYdM1Z8M8hNIkU64O8k7+aSX3hAqKW2shC6d/xm REcwzCU6NhmbDWgC5epH =tH28 -END PGP SIGNATURE-
Re: Question about legal requirement on gsoc page
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-05-22 10:59, schrieb Christian Costa: *You are not allowed to analyze Windows files with the trace functions of Wine E.g. when you are working on Wine's d3dx9 implementation, you shouldn't use native d3dx9.dll and create a +d3d9 log to see which lower-level calls d3dx9 makes. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRnI5hAAoJEN0/YqbEcdMwRCEP+gJc9bC+L4h2J9KpOIe/qdCm LWTejn5gzvVRrhP3RpvQRsVaEabYrewilAsb9yqE2NDyhScS2SoPlcQXLujZ+GNv /xK9OV+zXY6xWgoy43ko68z0WQqYnkUgisGUyEjGYga+clXswU/ZTTamovj/zklM wCsaXuoJPvoRRPfzTN5xdB16ZHGjZBRyLR3hMtRa0guc3y4brB1rWw0Clg+ODZeh a/E0gfkerfrXZNwiGH7Ws4vv/ECJRoDU7HqKtOSA/m9pnmlXps4XXT5TCzqUZ2QZ hJJXiUOgJpx0yGyDmFoKThkRmhcK7OxX8AafG0dKqE2XaiQD8S/9tHH6QglsGVCh cGlTZdrgFvxUonnaokYvtV9jel8VV2De/S9HBYSoBfCZBQC7vcvZfDqcUVL0BJCq 240Cx88p95XrpIxwpzCht3+PzQNJ0IaZOzGpTZUJEdsLZ30mjbQKIVnHypDgUKYR pyhIcBmxP1/fFIN5RO4cvKWLL53zauZNMgfawIKDFFQMQgeslFhd5Ark+eVgcuol geX14ivHgktq1ZFtFsRkoiSBurgas53ZIU80EPeAN2MXlG/FK/GQZf8AuXGMq1mC 1KhDybuiEUmtjKx1Kn9H4tAFKB3QTYIn4aee1kNzh+urGDg9MtjJLYOKAR8DWIXN sZdfEdnrU5D5mRtJvjdw =Iu1i -END PGP SIGNATURE-
Re: [PATCH 2/4] ddraw/tests: Add EXCLUSIVE-NORMAL coop level switching tests
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-05-21 16:03, schrieb Henri Verbeet:
On 21 May 2013 13:18, Stefan Dösinger ste...@codeweavers.com
wrote:
+static void test_coop_level_versions(void)
It may make more sense to move that to ddraw2.c and ddraw4.c
instead.
The reasoning behind putting this in ddraw1 is that ddraw1 has the
behavior that differs from the others.
(IIRC you can't QI a ddraw1 interface from ddraw7.)
ddraw1-ddraw7 works fine, ddraw{1-4}-d3d7 and ddraw7-{d3d1-3}
doesn't work.
I'll look into your comments for the actual patch tomorrow.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJRm8ZVAAoJEN0/YqbEcdMwe3sQAIOeXETnqbHU/9l67iM+omSK
tjFevbqdMlpCF7IzeVGQ2kYeRPEPxair05P97vp48c46g/XZf2e0WvSFs3TVZaPy
OOjFSKxoDtn3S0gLcXCcrjs6MLL9sP6K7emi1Eu+apKdMV2z1uEHZnV7daU4ZAxs
JNRxvRXyEBS0UXRI0cYW5+QDQ0SPLYi4irqv3j8K+Em6HQSHm3W3fzafip5ucAbA
zJgBiAxKjbVOgQWZ7dcb5PU3zgyUuRKtEs3X5dteQy1rWstRWIUGbjgN7qNMcPy/
imN+pcHknbWiCdgHY+nj1A7nxh0m4HKKT/77aZj16TZTEJFXhNW768lQ+f0ZOJwm
Hf/kbL3p+pA2LDM/jQ0C5g9s1sKkctMfRNmJDj0VThFMkKIpuoGlFzDuwAVgs++X
tMeW2SAcgx3qW+zIMNGQcKON6L8rslRP5ZzkFukSsCC2hQ3dOfcOAM5dzRzEQXku
WovU2hheYSOqXWwO+k80QlNMXLTX2qV+6+8ONnmwY4pdHgAXwIddKYcIRhOKofRu
pJFHVJEtdi3utmba2/9RMIosQVdrcXmEDqGazbpdTY9VuJQXlpeQ0xdycpwsqPxR
4zJaG0rMoosg/MmW5o7CKE9M1lb1kMiK6i1xfVbxSLviPlZaJGDGfFsxhUfmsorJ
6cgiD8bTCBj3Z44SygWX
=jVym
-END PGP SIGNATURE-
Re: [PATCH 6/6] d3d9/tests: d3d9ex video memory accounting tests
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-05-20 23:03, schrieb Austin English: On Wed, May 15, 2013 at 3:32 AM, Henri Verbeet hverb...@gmail.com wrote: On 14 May 2013 23:46, Stefan Dösinger ste...@codeweavers.com wrote: These tests have the potential to break on Windows when other applications create or release a large number of video memory resources while the test is running. Yeah, maybe we don't really need this to be in the tree, although it's good to see for reference. It seems like a good candidate for if(winetest_interactive) Good idea. I'll look into it. Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRmpdvAAoJEN0/YqbEcdMwc+8P/iug14kSI/reco7yQCXgmQva QKWpd7yzEgIxgSvCgrLN3RAydVUZIhgm1gSAPwp3ZUeLGfsoOtDzBoUC1F+n75mW GwatAkgIQro6I3mRWEMwxdW0TIvgD96/T6d/8ESXpUtPqKlnayCdQ5o7VYcWi6Kl OGo997PEZvrvSSSa1/aKg8iz/l0RfGAKyOTMdNrT6Y82n5PtZ7I5oYTRlZXezL2c uwy4yP8dBekggHGsgBBCScvHQXqLMHXzEtZ2Rn9MjhYyNs7/lg0IgWv2kNDSFNAg ix2SdeA/POfxprhZLB5KtIphlrjJY27YQWrkpUk1D5oZk81ThfaMzFr1jowkwRB8 NiEFkYmVgmN8Up7vup7UvM476oKfMLVm+YnDh0tpr/cmAzEXPSpuheaoco84XbCe fRf3ODz5zY1IdGIGkBlUvpmOtGBu4rwouNpSb5HA53W91NdIQUbeRMdIXPPnf3er /fPjsU/QptvOUWvfravzJPwcj4vbxIqNT9NvPKLSNYWNDslF21zA50orT049PPzx D8JEwHBK0sD0ghELIBqUaIqFf4q/NG69a9JNG0PP2EBDR+pLM6mD4GqpMwRkX1jd IsMKGpi1PIjg04mh5UWFr0RRXJ4K+nBKDADx+YszWQ4MkHEzPMOSnhMXy37VDDgd BrigQbEjcEgETpEi7z9L =2inv -END PGP SIGNATURE-
Re: [PATCH 5/5] wined3d: Pass the state and private data to shader_select
Am 13.05.2013 um 15:28 schrieb Henri Verbeet hverb...@gmail.com: On 12 May 2013 15:30, Stefan Dösinger ste...@codeweavers.com wrote: /* Disable shaders */ -device-shader_backend-shader_select(context, WINED3D_SHADER_MODE_NONE, WINED3D_SHADER_MODE_NONE); +device-shader_backend-shader_select(context, WINED3D_SHADER_MODE_NONE, WINED3D_SHADER_MODE_NONE, +NULL, device-shader_priv); I think that's a bit questionable. Passing NULL state happens to work for this set of arguments, but I don't think we want that to be part of the interface. I think it's the best solution. SetupForBlit does not have any state information, which makes sense because it has no relation with d3d draws. Even if we grab some state information from somewhere (e.g. the stateblock, or the command stream) there's no guarantee that it is set up in a useful way. It could e.g. have a NULL vdecl or mismatched vertex/pixel shaders etc.
Re: [PATCH 5/5] wined3d: Pass the state and private data to shader_select
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-05-13 17:44, schrieb Henri Verbeet: Maybe. Perhaps we could also just get rid of WINED3D_SHADER_MODE_NONE and add a separate call instead. Sounds like a plan, as we're never using WINED3D_SHADER_MODE_NONE for just one shader type. Please also skip patch 3, I'll adjust shader_arb_load_constants_internal according to your comments for patch 4. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRkTOVAAoJEN0/YqbEcdMwIykP/2DuAxxc7ypiXFO2IDoRqmXZ 1DZFEua0317+IcBx6hHc3lqgsh9ibg3+2slE/CrWHwKCWlxzUvct6Y2j91tk8R5W 2DDFW1J67mJS/oLJzofI+HrghISC0J+jfKwdTI61IEp37G49JZCD7dnxr9rlEJDn rb3p0taPdvXYKB3goZiVQo60wf/FIDE7PxZ2/oGtYKVhuFfsmU3DurYeMyeQkMgd Ma5iHDhZP/V5zn36+kc7nxAFdw231Znne5LkHcnBKgRGwBGGf/uJCSmg2SDYUzSM gAbDiWatF4NL2J1XG3zuHTKNHDL0BI5WUyBTtM85BkcwkRJN3DsLzcTZadrsXcsj BuibjYJD3M4TFHWMsX1GFTf/g5msM08Wqk/cHt2Gm5vDmmRMOcEo5EQRGOcSjrg1 Xl5pUTSCyb9ykUB8idW/1dUGP75XpS5xQEtgLryuZVw4xOORe0izsoA6UadHMzLz KqnH9SQKhm9LKkfIKCGWLAMAcEXn5MwMcq/okkQZmUiVbRZ/RIy1Pba19+tHfv79 CJPTrgdNl3KMNF2/a4qcqyv71tgcutYjfdufvRdRLZrmmM9lVfD0CJ4U1/OafKC+ EEDKBgbrNUuZIsN+ebuxTJjfChPx4UrFD7WkSCI1AvSZhjchaobXN2/tNjElt/8j n2PzMahocsGHnD6BmzbG =CHRn -END PGP SIGNATURE-
Re: GSoC proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-05-01 17:14, schrieb George Stephanos: Tell me if you need more information. Hope you consider me! I can't comment on the details of the proposal, but please note that you have to submit the proposal at http://www.google-melange.com/gsoc/homepage/google/gsoc2013 . -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRgTKXAAoJEN0/YqbEcdMwYdkP/28gEJNvADLYmLGdHRHuSZil R99heKrRgIs0laL8pnTEzlR0rR88MlhsmhVhjS1CYECp/8vzVKJENxk2KDKC6O8V TJHmfqoZ4HrBWKiMuvruw5feD5fbmYeKri5sj/Fga2Ql4VJDohnE6gonyWk2iqpe v4l8/6C8O9+B3Slg9UQOiI5FDlQx47QUlNo2j4jgl58Hz/gWtg94JkkIKTQ7uh2T eF5A0JSTay4+2oQ80vguyADCw0bD2rwwR9W/Awm7XSItEt4hG2icTe6I0R6hH297 aVGLqH3P/d+CplJ4biupH5bgYuUvjVaL1bcga2b/FVe+uBXrC0XR5Wd953Yg2z+0 0MEITZ2xh1Ef3Ea3oti9L4RrvCxrUrblTyn2jUbyR5USug4NfE3+uiUXgS1RalUR 6t9MuSTJtTKK0zAyXgYcKLAWOoKSPbjdOweIKBU0capYCzk1VBQJxQwusSL4XObe 7oB2RnVWDnXB0vAFF4aBlQCBJhTmemz7tJKz3JbIHHfj9/3JXZEUUp4Hlhmf3GS/ BJcCnWrFSMMVTy3SGVOyZP/F8pNO1V160RkmpGgK3TwiT1o80Mjoybtxkotb52+6 Xgavwfk77eXSQoMe5iXVFkTI4JTifRnLgQx7sqii+laoCvpTx4Z9XAP9qME8zn7S /Qy9akUiuYwHTAlzMTCp =eB9p -END PGP SIGNATURE-
Re: [PATCH 1/7] wined3d: Add a new structure for for d3d limits and other info
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Please ignore this patch. I figured that my series might collide with Henri's, so I canceled the send process. And indeed there are conflicts, so I'll resend my patches rebased on top of Henri's. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJReSS/AAoJEN0/YqbEcdMwElkP/AiDEqVSaMxTW+sOaQava97g a0cOBpHTU+lInUuUXIS2WVe65D+IhkdYJHnMIrSUVdquvT1x+pLVgr+2J4jczFX7 /9Ay0gAjMVbKsKIYO4tvOQgSru/RdAljTg6uaIw+qTDrHZvQLW/sJu3JcbAp0GW7 9pGEzPvRr6hNsOyXE+DQlTEsT3vkbEUTRr01j4+znF50laYV2s3e5saZHyXULyY8 ObEf3n2ppQgcO4keQg7wAPLydw+xiNcYOw9724fh/xyezj8MXoT1CDHeio7yPfhg xp76kNWzNERQcWaDT7QXwuWLRXy5H3VodWm4PEMXvqXyxkJJycm2jECvTOTjrrke iswKGqh9n0gTWQjse2eUY/fKxpjhh/ySxDcJq093swHHbvrCngL8Q5dYu/Ch3cFu JbLu4pHla3iAmJKftVTT/iRq6vwsLB7tzloCoA7e8T+GFmsA39RPFI6zttCIoA60 kui5a4Ofd6/sGMFaqg2VBK+2crGJzVzN6VRvglg63A0hNr0UGbkFC/6iQK8FzxyA A+uPGr5Xrd/vGpKZksMMH68JiK5kYXm+fsiVI1F1rcAcfdh6STQBoThcig1N/HXu fA8daluv4+PgQ9RhgzlioBsVFGxkZ1FbM8XjKlcnKQb0ZK3DXLHLEzspvmBnr3Pi MK94F9BvqMDa6Wi57sgT =Wh/i -END PGP SIGNATURE-
Re: [PATCH 1/2] wined3d: Remove leftover texture accesses in GLSL shader generation
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-04-22 14:42, schrieb Henri Verbeet: On 21 April 2013 16:51,
Stefan Dösinger ste...@codeweavers.com wrote:
-if (texture texture-target == GL_TEXTURE_RECTANGLE_ARB)
-sample_flags |= WINED3D_GLSL_SAMPLE_RECT; +if
(priv-cur_ps_args-np2_fixup (1 sampler_idx)) +{ +
sample_flags |= WINED3D_GLSL_SAMPLE_NPOT; +}
I don't think the added braces are an improvement, but otherwise
this looks ok.
Personally I don't like ifs without braces if either the condition or
the instruction is spread over more than one line.
Afaics the code isn't quite consistent in either direction. I can
resend the patch without the braces if you disagree.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJRdTGfAAoJEN0/YqbEcdMwKIcP/ieIu1iHckCe1hSoG+Xx5YAm
4DBCjak4xlf1NfmVSik0RduCCG4mR1w2ZWkYXzrHuHUsQlh3ILsNe3nsHIOj/M4K
R82tmWfCS0iV5xThnGiIdVs4/7lkwcs8ZJGZDWhN8bvDZ3CtJCVSCepulPt1LJ8Q
+G2S18OKGIXgtQTYNPgvGK5V3QSpuSkAWkmfL45II9vD1/Qs4/SIEF/6jQrJ9cya
7DRnYhMRdZaz0zfrvjrq6rUQOWwtLPj50zDCINLS1w6prMZugyB9zdB5xmnAjzu2
eR9Dvh/7USzoFkbv2KwFwBQhxj5202+iUoDJEcKZ765GveeN5d3+GghLN8M1B8jR
9alSRqsirWvxiu/HT5W3e4Hm83TMp1XOrAgfrCQHjg9PGfQ/vWVjpf+uVh5xprzC
gRLW6ko5I9QKsFDuoeg5revedX2BP2z+iUH1zRIZhLnegdnEwVaIuuhPVZ4bW1WB
QqxfaMBuKJ8B86g8OEcE8BMHDF9qXCnd9ewS0qHpPwshvkBP3GJdJt1w5tVmvp/1
s/OTV4gBYIF6ZzWX89Boi0dWyUnUGFGl9n4FJbN3473SeJor0HkZHAgqXLbDgP/D
AbpmEgdiRhPTRGIfO42mwSqdOZjyXOvh5E2HoUlfxoM5xCqKkzrC2HqGHowUaxUy
FWJtBflkY/oslt8BQsLS
=qysk
-END PGP SIGNATURE-
Re: [PATCH 1/2] wined3d: Remove leftover texture accesses in GLSL shader generation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-04-22 14:54, schrieb Henri Verbeet: On 22 April 2013 14:48, Stefan Dösinger ste...@codeweavers.com wrote: Personally I don't like ifs without braces if either the condition or the instruction is spread over more than one line. Well, I do disagree, but note that that reasoning doesn't actually apply here, both are single-line. Oh right, I changed that from a first version of the patch before sending. /me bangs head against wall and will resend. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRdTPPAAoJEN0/YqbEcdMw/5kP/2N5YFuzEKsjVLR29ArqBEha qsYuQUOLq6OhguUK/cksTidnVIMQ9V99aFVTz1RXdgAfWqVhIZ9UhE8M1cSKTq2m +VJEtCmDzsuocUg7ZWNq+WOPivE65D/HpS+j1g6B3VTfeRXUAWNAICHz3B7jB1lO wmFLXOuWPha2G6n89o+nN3lFBhNSU3ViFMxwjPWXKqrrAxRKGRIKR6aHyKqajpsP dIeppHO6UXcj9Pxb44GpXdlwgKYa17eIM95i7pzTV0m4mmyMRGGr4L4HCVcZhXuk PUULZE5lKJM6Ada8g3xTtsfOc+SazSWyhZpFgczqBAGQy4y4gn24xcMREz0xtEwI v27xFuKFXP2XHi6sSbAkTg1FF+S+hL+S2Kn5J7SAHa2jPD8YHf1zZlevCvHW6Gpi S2ivTys+wNnHEOjfv+dnR7fOBHkCJhMs6f6loGvaeGKx5i5q/HsopcrxeZJXfIuc oFRZJgw6HbzPWltb3jvA6XTmDQFUH49QvqY3DoZRO+Q5aTw29Zt6MC1hhEVdZMWf it2RVlKfdd+t9Ou9hDkzI4Qn0hxx7cwsbQXignghwQfeiMKjrZQDhn2GPqKv1wEM Krl/ZHoagBnodiFr7HGdhewrHntGxTEphR5ygZc/mgJtV7A6wqDPmzbPCX6OJxkK SJDm3wSw3f+t11u6AyXC =M+Ry -END PGP SIGNATURE-
Re: [PATCH 2/7] wined3d: Store vs_clipping in the adapter
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-04-19 16:26, schrieb Henri Verbeet: I think we'll want a separate structure for this. Note that you essentially have two different kinds of data you're concerned with here though. One is derived state like e.g. the texture unit map, the stream info, or the view_indent from patch 1/7. We don't really want that in wined3d_state, because there's no reason for e.g. every stateblock to have a copy of that. Having the derived state structure be owned by the device is probably ok, although there may also be something to be said for making it part of the context instead. My plan is to move the tex unit map and stream info into the context. This is fairly easy to do because it's already the context that triggers the update of these data structures. The tricky bit is the lowest_disabled_stage because we have two pieces of code that use it. One is wined3d_device_set_texture_stage_state, which uses it to find nop state changes. The other one are the state application function and device_map_fixed_function_samplers. The state seems like the best place for this, as both the device and command stream have a copy of the state where they can keep their version of this value up to date. IMHO it makes sense to keep view_ident close to the view matrix, as there's a pretty direct relationship between them. The other place where it could go is /dev/null, I doubt that it has a noticeable performance impact. This needs some benchmarking though. load_base_vertex_index can probably go into the context. At least I don't see a reason that speaks against this. There's a related situation I'm not quite happy with: The dirty states are stored in the context, but the values that should be set are not. For now I've kept this setup in my command stream patches and didn't run into problems. There may be a nicer approach though. The other type of data is immutable data like derived caps and limits, as in this patch and following ones. In principle the adapter is the right place for that, but I do think we want a separate structure for that, and probably a pointer to it in the context, for similar reasons as having one to gl_info. Works for me. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRcWVLAAoJEN0/YqbEcdMwDAAP/21t5qSPPuX+CR5ur3qj9qe2 OfSJQUfmw0L5PMETxzq8TMcGI4qjcI11GxvocL9JBsft7aYxLWKJibwOcGvcdRJO iaoHjYow2xfRMP7QgTrlP+Ii/tfpHHJHW4kw54pcKVEJnFbiDtMBGvi/IdFnXiW3 vSJAlaPojtLz2rbWSlImCiT8b3DgQ43KY4YCNSGvsG/ATXrhOpTAPPDEZ2h/28Xp oKQ8zunob8YVWmb4zl7BJjRWJy3cj21gUgnPxLdmpqsbZn1Y6tPQj5iGOdfkb0sN yieR1y25JNs5L6C+PrbIUW22lrrAzmvFm62f2/kugwWROdZK0gSAD2L0rdfuo5CN xE76iZqdCoDyMy/PyEgPtMzKIwCHa7mOtfHCkpHvHHnBdLEcMTdXA7pFvKmiiZnB bAseA+06jMl3+qphGfk4W381LCE3OUKE5t05KD1zqNhM26muh3+TC4GO702FPq+N heIFuw3exC9f4EEyfbDJ21PtLVDFQqemWRdyfTy8UmjgFrEB9vr1HRdPnLUj4YZV V7s/bh4/Wzco29N//1oiQ5K2CoqX+AtbnMDtPoFd5/ox8BMbJF+H4JojeX14NH+B 183dWJUC6fMve5trVenw5dkq56tv53Tls58NepH6k51TVFh7KRn5tkVDRjlfywUp gvBE82NsnSWxDZi6rnMG =WAaZ -END PGP SIGNATURE-
Re: [PATCH 5/5] wined3d: Enable GL_ARB_texture_rectangle in GLSL ffp fragment shaders
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-04-16 17:01, schrieb Henri Verbeet: On 16 April 2013 14:48, Stefan Dösinger ste...@codeweavers.com wrote: +if (gl_info-supported[ARB_TEXTURE_RECTANGLE]) + shader_addline(buffer, #extension GL_ARB_texture_rectangle : enable\n); + This may be a good idea anyway, but is this strictly required? IIRC ARB_texture_rectangle is the one special extension that's always implicitly enabled in GLSL if it's supported. Yes, I get a compile error on Nvidia otherwise: fixme:d3d_shader:print_glsl_info_log Info log received from GLSL shader #21: fixme:d3d_shader:print_glsl_info_log Fragment info fixme:d3d_shader:print_glsl_info_log - fixme:d3d_shader:print_glsl_info_log 0(5) : error C7532: global type sampler2DRect requires #version 140 or later fixme:d3d_shader:print_glsl_info_log 0(5) : error C: ... or #extension GL_ARB_texture_rectangle : enable fixme:d3d_shader:print_glsl_info_log 0(10) : error C7531: global function texture2DRect requires #extension GL_ARB_texture_rectangle : enable before use This is on Nvidia 319.12, with ARB_texture_non_power_of_two disabled to test the RECT codepath. The d3d9 visual test uncovers this problem. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRbWnQAAoJEN0/YqbEcdMw0U8P/0XUFynxe2xQY3E+clFHgFs7 MyzXcAJMTi0kCxNHsOCiTtP/wzVVpbRAL3MZFrouAXtMIEuJ/Mtt7JRB7PrwsQPV qgl0CtjGXB0e6ftgi3shnXprcq5XVxl74R4CV14//VcGRfHPzczDd0qvrRlKFFv9 I9fgABVboPDtezq2JrxNmIemMU6D90eOx5MSjqJyf1ZoqfCpUKW0e4UrmRUiwm5k HGquu0b33iCvyJ+oZt1szItyQqLK6p5gERKfEvCTLr17mawrO4Q//T8D3zFVBdaZ e1xls0euAtks/he8x/ZYxmC8mrEYS+TpwWDwr6MDth+w0cxw218Z/B2vwbH95hmQ +Ah7Ky6xFfwtUsFXe8Ry48FFE29s1iPvijvuZZh04BKa1rmrMP2sog66VbStDxhT gg1D3PCKJ18fNT396TkJL68Oq1VrikliEExkYXf+xI/TWwDin5Ucp7Qy+cHqZnnG UBpV2jM+WNDDI4j1D6Sr+Q/d9h0d412fObJC0L8DWkN9f8lob2oUvF0kjYMc029z NPsjtIllLUVRwOuu3Iwp05Z553f5A5HdhUnzZTyvgyQ8yo1tVS1doh+ErjocP9ls xxkV6W282z78lVuOk8iVTadxVMhfupmZ7v2eEXSoxf5w/DNszt++ejR33ot2sQgA S8p0wgrYDz1YBd5Pv7rz =ZHz0 -END PGP SIGNATURE-
Re: [PATCH 1/1] d3d8: Don't assert on invalid IDirect3DBaseTexture8 interfaces.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-04-14 16:53, schrieb Rico Schüller:
+if (iface-lpVtbl != (const IDirect3DBaseTexture8Vtbl
*)Direct3DTexture8_Vtbl + iface-lpVtbl != (const
IDirect3DBaseTexture8Vtbl *)Direct3DCubeTexture8_Vtbl +
iface-lpVtbl != (const IDirect3DBaseTexture8Vtbl
*)Direct3DVolumeTexture8_Vtbl) +{ +WARN(%p is not a
valid IDirect3DBaseTexture8 interface.\n, iface); +return
NULL; +}
A test would be a good idea.
Are you sure that the assert is the actual problem, and not some
memory corruption that changes the vtable poiner? What does e.g.
GetTexture do after a bogous SetTexture call?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJRa7lTAAoJEN0/YqbEcdMwNjEP/RLeLk3+009+Cp2n5sWOUprn
Z5ED8iL3RXRjsCJNU5Fi2JIkCcVRmdkkn2RTBN9Q9KEkUL0qjg6B7Admy5sWtMIk
LDtYpjS6BeDIJm8e0D0HwGItv2ekxW37ggg9fsArcXUO/lKf2GrJmUiyAjQfzmT9
IDlewcLSzUiAdbzZ4WUZzkqIa9lQgDpZBAvOgvgqhY2suf+YpJi6oTMfgwzpiSyB
L2mlXx4cb0/hYaPAdWZUbc9uHvsCQ5ZwE4EhIxWpMlZM8FENMN3Gc0vrpzWAXoBo
XRifoh3n0VKaYyZ+Wi+zGRaFX40P4ouBUKuFcBdjEPq6Fhz46GEGY8KFf1MVZKwM
7pzkhv6yc8/GTr2q5wthhmnZxDLHIZNyVEoMU0AFB1M0V/k0sJQfXpCCA/6vql+g
dgUtyPggMSefwT0lc/7S/UwQdvuRYyIcdVd47alDJyRfU5NOMx091IiqkKXm9nby
nqGAfdO3GDQoOIXJpWD5E1UMPHt6AGXGsfypkuVTtTljvOx+U7S9ngBeFkjuor8+
VFwStSFGboPxAjfKqzubdFcPcp4t8E5/qqkXR+Nc2UBJV5XeC3Pg5GOZxBsDZvbz
zU4btX6kgC1Si1vIkf+D8CyZgaoPSwiVgGfVkTaqYSqnO39JZ0SpjYlv7e4yuhfa
jkXNYd+XevrLq435YYir
=TVml
-END PGP SIGNATURE-
Re: [PATCH 1/1] d3d8: Don't assert on invalid IDirect3DBaseTexture8 interfaces.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-04-15 10:53, schrieb Rico Schüller: I'm not sure what GetTexture does, a test might show it (I'll have a look). The problem might be, that we use some members, which native probably doesn't do in SetTexture. You couldn't call GetTexture in wine with uninitialized memory as we do currently, that's why I think using NULL is the way to go. Given the circumstances, the patch is probably the correct way to go, yes. Does the game just do the broken SetTexture call once, or does it repeatedly try to use the released texture? What happens when you pass an invalid pointer (e.g. (void *)0xdeadbeef)? What happens when you pass a valid pointer that points to memory filled with zeros or garbage? If SetTexture does not crash, what is the return value? Please have a look at http://bugs.winehq.org/show_bug.cgi?id=33055 . Well I think there might be some memory corruption somewhere, but it doesn't have anything to do with the this bug as we use already freed memory in our implementation. I don't see anything in the log that would keep the texture around. There may be some capability flag issues that trigger a broken codepath in the game, but such an issue is really hard to find. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRa+l9AAoJEN0/YqbEcdMw9qsQAJFvdFH3jGhrVsyII++ART9J etfmFEfsFcw99m1mkPfpUsPqtlk0tiwWJ5OTI6pcoa5zAqh03e9sr83xQYvxyX/J B155EW5CepOMbTKHbedPyS2UXYcdRCFxN0w6wVcWRMap7WTLNPWLC4A7XGFNhkSZ ZIDM7IlDjOntHij74tdxEzx+xs/aZsgaTcfWaxX3IzrHsxOb2gywKI3NcrTg+TNT yQvTq9ac2jeZ4U7nHnASAfg9TYZtIdNygK1DhuHWTx9QEo+Xb+Ik09VR4zYWmCEt EFqxIcNnSqCDqVO9lDigEpUSLBqfpxTBdb6SPnQ6vJhwjO/XTYl3fKWzby3IVgEH wo8p+T7f3n+rnpNocQ7BQlVjwIqyRwsPj6B65xaB9Sxv+zd1hTiPD7diwLh4bveX VEpSXRkfESAOUgnj8HWiRczSb/9GN2m2YCdgiHIyXMDd3TcvNagncK2o5ROC9s3i cN2rdyP7nFYRZzwyn6ttN+gAeFjcK1Ryk37nCF77HkKiFCqE6cqGTYnQxDPH8D2m xaKj36vjswg1Tk6PoZ1CN/isW99psbRHaNcdimW0ExcoboiePD8qMhdFLHZ2a123 Bdbti4zUkUIhGt3VnE7MQyMZ2ivWLSXrbQplFQcViz6gmJB+hm+LJl+ONBRNky1j ADcAEILlJ8JVLXR9EDCV =QLR7 -END PGP SIGNATURE-
Re: [PATCH 1/2] wined3d: Use the np2_fixup to find out if a RECT texture is used
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-04-11 13:40, schrieb Henri Verbeet: The basic idea is ok, but the conditions for when np2_fixup is set are a bit more complicated than that. Specifically, look at how the WINED3D_TEXTURE_POW2_MAT_IDENT texture flag is set / cleared in texture_init(). I think this should be 'fixed' by supporting conditional NP2 textures only when texture_rectangle is supported and get rid of other situations where we scale coordinates. - - Fake NP2 cube textures: I don't see how this can possibly work. We're merely length-scaling a directional vector. - - GPUs that don't support ARB_texture_rectangle: Unfortunately I don't have one of those, but not advertising NP2_CONDITIONAL on those should be legitimate. - - Fallback for P8 textures and EXT_paletted_textures: Problematic because I can't test this. Not sure if the code even works... -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRZ70nAAoJEN0/YqbEcdMww1MQAIYlL31TtEyZ0z60Ki4KfX4w bGeaFbfMJPEcgOVzCHxEStmUaHOJFsJufdeEvw16Fs0ZoRHh45O5hRaNaEGCEE7i bFu5j1eBRXqHmYOrgwoJ328SG/wLAUy2DHyt6EeiebBKsrhvyUnzVDi6qocvie5V 6KNN9y+PB8PE6yipR4Qtts+GBP8jOYvMc38l6S2q9Bq2jNv6fPwXtYsIlQ2Ltl8a RCsQMSVJashOsBsne6VOJ124DbCT9KzIIwy0/lKMwqxoN+Jvj+Xo9jO4XPEZNUOp 7AsbKl+ssp4JyTjjvxVu4QXXK3EzrpxmCverUxkNG1MS5RUAivKkn+gpCjRVM84w e2BUy6F5blmig64JuvIb77b7DI5DT3aZlsenGkYkBaITE71szjjssiWlTAbLHf7/ hGIrXklXvf3xL2g+0dCg10lvHA8/1ty5iwG/O1ZH51o5zBCBUHg5+GYNBx66mRgZ oMXHds3QYU6XIp5S79TmIQPXRBlK553O/N0pwicq98uFh025qjC8GIEkflAqJaKk CSuAA7diizPLYLWUX4XdAcnDx8H3Xp+JS4SpqsaL61+mOD1gqgnDd5Hx5GgwvqV4 EM0riZq3TeoRjfCzBmn39PSvRIajdVU0Civ9JOj/raKKfQqzIG7KiSYG6T8n9Vl8 7XUAIf0TzEYEbO5P5XF9 =c0yJ -END PGP SIGNATURE-
Re: [PATCH 1/2] wined3d: Use the np2_fixup to find out if a RECT texture is used
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-04-12 10:34, schrieb Henri Verbeet: Possibly, although the only really problematic condition is the 1x1 texture one. If you make that go away, the condition comes down to ARB_texture_rectangle being supported, having a 2D texture, and the appropriate bit in np2_fixup being set. I missed that one, but isn't that dead code already? 1 is a power of 2, and the code that calculates pow2_width should recognize it as such. So there shouldn't be a 1x1 RECT texture, and thus no RECT texture that doesn't have WINED3D_TEXTURE_POW2_MAT_IDENT set. - - GPUs that don't support ARB_texture_rectangle: Unfortunately I don't have one of those, but not advertising NP2_CONDITIONAL on those should be legitimate. Yeah, though that's also more of a generic NPOT texture cleanup, it's trivial to check for rect texture support in the shader code. My prehistoric mach64 GPU might not have conditional NPOT support. If I ever feel like messing with the empty cmos battery in that laptop I'll install Windows again and write some tests. Supposedly we can't really texture from P8 anyway, and certainly not from shaders. I'm not sure if there's any still supported hardware / driver combination that supports EXT_paletted_texture either. We should probably just get rid of any remaining EXT_paletted_texture support. I think the point of that code was to support P8 presents, and GeForce 5 and earlier cards supposedly have support for EXT_paletted_texture. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRZ9djAAoJEN0/YqbEcdMwS+YP/jagWaMrf8TX3u4+qVwUtM8P wsgmIdQR+AAP7tr79cA8YzCEOomH7KvtrucfNDooGiRvvMV7lsEWUEM0lPjqoQEj NLUwZTaF0kKPOOnj6Mozf+T9acnu73Jvy4ghk1bzmvy53yHhS9DaMQ5smGavPimy 1EbS2ZG3hFJtZmDNmPlBRGJLHg4noUhGiDpbt93ztz8PtuoryTfVeq9TT/rdu0zm 7njg1kgY+Dvzyk5bSv4HxVGrrlmoY0FmFxM5u/7CjzkJCxZhqxpBuySrl7toWH4P pgWyeWsdM4PYnbjI0JUq+dIzp6Kn0HgCqEZWNqsdUg9VE/FOS705KmJH5uVUybdG y3peEav4PKHvgvjK9L3m1lzr8pWQUOqIuK6LiV8pC6WhM18TWTfWCnfRW4xjE1q/ a9yqKU///YX5FKYt8MHIk1/3boFN1V3pewuJ33M1oJ7Tc/D/FG8rGZlpKFXez8m+ SwgOUoGjcAWmSWnYQbSc9Gqo6hbivWZoAtbg0e78k3CjmYyK9OGpNgI6vMrfTt65 lamECLjBkVdf0O4Zgkg7Agsd6y4DtymNaEy5Kk4JwMX6OGb2EtyPYHS6sOGNmMpw rmCKmwiYr8yU71Td058kUL6h/CjrhOCA0pa6IfbngykaRfgfFUEMWdxiLSSefdnz q8f34ubBt3NZVidCS3UF =WWCJ -END PGP SIGNATURE-
Re: [PATCH 1/2] wined3d: Handle texture types via ps/vs_compile_args
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-04-10 14:28, schrieb Henri Verbeet: Why do you need the sampler type for anything other than SM1 pixel shaders? I'm not sure what you mean exactly. There are 3 problems related to the sampler type: *) RECT vs 2D samplers *) Shader declares a 2D sampler but e.g. a cube texture is bound *) SM 1 pixel shaders Also, while in principle I'm all for not accessing wined3d_state from the shader backend, I don't think there should be anything in the command stream patches that would prevent that. Correct. But accessing the stateblock to access the state is a problem. Furthermore, we may have to recompile the shader if the app switches texture types, thus we want this in the compile args. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRZVvQAAoJEN0/YqbEcdMwyYEP/1Ez745CKD3CxnYK7WNuG2L3 0MEqi0IcepR917nZXXg7Azq7gssVRsepusxgU6RxTaY2HjmgBZ5a4d/XWBOiWnsl Z3rf4HMtHGQVunE1Nr8jQs0J01Ak0/pdp/po856Fy6BYJVQWx773glj3xa7RK5LP GRm8U4sD9SirC0vIdOnKlU9pBrCRtWC6c5TjJm57WFaGEujIt6q8SL7bqe1Sct+0 lKR4WO+66iUfNwCYsbLUT/mt5zwdVeiqmi5CtRYRMvTn972cKpYh1Lsyd3Xr45Ok ZZSQ4iQn3g6l2i9A5kSJw0tiVjNTKdc4+S9UhOuQsSXusXr1lvkrl9wrwgG+sXK0 Dt4cKdjNh3TIt+OcQ2R1jvqU3dkQlD8wj3aBtXJf6U0OQTSjc/0iCXy00yyoNwsM ZrVlT7DoLQ5+fMAbWy6RdXqONpEbEF6wxN/UCMJtyC+UUns4oyp5ndygKVoub1l0 PmkWQEX8GbsKu4q81OjIp4cdouEsIkkrVanDy+keYvX+ykxRGq0qg2+lVltYz3RJ 6Lb5SeK+Ky9TLJNL3mo0Xi0fQ0VCXti3t+5X4MwlDQ7gqLoEqGCBvC/coSInFuJO zlOaK8Jan/sh8uwH2WKcfa8HK2vI2d1MBtMd1om2SWGH2SlMVML2D4tVXZjlMzC1 Je8PniI9/LVi/UXE6Asn =eFtc -END PGP SIGNATURE-
Re: [PATCH 1/2] wined3d: Handle texture types via ps/vs_compile_args
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-04-10 15:13, schrieb Henri Verbeet: On 10 April 2013 14:32, Stefan Dösinger ste...@codeweavers.com wrote: *) Shader declares a 2D sampler but e.g. a cube texture is bound Yes, but we have the dummy textures for that. My understanding was that we don't want to use the dummy textures for this purpose, but I'm not sure about the reason - probably because we have to re-bind the dummy texture every time the texture type is changed. Matteo, do you remember the details about this? If the dummy textures are the preferred way to handle incorrectly bound textures, most of this patch is moot. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRZWtoAAoJEN0/YqbEcdMwCvUP/1dUCAz4VGdGBMoJLCY19rlr yW9EXVuthizZXuoBueNPdBZtMj/NIh22WRr33aObWsMkvdL5vwuWklwMkHW/Pjzh xTQitfeu4wfI4DV9inCQaKiTWYxf9h+kAZxoaEnixGZHk5EkVUroic7n6hbGvPs+ e/kCwPyO+aYioxTFqvF2o4WANdzu0UF3MExz6GQiwqSzhNnlZhHy+hEDrOcbGbeS Eg9jgTutgFSEQu7+FDOHi8mNHQ7LCeBg09/OiUZVm00lTqS2FWFTg/7l1javKsdr FwKg6D7/CqdFmYSEv9aXzU+HaaDifNWI5P991qWb6k0i+IljpUnJHwy03vOcImHm VSQGTTHpFpWMAwDglbbBMU8cImhtd7EW9DmTH5kSIJ39ONCoYQRVZtXxGT+ducGa CbHDfgBbGBsP145+KtD35nAahf2+le9QwHMruBJ/Di53JcBUUuBYDIgNpJWz/wvK 7f1EcuMC05lMKxy6RE9dEE1CNrUpLz1IXVgHa3gDHl+cJRpBkWSV7uL0NDO7STS3 04PhDiQOwrnh7K48kMt7JztcKbG+obvdiOfv7Wj2kNPeRllMrQUN+AEaFKG3YQEP KeKsts6BBkjQkqYTYLCAm/vxCnJ9rWHmKdjjl355Il1aDocJb+mT48zZA5JBEzz9 flE2jibstgLp6Qzm7Wj1 =S7yF -END PGP SIGNATURE-
Re: Google Summer of Code
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Am 2013-04-10 18:28, schrieb Liu Tuo: I am Liu Tuo from National University of Singapore. I am interested in implementing missing D3DX9 APIs, how can I know more about this project and how can I apply for it? Is there anyone who can help me with this? Thanks for your interest in Wine. I recommend to do some basic research about d3dx9 and gsoc yourself, e.g. how to apply and which parts of d3dx9 are not implemented and need more work. Feel free to ask if you have any specific questions. Cheers, Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRZbstAAoJEN0/YqbEcdMwBS0P/0hlqGVJiALFyRdxTFLmUwXe yFxsdJCTErh+cdOaWtPUJ2As9JdR3Ukd4cnMvvFQ4vxTwesH5L+oIerrHV7n2RRk udz2Apt4wmE11N7GgP04rI6WeTQllu/SC+2nqdIIwz6wdaql4obO5jX9FN0cl/0c +ORchMNDagZXq8sUoz9yV5QTno0t0xClol0wFxBDYYoJesb0UTDJUuESf91+NArt MZpYGXwwE9FzljzuP16cBO0VOARvOdxH+biT5+kVQujItwhSlqyahntCZY6hKhTj y2CI3lheFsjdnIRBG+UB5I+Z5nPg9Zj292CpQSiARE0WNoTYk45JVA59TBQINJx3 IKULQolaKG6uhwKVgeWKRHTWogQblTjrXA74gVFDcr7qM5K/KZct6MTv8MKvqqfz y4VWbDy5PaDPPNEPX2KpgyTjT1zcDkEOyjuL8R1kBcVCICfEnksSBPz58Hc4yaBR q4SeKMayLNQKamDUxaGpuB+cg+Pd8Ax7ybO8wdIj3KIBKUq3LroCcopfQn6DZWD2 H8/3I760b4TtoGWLwtRT4ybjjyo4whHUN/ICSJMds/+9MSHPo0sZgm0qeOX87RAM F+DRl3pO1Hx3rI5jUuTGt5aUyHq5aplr7YZ4jr8KROW2ZkEozbBWK+rERbYL0Yw2 zps02Z0MjWMqWq7qjXh5 =Mn7F -END PGP SIGNATURE-
Re: [GSoC] My (new) proposal for GSoC 2013
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-04-05 10:54, schrieb Gediminas Jakutis: This was discussed on the IRC a bit. The idea is to write [performance?] tests that are to be used for dxdiag. (I suppose that includes that funny spinning dx logo cube test found on the native dxdiag). I think performance tests for dxdiag won't work, but a related idea might: In the past, I have written a number of microbenchmarks for various d3d operations like drawing, changing stream sources, changing vertex shaders, etc. You can find the code at https://84.112.174.163/~git/perftest (self-signed cert). I'm also running some of those tests The overall idea is to use such microbenchmarks to optimize single operations, in the hope that those optimizations stack up and improve real games. Most benchmarks have a GL version to find out if there's a difference between the GL and d3d drivers, or the Windows and Linux drivers. Adding more benchmarks to this collection and investigating spotted performance differences would be a useful gsoc project imo. Regarding the way of testing if opengl works - I was thinking in the lines of: Making a GUI tool that would let simple users test if d3d and opengl works along with providing info on current wine-specific d3d / opengl settings / specs and similar thing. There are tests like that in CrossOver, and my experience with them is that they don't provide too much value. The warnings if libGL.so doesn't load, or if direct rendering is not available are helpful, but all other tests go unmaintained over time and become irrelevant. Wine prints some info like that on the winediag debug channel. Showing a window instead could be a usability improvement, but that's not enough work for gsoc. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRY/UmAAoJEN0/YqbEcdMwGVsQAJYpg64Xnx2OazLz+eLqKgVR 2EMZaqP5eT1caR4X2Uv3G5hV7CtcJUE+aAxw8qe/Yn/v5ASmGgNuuEUoA6JIoDgC bHZq/4+VPVBHIk+tN1cfFK6tZWHlB76pGyUyGKTsuP0IGdWU+AaEGAVu8sYM1pKE UwLZowhGSqULdL3pNgkoUWeE7hfn7JESvl+LIdRvdJS4xUNJmhZdiaGxG98XW1aZ S/IsuiNHuhGeaosgjc2VgJfviVgrywJXTsGqyzdVhyv0ndnVFRbI7hwZcgns8R6/ NByOZQJKiMuqeFR9dT2+wmwk4pszbVJYJ+wMZMxwPP220HF2+vQy6pNzvaMxizD9 y6/795t1noVt8KW00QQ8PVjlnre5eO5Y+paIZG/wAJ3JorFHMDQ02jZuZrpXJn8s 1TV3LH0qyRIF6GNTy5BSXhluk320U312biKYqFuWRgrzIQkp4Zobd1lwbSsZYTm3 IxD8DqibeUcdSIFc7Nf1X+JUL0700+HX2WJFfldVc+RA8iKfXK0elYn8PVkQeiFr k3aJjwI8VQ/jbr/roRSLRVSgeL7AP8ST7x8LDYjtNPgw1N2289IKuXrQ6hDrrlKZ 23qj+WyX+AQo8ARjpKHNfAQHMrkKd9O0/2TLhNJpETvFaRACizY8HpxHHTyUrvZ3 on3sZGchvKb6OQrt0Sar =kmYX -END PGP SIGNATURE-
Re: [GSoC] My (new) proposal for GSoC 2013
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-04-09 13:01, schrieb Stefan Dösinger: I'm also running some of those tests That sentence got cut off: I'm also running some of those tests on a nightly basis to monitor Wine's performance. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRY/dQAAoJEN0/YqbEcdMw0/cP/RCURabshM5dKozfpVE8yw4V GT9FCEBL0WyoMfqBsxHCPiPeZ2r+e3DyL2b8PK0xGc+TphFMtdfeZUbMO6CDN4W0 YeI+wRZcEQbdMGagV3wk/2IipFKLiaY/0k/PPk9RWilxYn8IDyqJmL+OKGCRA7za qY7ailwqfr4TBIJVBEqlM9dMlBRixzdto8d9Byi0IryX3/T83QInGfU+y5FB3K50 QZZJQ8nKmn2nkViHfstL4cfhD9oQfIGbSQ/sLuJ+EZgTJOhOqMBe5qfFr0zgrzqz kGShxXGwRbPgLcgQXiDRKk/VgUingNINsh70gx9CMVe7qDx+6x5YiZWoy0QOf4KC FTwEZ4cQCI7+rBd3NCcSKKiK73qJ470MWm/wlPDC1LisPcLq4XQieB/PW4GnTKAB 6iv6hmHi4v0bgXplDiIv+5RAl6CxsKoSCpCbtbYnbIpXHfWJRF/vhxBcPttzG8w0 ySUKy8opj1ZVwUQ9U436b0a6Iqkg4aBCi2k7EDgT0YtDLVingDbv0AmIET8GvT7t eXDoy39xM3Tm5hyjOdTzRHcQSmYZ6kgA7Hxf9N88Nydtors+5eJK2nob44R2pr6R ms/uHzcJru0lJLI510E5rFSBby9C6xpTGO6dCVN5nHUstdbSToU46v1S5hAcqyM8 HejFtQkOqohx4c+o8bH1 =mSZN -END PGP SIGNATURE-
Re: [GSoC] My (new) proposal for GSoC 2013
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-04-04 22:52, schrieb Gediminas Jakutis:
Hello!
My previous application[1] turned out to be a total failure, hence
making a completely different one. My proposal this time goes as
follows: Write various D3D tests, mostly focusing on ones that can
be later re-used for dxdiag in one way or another. Along with
writing a tool that would allow users to easily test if d3d and wgl
/ opengl work are set up properly.
There is some merit to the proposal, but it needs a lot more detail.
We already have a lot of d3d tests (see
dlls/{ddraw,d3d8,d3d9,d3d10core,dxgi}/tests/) . Those already provide
a way to test if opengl works ok, to some extent - those tests are
fairly strict and only pass on nvidia and r600g.
Extending dxdiag (and adding the information dialog) might be a good
idea. I think there have been some projects concerning that in the
past, I recommend to do some research.
Lastly there are some bug reports which need tests, e.g. 10164 and
29052. Bug 29052 should provide a nice introduction into ddraw/d3d
programming in Wine, but those two bugs do not provide enough work for
a full gsoc project. Some additions will be needed. However, Alexandre
has stated that writing tests for the tests sake (i.e., no application
that uses the testsed behavior) is not a good idea. Picking any number
of apps which have bugs that are not understood yet and attempting to
fix them is a bad idea as well because you don't know how long it'll
take you to fix them until you have some idea what the actual problem is.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJRXnhmAAoJEN0/YqbEcdMw7p0QAIkfZdXHfVbuOyN42BZYDvyu
1gPCqAEKk6Im45GSJPy1cRI43n//cTC9QYy2UYNcEbv8wkZ4O2IYMWp7lBFiukc6
A5R9TbzzjxcuIkaaqCW0fHhiFFZZw/WZA5fu0ZQTxDbgTHQqR45S269I+BXwltUy
kfuZWTVKDHdmI54y6+YVoypGhvKNPWZeBVPea3xaWVu4V8dzSZT1FchMSC0EPOvO
6d46BAodkJsf8y9gga6zXe+sQwX8r4nuOJrxrdvkVx8YfamYzW8IDioBWyJu8STc
wF4Xe5tI04TrKadorDSsFhy8Kpr0za9zsTvMxfSAjOFTM5mFn1pJtF+a+Wj0FmKB
gM7qqy8mPiL4dyKx4/mP2RPZjYvBr+k2nxaLTr9ARI4JvKAfSLAlwPzNyY/z1E4u
2rZ+WMxzgAxv0rV+1s9+lWd4h6hqniuOZITrKd/EC0KA4DBsuy6ls1Re/zMqtdOg
enHfQGL2oRoXHPTidqO6zXuY5aJH7SyhhWbvY6/RlillgMSUOIGlM6IeSGq6BvJd
CvFqtrD9aRNzjmfUaUZy9BS4hNgw+RzWMiwk3WZfIB0U9+rxLpd345ijwAEHi4Yv
Q2px5PT2Wn8rdvLMSET9oWylIjZyZ5ax1OPcCV9I+ZHKqg3ptxCGBXzjRHJAlkWJ
aDANITdvhCkaPymIYDkt
=FBD/
-END PGP SIGNATURE-
Re: winehtml5.drv: Added new HTML5 driver.
Am 01.04.2013 um 16:55 schrieb André Hentschel n...@dawncrow.de: Maybe you should continue with your work until wined3d supports webGL as backend ;) No, nobody will need regular d3d once all games are written in webD3D.
Float printf precision
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Henri,
While overhauling the patch to hardcode local constants in the shader
code I came across the TRACEs in wined3d_device_set_{vs,ps}_consts_f,
which print the floats with %.8e. You changed this from %f in
979e3744f7721bef9e88fd671dfd7591c9f85392.
I was curious how you ended up with 8 digits. My thinking was that 32
bit floats have a 23 bit mantissa, and one digit in the printout
encodes lb(10) bits - so you need ~6,9 digits to encode the mantissa,
which rounds up to 7. Thinking further, %.6e should do the job as
well, as there's one additional digit leading the decimal.
Is my thinking correct, or am I missing something?
Cheers,
Stefan
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJRWAiyAAoJEN0/YqbEcdMw+4AQAIW57gxqJJcPEKzS35K4R++Q
aMy1rma7JV4/cUmRIqkmOROc6Y3T2bz7x3e12mNpLVvI9YUBdaZKsofuBJk9QCtL
R6nWL266dLc3aRdIFazwjxK6GmohqjxoLidpCAPSXGkekjw48DqhA+5fdXO2YYm/
2g1Fhyy/cpi6BN2AUh760YNy3ojk/x9eH25oTmifFxCUbWlhYNGsIVt8OTTW9YBE
RnQyyoO2lPjNi5mlNIqoSkkYriG5m97nS8bSMXvu9BjKW8rSmmErLGPf2zDL7Big
wdibKxbXaSSx74upJaOTLjoOx04sqoi4SuPnX/55ftFKj7s2SeoFJaOUwgdNJoN+
UxKcd0HzfaXBi/VikYvtfMd0+SLA8wFIVjrJsWeBwgNU9cEAA3OiRFPWyizZCPqu
4UQOSnxuK6LZ7Ke58ikcG6JqMVTye8iTeEmr6r3NhkRdmCKrFbVGmJ1POb8Q26Hu
q2yQBHq2L5CZ0Vx7fruvqq9Ap8auI/l5B6tneDM/RUdvpWxQTJneVRpSqIE50ZmW
U3XH2cx4eLaEGJnSnHBgxnqgSAmcVTJEkFHtd8tCiqsPcnkw2g3Ng3gQZhjkDJ45
ZxvXNxVUl3B899Y1CwFd3FVJhKQq2jFS0NQvNQYZXhx0djZ2ok8rvtmoJzTaNN1s
SMfTtZDHxHFtluASd6zJ
=7CAL
-END PGP SIGNATURE-
Re: wined3d: add NVidia GeForce 315M
Am 17.03.2013 um 17:08 schrieb Daniel Jeliński djelins...@gmail.com:
why can't we get these values from X? They are definitely present in
my Xorg.log.
Propose a patch.
A few notes though:
*) The upcoming GLX_MESA_query_renderer extension will provide a good way to
query this info. If this extension will be adopted by the binary drivers is an
open question.
*) The X.org log would be an extremely ugly way to read this info. The log is
at an unknown place, might be readable only by root or might not exist at all.
There format of the log messages might change.
*) There are vendor specific X11, GLX and GL extensions to query some GPU info
*) Wined3d should not deal with GLX_MESA_query_renderer or any other X11
specific things. This should be handled by winex11.drv.
{GT 320M, CARD_NVIDIA_GEFORCE_GT320M},/* Geforce 300 -
midend mobile */
+{315M,CARD_NVIDIA_GEFORCE_315M}, /* Geforce 300 -
midend mobile */
{320M,CARD_NVIDIA_GEFORCE_320M}, /* Geforce 300 -
midend mobile */
Afaics this table is sorted in descending order, for consistency you should
swap the 315M and 320M
Re: WineD3D performance
Am 14.03.2013 um 20:07 schrieb Graham Knap graham.k...@gmail.com: I would like to try to help with improving the performance of StarCraft II on Wine. I'm working with a friend. Over the past couple of weeks, we have tried to read whatever documentation we could find. We have tried a couple of different approaches to profiling, without much success. That's great :-) Note however that improving performance is not a weekend's job. It needs a lot of careful profiling, testing and bugfixing. Can anyone offer some hints on how to find the most significant causes of the performance difference? Any tips for effective profiling or tracing? Depending on your settings, you may be CPU or GPU limited. A rule of thumb way to find out is to change the game's resolution - if increasing the resolution causes a big framerate drop, you're probably GPU limited. If the framerate stays the same, you're CPU limited. In the GPU limited case, improving the situation requires a tedious work to find shaders that execute slower, finding out why they are slower and then fixing things. It also needs double-checking with other games and GPUs to make sure that you're not optimizing one game at the cost of another. In the CPU limited case, I believe the main reason is that native is able to move a lot of the CPU-side work to a different thread, thus utilizing two CPU cores. You can test that theory by forcing Windows to run with one CPU only (use msconfig for that) and comparing performance again. Aside of the worker thread, there may be some parts of the wined3d code that can be optimized. Like the GPU side work, this requires a lot of careful testing, fixing and double-checking. Stefan
